Abstract: A remote transaction system comprising: a first secure server arranged to store unique identification (UID) data corresponding to a plurality of persons; a transaction network arranged to mediate at least a portion of transaction data corresponding to a transaction between a first of the plurality of persons and a second of the plurality of persons; a first data entry device associated with the first of the plurality of persons; and a second data entry device associated with the second of the plurality of persons; the first data entry device arranged to input data indicative of the commencement of a transaction into the transaction network, a portion of the input data being related to UID data corresponding to the second of the plurality of persons; the first secure server or the transaction network being arranged to generate and transmit a single usage pass code to the second of the plurality of persons, responsive to receiving an indication of the commencement of the transaction, based upon the portion of the input data indicative of the UID data; the second data entry device being arranged to receive from the second of the plurality of persons an input corresponding to the single usage pass code; the transaction network being arranged to communicate transaction data between respective accounts of financial institutions linked to the first and second of the plurality of persons such that the transaction is effected, based upon the verification of the single usage pass code.
Background of the invention
A unique identification project has been proposed by the planning commission of
India. As part of this project, a unique identifier will be assigned to each resident
which is linked to the person's demographic and biometric information. The
5 unique identifier (UID) will make it possible for residents to easily verify their
identity to both public and private agencies. The UID will guarantee identity and
not rights, benefits or entitlements.
One important aspect of the model is that Know Your Customer (KYC) and/or
10 Know Your Resident (KYR) policies and regulations are adhered to. These
policies are due diligence activities that financial institutions and other regulated
companies must perform to ascertain relevant information from their clients for
the purpose of doing business with them. These policies are becoming
increasingly important globally to prevent identity theft, financial fraud, money
15 laundering and terrorist financing.
Brief Description of the Drawings
An example of the present invention will now be described in detail, by way of
example only, with reference to the accompanying drawings, in which:
20 Figure 1 shows schematically a known authentication operating model;
Figure 2 shows schematically an operating model of a welfare disbursement
payment system;
Figure 3 shows schematically an operating model of a cash withdrawal system;
Figure 4 shows schematically an operating model of a payment system
25 according to a first embodiment of the present disclosure;
Figure 5 shows schematically an operating model of a payment system
according to a second embodiment of the present disclosure; and,
Figure 6 shows schematically an operating model of a payment system
according to a further embodiment of the present disclosure.
30
Detailed Description
At the centre of the UID project is a form of online authentication, where
agencies can compare demographic and biometric information of a resident with
2
_ a record stored in a central database. This authentication system can be
accessed by banks and other service providers to verify an individual's details
anytime and from anywhere. An exemplary authentication platform and example
uses of the platform are described in February 2012 in the paper "Aadhaar
5 Enabled Service Delivery" by the Unique Identification Authority of India (UIDAI),
Planning Commission, which is incorporated by reference.
Figure 1 depicts the authentication operating model exemplified in the above
paper. The model includes Authentication User Agencies (AUA) 111 and
10 Authentication Service Agencies (ASA) 112. An AUA 111 is an entity that
utilises the authentication to enable one or more of their services and may
communicate with an ASA 112, which is an agency that has established secure
leased line connectivity to the Central Information Data Repository (CIDR) 113 to
transmit authentication requests on behalf of the AUA 111 and receive
15 responses from the CIDR 113. The ASA 112 and the AUA 111 may of course
be the same entity and may each directly communicate with the CIDR 113 or the
direct service provider.
In the exemplary operating model of Figure 1, a resident 114 will request
20 authentication (step 101) with an authentication device/operator 115. The
authentication device 115 will then communicate with the AUA 111 using a
specific communication protocol (step 102). The AUA 111 will request that the
ASA 112 confirm the authentication (step 103). In this model, the ASA 112
passes the user information onto the CIDR 113 which will return a yes or no
25 response depending on whether the authentication can be granted, i.e. that the
demographic or biometric information presented by the user 114 matches the
information stored for that user in the CIDR 113 (step 104). The ASA 112 then
passes this yes or no response to the AUA 111 (step 105). The AUA 111 will
then send the necessary updates and confirmation to the authentication device
30 115 (step 106) depending on the individual service. The service is then
delivered to the user, most likely by the authentication device 115, but
alternatively by a further electronic system (step 107).
3
• In order to allow service providers to communicate with the data repository CIDR
113 there has been defined a set of Application Programming Interfaces (APls)
which are outlined in the April 2012 paper 'Aadhaar Authentication API
Specification - Version 1.6' by the Unique Identification Authority of India
5 (UIDAI), Planning Commission, which is incorporated by reference. The APls
defined in the paper use XML and the authentication service is a stateless
service over HTTPS.
In addition to setting out APls which define how services should interact with the
10 CIDR, the paper also sets out an exemplary authentication flow in the case of an
operator assisted transaction at a Point of Service (PoS) terminal as follows:
"a) Resident provides [UID] Number, necessary demographic and
biometric details to terminal devices belonging to the AUAlSA (or
15 merchant/operator appointed by AUAlSA) to obtain a service offered
by the AUAlSA.
b) [UID] authentication enabled application software that is installed on
the device packages these input parameters, encrypts, and sends it to
AUA server over either a mobile/broadband network using AUA
20 specific protocol.
c) AUA server, after validation adds necessary headers (AUA specific
wrapper XML with license key, transaction id, etc.), and passes the
request through ASA server to UIDAI CIDR.
d) [UID] authentication server returns a "yes/no" based on the match of
25 the input parameters.
e) Based on the response from the [UID] authentication server,
AUAlSA conducts the transaction."
Although the extract above describes that the resident provides the necessary
30 demographic and biometric details, in practice the resident need not provide
their biometric details, in many instances merely using the UID number is
sufficient to identify the resident.
4
A number of the aims and potential advantages of the UID project include (see
http://uidaLgov.in/aadhaar.html, accessed 29 November 2012):
A guarantee of uniqueness and centralised, online identity verification
which would be the basis for building multiple services and applications, and
5 facilitating greater connectivity to markets.
The ability to access services and resources, anytime, anywhere in the
country.
The provision of an identity infrastructure for ensuring financial inclusion
across the country - banks can link the unique number to a bank account for
10 every resident, and use the online identity authentication to allow residents to
access the account from anywhere in the country.
A foundation for the effective enforcement of individual rights. A clear
registration and recognition of the individual's identity with the state is necessary
to implement their rights - to employment, education, food, etc. The number, by
15 ensuring such registration and recognition of individuals, would help the state
deliver these rights.
One of the potential applications of the project that has been proposed is a
universal, micropayment solution. Such a solution is described in April 2010 in
20 the paper 'From Exclusion to Inclusion with Micropayments' by the Unique
Identification Authority of India (UIDAI), Planning Commission, which is
incorporated by reference.
In particular, this paper sets out the following:
25
"In the last twenty years, India has undergone a transformation of its
economic and regulatory structures. Policy reforms in this period have
led to the increasing maturity of our markets, as well as healthy
regulation. The emphasis on de-licensing, entrepreneurship, the use
30 of technology and decentralisation of governance to the state and local
level have in particular, shifted India from a restrictive, limited access
society to a more empowered, open access economy, where people
are able to access resources and services more easily and effectively.
5
But despite these efforts, access to finance has remained scarce in
rural India, and for the poorest residents in the country. Today, the
proportion of rural residents who lack access to bank accounts
5 remains at 40%, and this rises to over three-fifths of the population in
the east and north-east parts of India.
This exclusion is debilitating. Economic opportunity is after all,
intertwined with financial access. Such financial access is especially
10 valuable for the poo~-it offers a cushion to a group whose incomes
are often volatile and small. It gives them opportunities to build
savings, insure themselves against income shocks and make
investments. Such savings and insurance protect the poor against
potentially ruinous events-illness, loss of employment, droughts, and
15 crop failures. However due to the lack of access to financial services,
many of the Indian poor face difficulties in accumulating savings.
To mitigate the lack of financial access in India, the regulator has
focused on improving the reach of financial services in new and
20 innovative ways - through no-frills accounts, the liberalization of
banking and ATM policies, and branchless banking with business
correspondents (BCs), which enables local intermediaries such as selfhelp
groups and kirana stores to provide banking services. Related
efforts have also included the promotion of core-banking solutions in
25 Regional Rural Banks; and the incorporation of the National Payment
Corporation of India (NPCI) to provide a national infrastructure for
payments and settlements in the country.
Advancements in technology such as core banking, ATMs, and mobile
30 connectivity have also had enormous impact on banking. Mobile
phones in particular present an enormous opportunity in spreading
financial services across India. These technologies have reduced the
need for banks to be physically close to their customers, and banks
6
have been consequently able to experiment with providing services
through internet as well as mobile banking. These options, in addition
to ATMs, have made banking accessible and affordable for many
urban non-poor residents across the country.
5
With the poor, however, banks face a fundamental challenge that limits
the success of technology and banking innovations. The lack of clear
identity documentation for the poor creates difficulties in establishing
their identity to banks. This has also limited the extent to which online
10 and mobile banking can be leveraged to reach these communities.
Besides challenges of access and identity, a third limitation has been
the cost of providing banking services to the poor who transact in
smaller amounts, commonly referred to as micropayments. Banks
15 consider such payments unattractive since transaction costs may be
too high to bear.
The Unique Identification number (UID), which identifies individuals
uniquely on the basis of their demographic information and biometrics
20 will give individuals the means to clearly establish their identity to
public and private agencies across the country. It will also create an
opportunity to address the existing limitations in financial inclusion.
The UID can help poor residents easily establish their identity to
banks. As a result, banks will be able to scale up their branch-less
25 banking deployments and reach out to a wider population at lower
cost.
An efficient, cost effective payment solution is a dire necessity for
promoting financial inclusion. The UID number and the accompanying
30 authentication mechanism coupled with rudimentary technology
application can provide the desired micropayment solution. This can
bring low-cost access to financial services to everyone, a short
distance from their homes.
7
" The key features of UIO-enabled micropayments outlined in this
document are as follows:
5 UIO Know Your Resident (KYR) sufficient for Know Your Customer
(KYC): Banks in India are required to follow customer identification
procedures while opening new accounts, to reduce the risk of fraud
and money laundering. The strong authentication that the UIO will
offer, combined with its KYR standards, can remove the need for such
10 individual KYC by banks for basic, no-frills accounts. It will thus vastly
reduce the documentation the poor are required to produce for a bank
account, and significantly bring down KYC costs for banks.
Ubiquitous Business Correspondent (BC) network and BC choice: The
15 UIO's clear authentication and verification processes will allow banks
to network with village-based BCs such as self-help groups and kirana
stores. Customers will be able to withdraw money and make deposits
at the local BC. Multiple BCs at the local level will also give customers
a choice of BCs. This will make customers, particularly in villages, less
20 vulnerable to local power structures, and lower the risk of being
exploited by BCs.
A high-volume, low-cost revenue approach: The UIO will mitigate the
high customer acquisition costs, high transaction costs and fixed IT
25 costs that we now face in bringing bank accounts to the poor.
Electronic transactions: The UIO's authentication processes will allow
banks to verify poor residents both in person and remotely. Rural
residents will be able to transact electronically with each other as well
30 as with individuals and firms outside the village. This will reduce their
dependence on cash, and lower costs for transactions. Once a
general purpose UIO-enabled micropayments system is in place, a
variety of other financial instruments such as micro-credit, micro-
8
" insurance, micro-pensions, and micro-mutual funds can be
implemented on top of this payments system.
The UID-enabled micropayments solution is just one of the many
5 developmental applications of the UID number."
As described above, the UID may provide a method of uniquely identifying a
person or a resident of a country, such that fraud may be reduced and trust and
inclusiveness may be increased. The UID platform allows for the provision of
10 further applications and services using the unique identifier.
In order to provide functionality such as that described above, there may be
established UID-enabled Bank Accounts (UEBAs). UEBAs are linked to aUlD
number and a customer can access their UEVA through a microATM device.
15 The UEBA generally operates as a prepaid account, similar to those used by
mobile operators when charging for talktime. The UEBA provides four main
features:
- a store of cash for savings, with a facility for making electronic deposits
and withdrawals in micro-amounts;
20 - a way to make payments;
- a channel for sending and receiving remittances; and,
- enabling balance queries and transaction history queries.
Other documentation which may aid in understanding the background to the
25 invention can be found at http://uidaLgov.in and http://uidaLgov.in/uidaidocuments.
html#publication, accessed on 29 November 2012.
For the purposes of introducing concepts of embodiments of the present
invention, an international payment system such as that operated by MasterCard
30 International Inc. and international remittance systems such as those described
in W02008/124584 and W02008/124580 may be used. These documents are
incorporated by reference.
9
It The payment system operates to route and clear funds transfers from the
payment card accounts of senders to the payment card accounts of recipients.
One example of a payment system is the Banknet system, which is well-known
to those who are skilled in the art. The Banknet system is a global
5 telecommunications network linking all MasterCard card issuers, acquirers· and
data processing centres into a single financial network. Typically, payment
systems such as Banknet comply with standards specifications which define the
interchange message specifications for the exchange of electronic transactions
made by cardholders using payment cards. ISO 8583 - Financial transaction
10 card originated messages is one such standard. The international remittance
systems described above may utilise these payment systems to initiate a funds
transfer.
Although embodiments of the present invention are described in the context of
15 the UID project in India and international remittance and payment systems such
as those operated by MasterCard International Inc., it will of course be
understood that the principles of the present invention are not limited to such
systems and projects and are equally applicable to other systems and projects.
20 Currently the average transaction value for pizza-like home deliveries in India is
in the region of 250 to 300 RUP. Additionally, a convenience fee may be
charged; for example, McDonald's® charges approximately 25 RUP (10%) for its
home delivery service. The consumer pays this convenience fee, some of which
the merchant will typically use to pay an agent for making the deliveries.
25
In India the failure rate for home deliveries is typically in the region of 12 to 15%.
The systems currently in place are susceptible to fraud and deliveries often go
missing or unpaid. The management of returned goods is a big issue in terms of
time and cost. Non-delivery takes up some of the agent's time and thus adds to
30 the merchant's costs. Furthermore, where agents are dealing with cash
transactions there are safety and security issues involved.
10
According to embodiments of the present disclosure, a UID-linked remote
payment system is provided which replaces cash-on-delivery (COD) and
therefore obviates or alleviates the causes of fraud and security risks in typical
delivery systems.
5
Figure 4 depicts an operating model for a UID-Iinked remote payment system in
accordance with a first embodiment. The model includes a payment network
408, which acts as a link between a resident 114 and a merchant 301, aUlD
database 409 which stores UID information and a final transaction 410 which
10 represents a transfer of funds.
In all embodiments described herein, the payment network 408 may comprise an
international payment system such as that described above and operated by
MasterCard International, Inc. Where the description refers to a bank account, it
15 will be understood that this bank account may be instead a prepaid card as
substantially described above.
In the exemplary operating model of Figure 4, the payment network 408 receives
an indication from the merchant 301 that a payment is due (step 401). This
20 payment request is linked or associated with the UID number of the resident 114
who will be making the payment. Optionally, the payment network 408, in
response to receiving the request, generates a notification that is forwarded to
the resident 114 (step 403). This notification may typically, but not necessarily,
take the form of an SMS to the resident's mobile phone. In order to retrieve the
25 mobile phone number of the resident, the payment network 408 may interrogate
the UID database 409 with the UID number of the resident or the merchant may
pass the number to the payment network 408 with the indication that a payment
is due.
30 The payment network 408 may also monitor recurrent payments and generate
the payment request without indication from the merchant 301 (not illustrated),
for example, for weekly lease payments for goods or services.
11
In order to approve the payment, a one-time password (aTP) is generated at the
UID database and sent to the resident 114 (step 404). In the illustrated
embodiment this step is initiated by a notification of the payment request sent by
the merchant 301 to the UID database 409 (step 402). The aTP may be
5 generated and sent at the same time as the mobile phone number of the
resident is returned to the payment network 408 for notification to be sent to the
resident 114.
Where the payment network 408 has generated the payment request, rather
10 than the merchant, the network may notify the UID database 409 of this request
(not illustrated). Additionally, the request for an aTP may be generated by the
network rather than the merchant upon receipt of a request for payment from the
merchant (not illustrated).
15 In response to receiving the aTP, the resident 114 transmits the received aTP
to the payment network 408 (step 405), this may be by SMS. The aTP is then
authenticated by the payment network 408 with the UID database 409 (step
406). If the aTP is successfully authenticated then the payment network 408
initiates the transaction 410 (step 407), a transfer of funds occurs and the
20 resident's account is debited and the merchant's account is credited.
The further payment system 410 may be an international payment system such
as operated by MasterCard, Inc. and the payment network may be an
independent platform. The transaction is illustrated as taking place in a further
25 payment system 410. However, the payment network 408 may be operable to
complete the transaction without instructing a further network, in an integrated
payment system and payment network platform.
In the described embodiment, the aTP acts as confirmation that the transaction
30 should be completed, thus reducing the risk of fraud in the system. The UID is
linked to a particular mobile phone number in the database and so the UID acts
as a common link throughout the chain, from merchant through to completion,
such that only that particular resident having the UID can confirm the payment.
12
5
10
15
20
25
No funds are transferred until the resident 114 has confirmed that the transfer
should take place, and the merchant has instigated the process requesting the
funds.
Figure 5 depicts an operating model for a UIO-Iinked remote payment system in
accordance with a second embodiment of the present invention. The model
includes a payment network 408, which acts as a link between a resident 114
and a merchant 301, a UIO database 409 which stores UIO information, a
courier 509 and a final transaction 410 which represents a transfer of funds.
Figure 5 illustrates an embodiment in which the receipt of goods is confirmed
electronically before funds are transferred.
In the exemplary operating model of Figure 5, the merchant 301 provides the
UIO database 409 with a product code. The UIO database 409 acts to preapprove
an amount corresponding to that product. To do so, the merchant 301
may indicate the value of that product together with the product code or
integrally with the product code. Optionally, the UIO database 409 may be able
to otherwise identify the value of the product. The UIO database 409 then
generates a one-time password (OTP) which may optionally correspond to the
value of the product (step 501). The OTP is sent to the resident 114 (step 502)
in substantially the same manner as described above for the first embodiment
and the resident 114 then forwards the OTP and the product code to the
payment network 408 where it may then be validated, either through
interrogation of the UIO or through calculation.
The merchant 301 issues a redemption code to the payment network 408 for
passing to the resident 114 (steps 504 and 505) once the payment has been
pre-approved. Of course the redemption code could be generated by the
payment network rather than the merchant 301. In the illustrated embodiment, a
30 courier 509 makes a delivery of the product to the resident 114. Alternatively,
the goods could instead be transferred directly by the merchant 301. The
delivery may preferably occur only once the amount has been pre-approved.
13
Once the goods have been transferred, the resident 114 inputs their received
redemption code and their UID into a mobile device held by the courier 509 or
the merchant 301, as appropriate to the circumstances of the transaction, to
confirm receipt of the product (step 506).
5
The received redemption code and UID input is then sent back to the payment
network 408 and the UID information is passed to, and validated by, the UID
database 409 (step 510). The redemption code may be verified by the third
party payment network 408.
10
The redemption code may alternatively be generated by, or passed to, the UID
database 409 (not illustrated). In such an instance the UID database 409 may
be used to verify the redemption code.
15 Once the redemption code and UID information have been verified, the payment
network 408 initiates the transaction 410 (step 508), a transfer of funds occurs
and the resident's account is debited and the merchant's account is credited. As
described above for the first embodiment, the payment network 408 may be
operable to complete the transaction without instructing a further network.
20
The described second embodiment thus employs a redemption code which can
be used to confirm the delivery of goods before any funds are transferred. In
conjunction with the UID, it can be confirmed that the redemption code was
received and transmitted by the intended recipient thus reducing fraud in the
25 system and confirming that goods have been received successfully before any
transfer of funds takes place.
Figure 6 depicts an operating model for a UID-linked remote payment system
according to a third embodiment of the present disclosure. The model includes
30 a payment network 408, which acts as a link between a first resident 612, a
second resident 613 and a merchant 301, a UID database 409 which stores UID
information and a final transaction 410 which represents a transfer of funds.
14
In the exemplary operating model of Figure 6, the first resident 612 may pay for
products received by another resident 613, such as a relative or friend. The first
resident 612 pre-approves an amount which the second resident 613 will be able
to spend on products. The payment network 408 receives an indication from the
5 first resident 612 that a payment will be made (step 602). The payment network
408 then generates a notification, typically but not necessarily an SMS, that is
sent to the second resident 613 (step 604). Notification of the payment request
may also be sent by the first resident 612 to the UID database 409 (step 601).
The payment network 408 may send the notification of the payment request to
10 the UID database 409 rather than the resident 612 (not shown). A one-time
password (OTP) is generated in response to receipt of the notification at the UID
database 409 and sent to the second resident 613 (step 603).
The second resident 613 then returns the received OTP to the payment network
15 408 (step 605), this may be by return SMS, which is then authenticated by the
payment network 408 with the UID database 409 (step 609), either by
interrogation of the network or by the UID database sending the OTP to the
payment network in response to receipt of the notification.
20 If the OTP is successfully authenticated then the payment network 408 issues a
redemption code to the second resident 613 (step 606). The second resident
613 then presents the redemption code to a merchant 301 (step 607) who then
sends the redemption code and UID information from the second resident 613 to
the payment network 408 (step 608). The payment network 408 then validates
25 the UID with the UID database 409 (step 609) and validates the redemption
code.
Once validation is successful the third party payment system 408 initiates a
transaction 410 (step 610), a transfer of funds occurs and the first resident's
30 account is debited and the merchant's account is credited. The payment network
408 then notifies the merchant 301 (step 611) and the first resident 612 (step
615). The second resident 623 is then able to receive the products from the
merchant (step 614) now that payment has been confirmed. As above, the
15
payment network 408 may be operable to complete the transaction without
instructing a further network.
The key benefits of the above embodiments are as follows:
5
Merchant Consumer Delivery Government Scheme
Aaent
- Ability to -Access to - Ability to - Promotes use - Move cash
process orders new products authenticate ofUADAI to electronic
after & services recipient - Ability to forms of
authenticating - Financial - Electronic charge for payments
consumer inclusion payment UADAI-
- Reduced - Transparent - More secure services
Fraud pricing and less - Possible
- Guaranteed - Can include dangerous for channel for
payments micro delivery disbursement of
- Opportunity to subscription agents funds
increase sales fees (e.g. pay- - Less time
for-view TV) dealing with
non-delivery of
items
10 The flow charts and descriptions thereof herein should not be understood to
prescribe a fixed order of performing the method steps described therein. Rather
the method steps may be performed in any order that is practicable. As used
herein and in the appended claims, the term "payment card account" includes a
credit card account or a deposit account that the account holder may access
15 using a debit card. The term "payment card account number" includes a number
that identifies a payment card account or a number carried by a payment card,
or a number that is used to route a transaction in a payment system that handles
debit card and/or credit card transactions. The term "payment card" includes a
credit card or a debit card. Although the present invention has been described in
20 connection with specific exemplary embodiments, it should be understood that
various changes, substitutions, and alterations apparent to those skilled in the
16
art can be made to the disclosed embodiments without departing from the spirit
and scope of the invention.
WE CLAIM:
1. A remote transaction system comprising:
a first secure server arranged to store unique identification (UID) data
5 corresponding to a plurality of persons;
a transaction network arranged to mediate at least a portion of
transaction data corresponding to a transaction between a first of the plurality of
persons and a second of the plurality of persons;
a first data entry device associated with the first of the plurality of
10 persons; and
a second data entry device associated with the second of the plurality of
persons;
the first data entry device arranged to input data indicative of the
commencement of a transaction into the transaction network, a portion of the
15 input data being related to UID data corresponding to the second of the plurality
of persons;
the first secure server or the transaction network being arranged to
generate and transmit a single usage pass code to the second of the plurality of
persons, responsive to receiving an indication of the commencement of the
20 transaction, based upon the portion of the input data indicative of the UID data;
the second data entry device being arranged to receive from the second
of the plurality of persons an input corresponding to the single usage pass code;
the transaction network being arranged to communicate transaction data
between respective accounts of financial institutions linked to the first and
25 second of the plurality of persons such that the transaction is effected, based
upon the verification of the single usage pass code.
2. The system of Claim 1 wherein notification data corresponding to the
generation of the one time pass code is generated and forwarded to the first of
30 the plurality of persons by one of: the transaction network, the secure server.
3. The system of either Claim 1 or Claim 2 wherein notification data
corresponding to completion of the transaction is generated and forwarded to the
first of the plurality of persons by one of: the transaction network, the secure
35 server.
4. The system of any preceding claim wherein the second data entry device
is arranged to receive product code data indicative of the product that the
second of the plurality of persons wishes to purchase.
40 5. The system of Claim 4 wherein the transaction network is arranged to
pre-authorise payment for said product with financial institution associated with
the second of the plurality of persons and is further arranged to notify the first of
the plurality of persons of this pre-authorisation.
45 6. The system of Claim 5 wherein the first data entry device is arranged to
receive redemption code data from the first of the plurality of persons and is
further arranged to transmit the redemption code to the second of the plurality of
persons.
18
7. The system of Claim 6 wherein the first data entry device is further
arranged to transmit the redemption code data to the transaction network.
8. The system of either Claim 6 or Claim 7 wherein the second data entry
5 device is arranged to receive the redemption code data from the second of the
plurality of persons and is further arranged to transmit the redemption code data
to at least one of: the first of the plurality of persons, the transaction network.
9. The system of Claim 8 wherein the transaction network is arranged to
10 mediate the transfer of funds associated with the purchase of the product
between said respective accounts upon verification of the redemption code data.
10. The system of any preceding claim wherein the respective accounts are
linked to the UIO data of the first and second of the plurality of persons.
15
11. A method of executing a transaction between first and second of a
plurality of persons, said first and second persons being remote from each other,
the method comprising the steps of:
i) inputting data indicative of the commencement of a transaction
20 into the transaction network, a portion of the input data being related to unique
identification (UIO) data corresponding to the second of the plurality of persons
at a first data entry device, the UIO data being stored on a first secure server
arranged to store unique identification (UIO) data corresponding to a plurality of
persons;
25 ii) receiving an indication of the commencement of a transaction
between said first and second of the plurality of persons at a transaction network
arranged to mediate at least a portion of transaction data corresponding to said
transaction;
ii) generating and transmit a single usage pass code to the second of
30 the plurality of persons, from either the transaction network or the secure server,
based upon the portion of the input data indicative of the UIO data;
iii) receiving from the second of the plurality of persons an input
corresponding to the single usage pass code, at a second data entry device; and
iv) communicating transaction data between respective accounts of
35 financial institutions linked to the first and second of the plurality of persons such
that the transaction is effected, based upon the verification of the single usage
pass code, via the transaction network.
12. The method of Claim 10 comprising notifying the first of the plurality of
40 persons of the generation of the one time pass code.
13. The method of either Claim 11 or Claim 12 comprising notifying the first of
the plurality of persons of the completion of the transaction.
45 14. The method of anyone of Claims 11 to 13 comprising receiving product
code data indicative of the product that the second of the plurality of persons
wishes to purchase at the second data entry device.
19
15. The method of Claim 14 wherein comprising pre-authorising payment for
said product with financial institution associated with the second of the plurality
of persons via the transaction network notifying the first of the plurality of
persons of this pre-authorisation.
5
16. The method of Claim 15 comprising receiving redemption code data from
the first of the plurality of persons at the first data entry device and transmiting .
the redemption code to the second of the plurality of persons.
10 17. The method Claim 16 comprising transmitting the redemption code data
to the transaction network.
18. The method of either Claim 16 or Claim 17 comprising receiving the
redemption code data from the second of the plurality of persons at the second
15 data entry device and transmitting the redemption code data to at least one of:
the first of the plurality of persons, the transaction network.
19. The method of Claim 18 comprising mediating the transfer of funds
associated with the purchase of the product between said respective accounts
20 upon verification of the redemption code data, via the transaction network.
20. The method of anyone of Claims 10 to 19 comprising linking the
respective accounts the UID data of the first and second of the plurality of
persons.
| # | Name | Date |
|---|---|---|
| 1 | 3730-del-2012-GPA-(10-01-2013).pdf | 2013-01-10 |
| 2 | 3730-del-2012-Correspondence Others-(10-01-2013).pdf | 2013-01-10 |
| 3 | 3730-del-2012-Form-1-(05-06-2013).pdf | 2013-06-05 |
| 4 | 3730-del-2012-Correspondence-Others-(05-06-2013).pdf | 2013-06-05 |
| 5 | 3730-del-2012-Form-5.pdf | 2013-08-20 |
| 6 | 3730-del-2012-Form-3.pdf | 2013-08-20 |
| 7 | 3730-del-2012-Form-2.pdf | 2013-08-20 |
| 8 | 3730-del-2012-Form-1.pdf | 2013-08-20 |
| 9 | 3730-del-2012-Drawings.pdf | 2013-08-20 |
| 10 | 3730-del-2012-Description(Complete).pdf | 2013-08-20 |
| 11 | 3730-del-2012-Correspondence-others.pdf | 2013-08-20 |
| 12 | 3730-del-2012-Claims.pdf | 2013-08-20 |
| 13 | 3730-del-2012-Abstract.pdf | 2013-08-20 |
| 13 | 3730-del-2012-GPA-(10-01-2013).pdf | 2013-01-10 |