WO2020201898A1 - A system and method for effecting a transaction using a mobile communications device associated with a receiver of transaction information - Google Patents

A system and method for effecting a transaction using a mobile communications device associated with a receiver of transaction information Download PDF

Info

Publication number
WO2020201898A1
WO2020201898A1 PCT/IB2020/052684 IB2020052684W WO2020201898A1 WO 2020201898 A1 WO2020201898 A1 WO 2020201898A1 IB 2020052684 W IB2020052684 W IB 2020052684W WO 2020201898 A1 WO2020201898 A1 WO 2020201898A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
information
mobile communications
communications device
transaction information
Prior art date
Application number
PCT/IB2020/052684
Other languages
French (fr)
Inventor
Jacobus Johannes BOTES
Original Assignee
Authentiss Technologies (Pty) Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Authentiss Technologies (Pty) Ltd. filed Critical Authentiss Technologies (Pty) Ltd.
Publication of WO2020201898A1 publication Critical patent/WO2020201898A1/en
Priority to ZA2021/07296A priority Critical patent/ZA202107296B/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327Short range or proximity payments by means of M-devices
    • G06Q20/3276Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being read by the M-device
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825Use of electronic signatures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3827Use of message hashing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829Payment protocols; Details thereof insuring higher security of transaction involving key management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/42Confirmation, e.g. check or permission by the legal debtor of payment

Definitions

  • the present application relates to a system and method for effecting a transaction using a mobile communications device associated with a receiver of transaction information.
  • the transaction could be an on-line payment transaction but could also be any other type of suitable transaction to which the method may be applied.
  • a method for effecting a transaction using a mobile communications device associated with a user who is a receiver of transaction information comprising: receiving a data set on the mobile communications device, the data set containing at least metadata, transaction information, a transaction public key and a digital signature; verifying that the transaction public key has not expired; if the transaction public key has not expired, verifying the authenticity and integrity of the transaction information by checking the validity of the digital signature using the transaction public key with an identity-based digital signature scheme using known cryptographic system parameters and a master public key; if the digital signature is valid, verifying that the received transaction information is uniquely associated with a sender of the transaction information and the receiver of the transaction information by verifying a transaction association value, wherein the transaction association value is verified by: obtaining identification information of the sender from the transaction public key; obtaining identification information of the receiver from the received transaction information; calculating a transaction association value by hashing the identification information of the sender and receiver to obtain a transaction association value; retrieving from
  • a mobile communications device for effecting a transaction, the mobile communications device associated with a user who is a receiver of transaction information and comprising: a communications module for receiving a data set on the mobile communications device, the data set containing at least metadata, transaction information, a transaction public key and a digital signature; a processor for: verifying that the transaction public key has not expired; if the transaction public key has not expired, verifying the authenticity and integrity of the transaction information by checking the validity of the digital signature using the transaction public key with an identity-based digital signature scheme using known cryptographic system parameters and a master public key; if the digital signature is valid, verifying that the received transaction information is uniquely associated with a sender of the transaction information and the receiver of the transaction information by verifying a transaction association value, wherein the transaction association value is verified by: obtaining identification information of the sender from the transaction public key; obtaining identification information of the receiver from the received transaction information; calculating a transaction association value by hashing the identification information of the sender and receiver to obtain
  • Figure 1 is a block diagram illustrating a system for effecting a transaction using a mobile communications device associated with a receiver of transaction information
  • Figure 2 is a block diagram illustrating the server of Figure 1 in more detail
  • Figure 3 is a block diagram illustrating in more detail the system for effecting a transaction using a mobile communications device associated with a receiver of transaction information ;
  • Figure 4 is a block diagram illustrating one example implementation of the present invention.
  • Figure 5 is a block diagram illustrating another example implementation of the present invention.
  • Figures 6a show example messages displayed to a user of a mobile and 6b communications device
  • Figure 7 is a block diagram illustrating another example implementation of the present invention.
  • Figure 8 is a block diagram illustrating another example implementation of the present invention.
  • the transaction is typically conducted between two users with one user composing and sending transaction information and the other user receiving and reviewing the transaction information before initiating the transaction at a system operated by a banking or non-banking institution.
  • FIG. 1 the figure shows a central transaction server 10 that can be accessed via one or more communications networks 12.
  • the communications networks 12 will include the Internet as well as mobile communication networks depending on the specific implementation.
  • the server 10 has a non-transitory data-storage device in the form of database 14.
  • a plurality of users access the server 10 using computers 16 and/or mobile communications devices 18.
  • computers 16 could be one or more of laptop computers, desktop computers, tablet computers, Point of Sale (POS) device, mainframe computer, or any other suitable computing device.
  • POS Point of Sale
  • the mobile communications devices 18 could be mobile telephones, mobile tablet devices or any other suitable computing device with communication ability, preferably access to a GSM network.
  • some of the users that access the central transaction server 10 will be transaction information senders and some of the users will be transaction information receivers.
  • the server 10 includes a processor 20 which is operably coupled to the other illustrated components and controls the operation of the server.
  • a communications module 22 allows the server to communicate via communications networks 12 with the computers 16 and mobile communications devices 18.
  • the first step in the process is to obtain the relevant transaction information. This is obtained from a sender of transaction information using one of the computers 16 or mobile communications devices 18 to send the transaction information to the central server 10.
  • the transaction will now be described as a payment.
  • the transaction could be any other suitable transaction.
  • the sender of the transaction information will be a merchant requiring payment for goods or services and the central server will be a server of a financial institution such as a bank.
  • the sender will author transaction information to be authenticated. This will include at least some of the identity of the sender, an identity of the transaction information receiver, an identification of the goods and/or services for which payment is being made and an amount to be paid.
  • the sender will now use their computer 16 or mobile communication device 18 to request a digital signature over at least the transaction information, from a signature generation service 24 which may be located at a trusted authority.
  • a signature generation service 24 forms part of the central server 10.
  • the signature generation service 24 sits outside of the central server 10. Thus the signature generation service 24 will receive a signature request from the transaction information sender.
  • the signature generation service 24 may either be implemented as an online service, dedicated software service or a dedicated server which may consist of suitable computing equipment that contains a processor 26 (and circuitry) to execute processor instructions associated with a signature generation software program 28.
  • the signature generation service 24 may in turn be connected, through a short-lived or persistent secure network connection to one or more transaction information senders enrolled with the signature generation service 24.
  • a database 30 is used for storing credentials uniquely associated with each transaction information sender.
  • the signature generation service 24 may store, within secure storage 32, one or more key pairs consisting of a transaction private key 34 and transaction public key 36, generated by and received from a key generation server 38 which will be described in more details below.
  • the secure storage 32 may form part of the database 30 or may be separate therefrom as illustrated.
  • a key generation server 38 is typically associated with a trusted authority generally responsible for key generation and an example of a key generation server 38 is illustrated in Figure 3.
  • the key generation server 38 consists of suitable computing equipment that contains a processor (and circuitry) 40 to execute processor instructions associated with a key generation software program 42.
  • the key generation server 38 may be connected, through a secure network connection to one or more signature generation services 24 enrolled with the key generation server 38.
  • a database 44 is used for storing credentials uniquely associated with each enrolled signature generation service 24.
  • the key generation software program 42 has an initial once-off setup phase, when executing for the first time, during which a master public key 46 and master private key 48 are generated using known cryptographic system parameters associated with an Identity-Based Signature scheme.
  • the master public key 46 and master private key 48 are subsequently stored within a secure storage area 50, offering tamper resistance for active protection of secrets.
  • the key generation software 42 generates a transaction private key 34 in response to receiving a request from a uniquely identified signature generation service 24.
  • the transaction private key 34 is generated using the master private key 48 in conjunction with at least a user ID and usage period received as part of the request.
  • the user ID consists of a string unambiguously representing a user, for example a website URL, while the usage period represents a period of time for which the transaction private key should be valid.
  • a corresponding transaction public key 36 is formed by combining at least the user ID and usage period.
  • the key generation server 38 returns the transaction private key 34 and public key 36 to the signature generation service through a secure connection 12.
  • the signature generation software program 28 uses the transaction private key 34 to generate a digital signature on the transaction information received as part of a signature request from a uniquely identified transaction information sender.
  • the digital signature is computed using an Identity- Based Signature (IBS) scheme associated with known cryptographic system parameters and which relies on, for example, bilinear mappings.
  • IBS Identity- Based Signature
  • An IBS scheme is a type of public-key cryptography which eliminates the need for conventional public key certificates and associated Public Key Infrastructure (PKI), which includes the issuing and administration of public key certificates.
  • public keys consist of a publicly known string, which can be used to uniquely identify an individual, organization or computing entity, e.g. an e- mail address, a mobile number or a website URL.
  • this string essentially also serves as a user ID.
  • the digital signature and transaction public key, to be used for signature verification is returned through a secure connection to the transaction information sender using either a computer 16 or a mobile communications device 8.
  • the transaction information sender will now encode the information into a data set consisting of: metadata, transaction information, transaction public key and the digital signature.
  • the transaction data set is sent from the transaction information sender to the mobile communications device 18 of the transaction information receiver.
  • the transaction data set is transmitted from the transaction information sender to the transaction information receiver via a communications network.
  • the type of network used for interconnecting the elements depicted in Figure 3 may include, for example, the Internet, local area networks, wide area networks, public switched telephone networks, networks based on dedicated leased lines, wired or wireless networks, fibre- optic networks or any other suitable networking technology.
  • TLS Transport Layer Security
  • the transaction data set could be sent directly to the mobile communications device 18 of the receiver.
  • the transaction data set could be received on a separate computer of the receiver from where it will be transferred to the mobile communications device 18 of the receiver.
  • the transaction data set could be received in an executable application executing on the mobile communications device 18.
  • the transaction data set is formed into a 2D code that can be read using the mobile communications device 18 and particularly using a camera incorporated into the mobile communications device 18.
  • a 2D code is a Quick Response (QR) code.
  • the transaction data set is formed into a QR code and displayed to the transaction information receiver.
  • the sender of the transaction information may be off-line, in which case the merchant may invoice a customer for goods or services delivered by sending an invoice with the 2D-code printed on the invoice.
  • the merchant may also be online, in which case the online merchant may display the 2D-code on the checkout page of the online merchant web server.
  • the transaction information receiver will use their mobile communications device 18 to scan the QR code and thus obtain the transaction data.
  • the mobile communications device 18 includes a processor 52 which controls the operation of the mobile communications device 18.
  • a communications module 54 allows the mobile communications device to transmit and receive data.
  • Camera 56 allows the mobile communications device, for present purposes, to scan QR codes.
  • a user interface 58 allows the user to input commands into the mobile communication device.
  • the user interface 58 could be one or more of a key pad, external buttons or a touchscreen through which a user can input commands to the mobile communications device 18.
  • a display 60 is used to display information to the user.
  • a memory 62 is used to store data such that the memory 62 is secure against malicious tampering of data.
  • the transaction data set is received and the mobile communications device 18 in one of the many ways described above.
  • An executable application executing on the processor 52 controls the mobile communications device to process the transaction data as will be described below in order to effect the transaction described by the data.
  • the transaction public key is extracted and it is verified that the transaction public key has not expired.
  • the authenticity and integrity of the transaction information is verified by checking the validity of the digital signature using the transaction public key with an identity-based digital signature scheme using known cryptographic system parameters and a master public key.
  • the received transaction information is further processed to determine if the transaction information is uniquely associated with the sender of the transaction information and the receiver of the transaction information.
  • the executable application running on the processor 52 verifies the transaction association value by obtaining identification information in the form of a User ID of the sender from the transaction public key and obtaining identification information of the receiver from the received transaction information.
  • the processor 52 now calculates a transaction association value by hashing the identification information of the sender and receiver to obtain a transaction association value.
  • a list of previously stored approved transaction association values is next retrieved from the memory 62 of the mobile communications device.
  • the calculated transaction association value is compared with the values stored in the list to determine if the calculated value is found within the list.
  • the transaction association value is considered verified and the transaction information is displayed to the receiver via the display 60 of the mobile communications device 18.
  • the user will also be prompted via the display 60 to approve the transaction by inputting an approve command via the user interface 58.
  • An example of this could be displaying to the user two options, approve transaction and decline transaction, and requesting the user to select one.
  • the user input is received by the processor 52 via the user interface 58, and if the user input selected is to approve the transaction, the transaction information is transmitted from the mobile communications device 18 to a payment system 64 ( Figure 3) to effect the transaction.
  • a payment system 64 Figure 3
  • the payment system 64 of Figure 3 is the central server 10 of Figure 1 .
  • the transaction is cancelled by not transmitting the transaction information.
  • a notification is displayed to the user that the transaction has been cancelled. If the calculated transaction association value is not found within the retrieved list of transaction association values then one or more messages are displayed to the user via the display 60 of the mobile communications device 18.
  • the first message displayed asks the user if they want to proceed to approve a new transaction and if the user approves this then another message will be displayed to the user.
  • the next message displayed will display the transaction information to the user and that the transaction involves a new sender and/or receiver of transaction information, as well as identification information for both the sender and receiver which will be displayed together with a request for approval of this information.
  • the transaction information is transmitted from the mobile communications device 18 to a payment system 64 to effect the transaction and in this scenario the calculated transaction association value is added to the list of stored in the memory 62.
  • PIN Personal Identification Number
  • biometric data based on a fingerprint or facial recognition, for example.
  • the payment system 64 may be operated by a banking or non-banking institution and is used to settle transactions. A user obtains access to payment services, being an account holder at the institution.
  • the payment system 64 settles transactions by processing at processor 66 transaction information received from a transaction information receiver 18 over a secure network connection.
  • the payment system 64 may generate a notification providing proof of successful transaction execution, which is sent through a secure network connection to an instant notification service 68.
  • the instant notification service 68 offers instant notification for transactions such as payments where the original transaction information sender expects proof of payment before shipping goods sold or services rendered.
  • the instant notification service 68 may either be implemented as an online service or dedicated server, which may consist of suitable computing equipment that contains a processor (and circuitry) 72 to execute processor instructions associated with transaction notification software.
  • the instant notification service may be connected, through a secure network connection to one or more transaction information senders enrolled with the instant notification service and credentials stored in a database 74 accessible to the service.
  • a notification received from a payment system 64 is sent to the appropriate transaction information sender based on unique identification information contained within the notification.
  • a first embodiment of the invention allows an account holder holding an account at a bank, represented by bank server 64, to make an online purchase using a smartphone 18 while visiting an online store using a client computer 76.
  • the payment is made to an online merchant, represented by merchant web server 78, by way of a bank credit transfer using a banking software application (not shown) running on the smartphone 18.
  • the banking software application provides a secure wireless connection to the account holder’s Internet banking profile with the bank.
  • the banking software application furthermore has cryptographic and QR code scanning capabilities for scanning and reading transaction information from a QR code to initiate the bank credit transfer.
  • the bank server 64 operates a payment system based on Internet banking for settling transactions.
  • the merchant uses the web server 78 running a web application that offers a checkout page with payment transaction information, and serves as an embodiment of a transaction information sender.
  • the signature generation service 24, key generation server 38 and instant notification service 68 may be located at trusted authorities.
  • the trusted authority distributes once-off, cryptographic system parameters and master public key 44 to the bank server 64 and signature generation service 24.
  • the bank server 64 in turn integrates these cryptographic system parameters and master public key 44 with the banking software application running on smartphones 18, used by their banking customers to obtain secure wireless access to their Internet banking profiles.
  • the sequence of steps for the account holder making an online purchase or payment to the merchant, by way of a bank credit transfer from the account holder’s Internet banking profile, are as follows.
  • the account holder uses Internet browser software (not shown) running on a client computer 76 connected to the Internet to visit the online merchant web page hosted by the merchant web server 78.
  • Internet browser software (not shown) running on a client computer 76 connected to the Internet to visit the online merchant web page hosted by the merchant web server 78.
  • the account holder chooses to make a payment for items ordered from the online merchant.
  • the online merchant web server 78 requests, through a secure network connection with the signature generation service 24, a digital signature for transaction information suitable for performing a bank credit transfer from the account holder’s bank account to the merchant’s bank account.
  • Transaction information will at least include:
  • Merchant identification information to be used by the account holder for unique identification of the merchant to confirm that a funds transfer will be in favour of the intended merchant.
  • Merchant identification information may for example, consist of the merchant business name and merchant web site URL.
  • Reference information to identify the payment such as an online order number.
  • the signature generation service 24 generates an identity-based digital signature over the transaction information received from the uniquely identified online merchant, using a transaction private key 34 obtained from the key generation server 38.
  • the digital signature and transaction public key 36 to be used for signature verification are returned through a secure connection to the merchant server 78.
  • the merchant server 78 uses transaction composing software to compose secure authenticated transaction information consisting of, for example, metadata, transaction information, a transaction public key and a digital signature.
  • secure authenticated transaction information is encoded within a QR code and displayed on the checkout page.
  • the account holder receives the checkout page within a browser session running on the client computer 76.
  • the account holder uses smartphone 18 running a banking software application with access to an Internet banking profile, to scan the QR code displayed on the client computer 76 screen.
  • the banking software application scans the QR code as described and the verification process proceeds as has been described above.
  • the transaction public key is extracted and it is verified that the transaction public key has not expired.
  • the authenticity and integrity of the transaction information is verified by checking the validity of the digital signature using the transaction public key with an identity-based digital signature scheme using known cryptographic system parameters and a master public key as described.
  • the received transaction information is further processed to determine if the transaction information is uniquely associated with the sender of the transaction information and the receiver of the transaction information. This is done by verifying a transaction association value as has been described.
  • the executable application running on the processor 52 verifies the transaction association value by obtaining identification information of the sender from the transaction public key and obtaining identification information of the receiver from the received transaction information.
  • the processor 52 now calculates a transaction association value by hashing the identification information of the sender and receiver to obtain a transaction association value.
  • a list of previously stored approved transaction association values is next retrieved from the memory 62 of the mobile communications device.
  • the calculated transaction association value is compared with the values stored in the list to determine if the calculated value is found within the list.
  • the transaction association value is considered verified and the transaction information is displayed to the receiver via the display 60 of the mobile communications device 18.
  • the user will also be prompted via the display 60 to approve the transaction by inputting an approve command via the user interface 58.
  • the transaction is cancelled by not transmitting the transaction information to the bank server 64. In this case, a notification is displayed to the user that the transaction has been cancelled. If the calculated transaction association value is not found within the retrieved list of transaction association values then a message is displayed to the user via the display 60 of the mobile communications device 18.
  • the message will inform the user that the transaction involves a new sender and/or receiver of transaction information and identification information for both the sender and receiver will be displayed together with a request for approval of this information before continuing to display transaction information also for approval by the user.
  • transaction information is shown to the account holder to be approved or rejected, with an example shown in Figure 6a.
  • Information to be reviewed consists of the type of transaction 80 to be performed, merchant identification information 82, the amount due 84 to the merchant, optionally merchant bank account information and payment reference information 86, and a choice to reject 88 or approve 90 the transaction.
  • the account holder reviews the transaction information and approves by way of, for example, a PIN or biometric data based on fingerprint or facial recognition.
  • the banking software application running on the smartphone 18 transmits the transaction information to the bank server 64 over a secure wireless connection for transaction processing and execution at the bank.
  • the bank server 64 sends a proof-of-payment notice, containing at least transaction payment details combined with merchant identification information, to the notification service 68, over a secure network connection.
  • the notification service 68 uses the merchant identification information from the proof-of-payment notice to forward the notification to the merchant server 78 being paid.
  • the merchant server 78 upon receipt of the notice, recognises the payment based on reference information indicating the order number, and concludes the purchase made by the account holder through a message on the checkout page indicating that payment was received.
  • a variation of the secure authenticated transaction information encoded in a 2D-code may include using an electronic data message format or electronic file format to convey the authenticated transaction information instead of using a 2D-code and that this variation still falls within the scope of the invention.
  • a second embodiment of the invention employs a variation and allows an account holder holding an account at a bank, represented by bank server 64, to make an online purchase using the smartphone 18 while visiting an online store using an Internet browser application running on the same smartphone 18.
  • the payment is made to the online merchant, represented by merchant web server 78, by way of a bank credit transfer using a banking software application (not shown) running on the smartphone 18.
  • the banking software application receives the secure authenticated transaction information using an electronic data message format as opposed to scanning a QR code conveying the secure authenticated transaction information.
  • the account holder will use Internet browser software (not shown) running on a smartphone 18, wirelessly connected to the Internet to visit the online merchant web page hosted by the merchant web server 78.
  • the account holder chooses to make a payment for items ordered from the online merchant.
  • the online merchant 78 requests, through a secure network connection with the signature generation service 24, a digital signature for transaction information suitable for performing a bank credit transfer from the account holder’s bank account to the merchant’s bank account. This step is performed consistently with the corresponding step in the first embodiment.
  • the signature generation service 24 generates an identity-based digital signature over the transaction information received from the uniquely identified online merchant 78, using a transaction private key 34 obtained from the key generation server 24.
  • the digital signature and transaction public key 36 to be used for signature verification are returned through a secure connection to the merchant server 78.
  • the merchant server 78 uses transaction composing software to compose secure authenticated transaction information consisting of, for example, metadata, transaction information, a transaction public key 36 and a digital signature.
  • the web application running on the merchant web server 78 detects that a smartphone is used to visit the online store. Accordingly the secure authenticated transaction information is embedded in an electronic data message format that can be passed, in the form of a JavaScript object, from a web page payment button on the checkout page to a native smartphone banking software application.
  • the account holder receives the checkout page, containing the payment button, within a browser session running on the smartphone 18.
  • the secure authenticated transaction information is passed as a data message by, for example, using a JavaScript object, from the checkout page to the banking software application.
  • the banking software application reads the received data message to check that that the transaction public key 36 has not expired and that the digital signature verifies successfully using the transaction public key 36 obtained from the data message.
  • This process which includes transaction association value verification, is the same as has been described above with reference to the previous embodiment.
  • transaction information is shown to the account holder to be approved or rejected as shown in Figure 6a.
  • the account holder reviews the transaction information and approves by way of, for example, a PIN or biometric data based on fingerprint or facial recognition.
  • the banking software application running on the smartphone 18 transmits the transaction information to the bank server 64 over a secure wireless connection for transaction processing and execution at the bank.
  • the bank server 64 sends a proof-of-payment notice, containing at least transaction payment details combined with merchant identification information, to the notification service 68, over a secure network connection.
  • the notification service 68 uses the merchant identification information from the proof-of-payment notice to forward the notification to the merchant server 78 being paid.
  • the merchant server 78 upon receipt of the notice, recognises the payment based on reference information indicating the order number, and concludes the purchase made by the account holder through a message on the checkout page indicating that payment was received.
  • a third embodiment of the invention illustrated in Figure 8, allows an account holder holding an account at a bank, represented by bank server 64, to make a peer-to-peer payment to another account holder holding an account at another bank represented by bank server 92.
  • the payment is made by way of a bank credit transfer using a banking software application (not shown) running on each account holder’s smartphone 18.
  • the banking software application provides a secure wireless connection to each account holder’s Internet banking profile with banking servers 64 and 92 respectively.
  • the banking software application furthermore has cryptographic and QR code scanning capabilities for scanning and reading transaction information from a QR code to initiate the bank credit transfer.
  • the first account holder using smartphone 18a equipped with a camera 56 and running a banking software application with cryptographic and QR code scanning capabilities with a secure wireless connection to bank server 92, serves as an embodiment of a transaction information sender.
  • the first account holder with smartphone 18a uses the banking software application running on smartphone 18a to create a payment request which includes specifying the amount requested from the second account holder with smartphone 18b.
  • the banking software application on smartphone 18a requests, through a secure wireless network connection with bank server 92, a digital signature for transaction information suitable for receiving funds through a bank credit transfer from the bank account of the second account holder using smartphone 18b.
  • Transaction information will include one or more of:
  • Account holder identification information may for example consist of a mobile number.
  • the bank server 92 requests the digital signature, on behalf of the first account holder, from the signature generation service 24.
  • the signature generation service 24 generates an identity-based digital signature over the transaction information received from the uniquely identified bank server 92, using a transaction private key 34 obtained from the key generation server 24.
  • the digital signature and transaction public key 36 to be used for signature verification are returned through a secure connection.
  • the banking software application running on smartphone 18a receives the digital signature and transaction public 34 key from banking server 92 which is used to compose secure authenticated transaction information representing the payment request.
  • the secure authenticated transaction information may include, for example, metadata, transaction information, a transaction public key 36 and a digital signature.
  • the secure authenticated transaction information is encoded within a QR code, and displayed on the screen of smartphone 18a which is in turn displayed to the second account holder.
  • the second account holder using smartphone 18b running a banking software application scans the QR code presented on smartphone 18a.
  • the QR code is scanned, checking that that the transaction public key 36 has not expired and that the digital signature verifies successfully using the transaction public key 36 obtained from the QR code. This process is the same as has been described above with reference to the previous embodiment.
  • transaction information is shown to the second account holder via 18b to be approved or rejected.
  • the second account holder reviews the transaction information and approves by way of, for example, a PIN or biometric data based on fingerprint or facial recognition.
  • the banking software application running on smartphone 18b transmits the transaction information to bank server 64 over a secure wireless connection for transaction processing and making a credit transfer to the bank account belonging to the first account holder.
  • banking server 64 Upon successful transaction execution, banking server 64 creates a proof of payment notice. To ensure that the notice can be securely verified, bank server 64 also requests, from digital signature service 24, a digital signature for the notice.
  • the digital signature is computed over the transaction payment information using an identity-based digital signature scheme and transaction private key 34 obtained from the key generation server 24.
  • the digital signature and transaction public key 36, to be used for signature verification, are returned with the proof of payment notice through the secure connection with smartphone 18b.
  • the banking software application running on smartphone 18b composes secure authenticated transaction information consisting of, for example, metadata, the transaction payment information, a transaction public key and a digital signature received from the proof of payment notification.
  • the secure authenticated transaction information, representing proof of payment is encoded within a QR code displayed on the screen of smartphone 18b.
  • Account holder using smartphone 18a running a banking software application scans the QR code displayed on smartphone 18b.
  • transaction public key 36 obtained from the QR code transaction payment information is shown to account holder providing proof that the peer-to-peer payment was in fact successfully executed.
  • This embodiment of the invention is obviously not limited to the assumption that both account holders communicate face to face.
  • the embodiment would be equally relevant to account holders being far apart since the QR codes are protected against fraudulent modification and it would be quite easy to exchange the QR codes through other means such as GSM text messages or even instant messaging applications allowing instant communication over the Internet.
  • a variation of the latter embodiment of the invention may consist of excluding the amount to be paid from the payment request such that the remaining information within the secure authenticated transaction information can be used in a QR code as a way of sharing bank account information.
  • another embodiment of the invention may therefore be used by an account holder to add a new beneficiary (i.e. a recipient of funds) to his or her Internet banking profile, for purposes of future bank credit transfer(s) to be made by the account holder to the recipient.
  • a new beneficiary i.e. a recipient of funds
  • the account holder may scan this QR code from, for example, a printed utility bill or printed invoice displaying the QR code.
  • the sequence of steps for the account holder to add a new beneficiary to his or her Internet banking profile, are as follows.
  • the account holder uses a smartphone 18 running a banking software application to scan the QR code as described above, checking that that the transaction public key 36 has not expired and that the digital signature verifies successfully using the transaction public key 36 obtained from the QR code.
  • transaction information is shown to the account holder to be approved or rejected, with an example shown in Figure 6b.
  • Information to be reviewed consists of the type of transaction 94 to be performed, beneficiary identification information 96, beneficiary bank account information 98 and a choice to reject 100 or approve 102 the transaction.
  • the account holder reviews the transaction information and approves by way of, for example, a PIN or biometric data based on fingerprint or facial recognition.
  • the banking software application running on the smartphone 18 transmits the transaction information to the bank over a secure wireless connection for the beneficiary to be added to the account holder’s Internet banking account.
  • transaction information is digitally signed, in accordance with the invention, also protects the integrity and authenticity of information providing complete protection against any accidental or fraudulent changes which may occur due to malware in the browser used to visit an online merchant website.
  • a maximum level of convenience is made possible through a simple combination of actions consisting of: scanning a 2D-code, reviewing transaction information, approving a transaction to be executed through PIN or biometric data recognition.
  • a further benefit is the fact that the 2D-code conveying transaction information can be instantly verified through verification of the digital signature without a requirement for any external authentication service.
  • the advantage here is saving time in making yet another secure connection to such an authentication service, which is important as this connection time would prolong the time to conclude a purchase transaction. A longer transaction time would in turn diminish user experience.
  • a yet further variation of the invention for making a payment by way of a funds transfer from one bank account to another bank account, would be to substitute bank account information with a reference to bank account information, for example, a mobile number.
  • the payment or funds transfer may be effected by way of reference.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

A system and method for effecting a transaction using a mobile communications device of a user who is a receiver of transaction information are provided. The method comprises receiving a data set on the mobile communications device containing metadata, transaction information, a transaction public key and a digital signature. Verifying that the transaction public key has not expired and verifying the transaction information by checking the validity of the digital signature. If the digital signature is valid, verifying that the received transaction information is uniquely associated with a sender of the transaction information and the receiver of the transaction information by verifying a transaction association value. If the transaction association value is verified then displaying the transaction information to the user, receiving a user input to approve the transaction and transmitting the transaction information from the mobile communications device to a payment system to effect the transaction.

Description

A SYSTEM AND METHOD FOR EFFECTING A TRANSACTION USING A MOBILE COMMUNICATIONS DEVICE ASSOCIATED WITH A RECEIVER OF TRANSACTION INFORMATION
BACKGROUND OF THE INVENTION
The present application relates to a system and method for effecting a transaction using a mobile communications device associated with a receiver of transaction information.
The transaction could be an on-line payment transaction but could also be any other type of suitable transaction to which the method may be applied.
SUMMARY OF THE INVENTION
According to a first example embodiment there is provided a method for effecting a transaction using a mobile communications device associated with a user who is a receiver of transaction information, the method comprising: receiving a data set on the mobile communications device, the data set containing at least metadata, transaction information, a transaction public key and a digital signature; verifying that the transaction public key has not expired; if the transaction public key has not expired, verifying the authenticity and integrity of the transaction information by checking the validity of the digital signature using the transaction public key with an identity-based digital signature scheme using known cryptographic system parameters and a master public key; if the digital signature is valid, verifying that the received transaction information is uniquely associated with a sender of the transaction information and the receiver of the transaction information by verifying a transaction association value, wherein the transaction association value is verified by: obtaining identification information of the sender from the transaction public key; obtaining identification information of the receiver from the received transaction information; calculating a transaction association value by hashing the identification information of the sender and receiver to obtain a transaction association value; retrieving from a memory of the mobile communications device a list of previously stored approved transaction association values; comparing the calculated transaction association value with the values stored in the list; and if the calculated transaction association value is found within the list then verifying the transaction association value; if the transaction association value is verified then displaying the transaction information to the receiver via a display of the mobile communications device; receiving a user input to approve the transaction; and in response to receiving an approval user input, transmitting the transaction information from the mobile communications device to a payment system to effect the transaction. According to a second example embodiment there is provided a mobile communications device for effecting a transaction, the mobile communications device associated with a user who is a receiver of transaction information and comprising: a communications module for receiving a data set on the mobile communications device, the data set containing at least metadata, transaction information, a transaction public key and a digital signature; a processor for: verifying that the transaction public key has not expired; if the transaction public key has not expired, verifying the authenticity and integrity of the transaction information by checking the validity of the digital signature using the transaction public key with an identity-based digital signature scheme using known cryptographic system parameters and a master public key; if the digital signature is valid, verifying that the received transaction information is uniquely associated with a sender of the transaction information and the receiver of the transaction information by verifying a transaction association value, wherein the transaction association value is verified by: obtaining identification information of the sender from the transaction public key; obtaining identification information of the receiver from the received transaction information; calculating a transaction association value by hashing the identification information of the sender and receiver to obtain a transaction association value; retrieving from a memory of the mobile communications device a list of previously stored approved transaction association values; comparing the calculated transaction association value with the values stored in the list; and if the calculated transaction association value is found within the list then verifying the transaction association value; a display for displaying the transaction information to the receiver if the transaction association value is verified; a user interface for receiving a user input to approve the transaction; wherein in response to receiving an approval user input, the processor transmits the transaction information from the mobile communications device via the communications module to a payment system to effect the transaction.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 is a block diagram illustrating a system for effecting a transaction using a mobile communications device associated with a receiver of transaction information;
Figure 2 is a block diagram illustrating the server of Figure 1 in more detail;
Figure 3 is a block diagram illustrating in more detail the system for effecting a transaction using a mobile communications device associated with a receiver of transaction information ;
Figure 4 is a block diagram illustrating one example implementation of the present invention;
Figure 5 is a block diagram illustrating another example implementation of the present invention;
Figures 6a show example messages displayed to a user of a mobile and 6b communications device;
Figure 7 is a block diagram illustrating another example implementation of the present invention; and
Figure 8 is a block diagram illustrating another example implementation of the present invention.
DESCRIPTION OF EMBODIMENTS
Referring to the accompanying drawings, a system for effecting a transaction using a mobile communications device associated with a receiver of transaction information is illustrated.
The transaction is typically conducted between two users with one user composing and sending transaction information and the other user receiving and reviewing the transaction information before initiating the transaction at a system operated by a banking or non-banking institution.
Referring to Figure 1 , the figure shows a central transaction server 10 that can be accessed via one or more communications networks 12. The communications networks 12 will include the Internet as well as mobile communication networks depending on the specific implementation.
The server 10 has a non-transitory data-storage device in the form of database 14.
A plurality of users access the server 10 using computers 16 and/or mobile communications devices 18.
It will be appreciated that the computers 16 could be one or more of laptop computers, desktop computers, tablet computers, Point of Sale (POS) device, mainframe computer, or any other suitable computing device.
The mobile communications devices 18 could be mobile telephones, mobile tablet devices or any other suitable computing device with communication ability, preferably access to a GSM network.
It will also be appreciated that whilst only some users are illustrated, in a real world implementation there will be a large number of users.
As will be described in more detail below, some of the users that access the central transaction server 10 will be transaction information senders and some of the users will be transaction information receivers.
In any event, referring to Figure 2, the server 10 includes a processor 20 which is operably coupled to the other illustrated components and controls the operation of the server.
A communications module 22 allows the server to communicate via communications networks 12 with the computers 16 and mobile communications devices 18.
The first step in the process is to obtain the relevant transaction information. This is obtained from a sender of transaction information using one of the computers 16 or mobile communications devices 18 to send the transaction information to the central server 10.
For purposes of illustration, the transaction will now be described as a payment. However, the transaction could be any other suitable transaction.
In this illustrated example, the sender of the transaction information will be a merchant requiring payment for goods or services and the central server will be a server of a financial institution such as a bank.
The sender will author transaction information to be authenticated. This will include at least some of the identity of the sender, an identity of the transaction information receiver, an identification of the goods and/or services for which payment is being made and an amount to be paid.
For payment requests, it is a feature of the invention to further securely include bank account information as part of the transaction information to facilitate payment by way of a bank credit transfer. It should however be appreciated that the invention is not limited to this form of electronic payment.
The sender will now use their computer 16 or mobile communication device 18 to request a digital signature over at least the transaction information, from a signature generation service 24 which may be located at a trusted authority.
In the illustrated embodiment of Figure 2, a signature generation service 24 forms part of the central server 10.
Alternatively or in addition, as illustrated in Figure 3, the signature generation service 24 sits outside of the central server 10. Thus the signature generation service 24 will receive a signature request from the transaction information sender.
Referring to Figure 3, the signature generation service 24 may either be implemented as an online service, dedicated software service or a dedicated server which may consist of suitable computing equipment that contains a processor 26 (and circuitry) to execute processor instructions associated with a signature generation software program 28.
The signature generation service 24 may in turn be connected, through a short-lived or persistent secure network connection to one or more transaction information senders enrolled with the signature generation service 24.
A database 30 is used for storing credentials uniquely associated with each transaction information sender. The signature generation service 24 may store, within secure storage 32, one or more key pairs consisting of a transaction private key 34 and transaction public key 36, generated by and received from a key generation server 38 which will be described in more details below.
The secure storage 32 may form part of the database 30 or may be separate therefrom as illustrated.
A key generation server 38 is typically associated with a trusted authority generally responsible for key generation and an example of a key generation server 38 is illustrated in Figure 3.
It will be appreciated that there could be more than one key generation server 38, for instance each bank my act as a trusted authority with their own distinct key generation server 38. ln any event, the key generation server 38 consists of suitable computing equipment that contains a processor (and circuitry) 40 to execute processor instructions associated with a key generation software program 42.
The key generation server 38 may be connected, through a secure network connection to one or more signature generation services 24 enrolled with the key generation server 38.
A database 44 is used for storing credentials uniquely associated with each enrolled signature generation service 24. The key generation software program 42 has an initial once-off setup phase, when executing for the first time, during which a master public key 46 and master private key 48 are generated using known cryptographic system parameters associated with an Identity-Based Signature scheme.
The master public key 46 and master private key 48 are subsequently stored within a secure storage area 50, offering tamper resistance for active protection of secrets.
Henceforth, the key generation software 42 generates a transaction private key 34 in response to receiving a request from a uniquely identified signature generation service 24.
The transaction private key 34 is generated using the master private key 48 in conjunction with at least a user ID and usage period received as part of the request.
The user ID consists of a string unambiguously representing a user, for example a website URL, while the usage period represents a period of time for which the transaction private key should be valid.
A corresponding transaction public key 36 is formed by combining at least the user ID and usage period. The key generation server 38 returns the transaction private key 34 and public key 36 to the signature generation service through a secure connection 12.
The signature generation software program 28 uses the transaction private key 34 to generate a digital signature on the transaction information received as part of a signature request from a uniquely identified transaction information sender.
The digital signature is computed using an Identity- Based Signature (IBS) scheme associated with known cryptographic system parameters and which relies on, for example, bilinear mappings.
An IBS scheme is a type of public-key cryptography which eliminates the need for conventional public key certificates and associated Public Key Infrastructure (PKI), which includes the issuing and administration of public key certificates. In the IBS scheme, and Identity-Based Cryptography in general, public keys consist of a publicly known string, which can be used to uniquely identify an individual, organization or computing entity, e.g. an e- mail address, a mobile number or a website URL. Provided that the known string uniquely identifies an individual, organization or computing entity, this string essentially also serves as a user ID.
In any event, the digital signature and transaction public key, to be used for signature verification, is returned through a secure connection to the transaction information sender using either a computer 16 or a mobile communications device 8.
The transaction information sender will now encode the information into a data set consisting of: metadata, transaction information, transaction public key and the digital signature.
The transaction data set is sent from the transaction information sender to the mobile communications device 18 of the transaction information receiver. There are numerous ways in which this could occur and a few of these methods will now be described as it should be appreciated that other methods could equally be used without detracting from the heart of the invention.
In a first example illustrated in Figure 3, the transaction data set is transmitted from the transaction information sender to the transaction information receiver via a communications network.
It should be appreciated that the type of network used for interconnecting the elements depicted in Figure 3 may include, for example, the Internet, local area networks, wide area networks, public switched telephone networks, networks based on dedicated leased lines, wired or wireless networks, fibre- optic networks or any other suitable networking technology.
Where communication paths between elements require security, a secure network connection will be used offering both encryption and authentication, for example the Transport Layer Security (TLS) protocol.
In any event, where the communications network is a mobile communications network, the transaction data set could be sent directly to the mobile communications device 18 of the receiver.
Where the communications network is the Internet, the transaction data set could be received on a separate computer of the receiver from where it will be transferred to the mobile communications device 18 of the receiver.
Alternatively or in addition, the transaction data set could be received in an executable application executing on the mobile communications device 18.
In one example embodiment, the transaction data set is formed into a 2D code that can be read using the mobile communications device 18 and particularly using a camera incorporated into the mobile communications device 18. One example of a 2D code is a Quick Response (QR) code.
Using the example of a QR code, the transaction data set is formed into a QR code and displayed to the transaction information receiver.
This could be done electronically via the Internet for example or in a non electronics fashion such as being printed on an invoice.
Thus it will be appreciated that the sender of the transaction information (in this example a merchant creating a payment request) may be off-line, in which case the merchant may invoice a customer for goods or services delivered by sending an invoice with the 2D-code printed on the invoice. The merchant may also be online, in which case the online merchant may display the 2D-code on the checkout page of the online merchant web server.
In either case the transaction information receiver will use their mobile communications device 18 to scan the QR code and thus obtain the transaction data.
Referring to Figure 4, the mobile communications device 18 includes a processor 52 which controls the operation of the mobile communications device 18.
A communications module 54 allows the mobile communications device to transmit and receive data.
Camera 56 allows the mobile communications device, for present purposes, to scan QR codes.
A user interface 58 allows the user to input commands into the mobile communication device. The user interface 58 could be one or more of a key pad, external buttons or a touchscreen through which a user can input commands to the mobile communications device 18. A display 60 is used to display information to the user.
Finally, a memory 62 is used to store data such that the memory 62 is secure against malicious tampering of data.
As described above, the transaction data set is received and the mobile communications device 18 in one of the many ways described above.
An executable application executing on the processor 52 controls the mobile communications device to process the transaction data as will be described below in order to effect the transaction described by the data.
Firstly, the transaction public key is extracted and it is verified that the transaction public key has not expired.
If the transaction public key has not expired, the authenticity and integrity of the transaction information is verified by checking the validity of the digital signature using the transaction public key with an identity-based digital signature scheme using known cryptographic system parameters and a master public key.
Once it has been ascertained that the digital signature is valid, the received transaction information is further processed to determine if the transaction information is uniquely associated with the sender of the transaction information and the receiver of the transaction information.
This is done by verifying a transaction association value.
The executable application running on the processor 52 verifies the transaction association value by obtaining identification information in the form of a User ID of the sender from the transaction public key and obtaining identification information of the receiver from the received transaction information. The processor 52 now calculates a transaction association value by hashing the identification information of the sender and receiver to obtain a transaction association value.
A list of previously stored approved transaction association values is next retrieved from the memory 62 of the mobile communications device.
The calculated transaction association value is compared with the values stored in the list to determine if the calculated value is found within the list.
If the calculated value is found within the list, then the transaction association value is considered verified and the transaction information is displayed to the receiver via the display 60 of the mobile communications device 18.
The user will also be prompted via the display 60 to approve the transaction by inputting an approve command via the user interface 58.
An example of this could be displaying to the user two options, approve transaction and decline transaction, and requesting the user to select one.
The user input is received by the processor 52 via the user interface 58, and if the user input selected is to approve the transaction, the transaction information is transmitted from the mobile communications device 18 to a payment system 64 (Figure 3) to effect the transaction. It will be appreciated that the payment system 64 of Figure 3 is the central server 10 of Figure 1 .
If the user input received is to decline the transaction, the transaction is cancelled by not transmitting the transaction information.
In this case, a notification is displayed to the user that the transaction has been cancelled. If the calculated transaction association value is not found within the retrieved list of transaction association values then one or more messages are displayed to the user via the display 60 of the mobile communications device 18.
The first message displayed asks the user if they want to proceed to approve a new transaction and if the user approves this then another message will be displayed to the user.
The next message displayed will display the transaction information to the user and that the transaction involves a new sender and/or receiver of transaction information, as well as identification information for both the sender and receiver which will be displayed together with a request for approval of this information.
If the user input now selected is again to approve the transaction, the transaction information is transmitted from the mobile communications device 18 to a payment system 64 to effect the transaction and in this scenario the calculated transaction association value is added to the list of stored in the memory 62.
In all cases where the user selects to approve the transaction, they may be asked to input for example, a Personal Identification Number (PIN) or biometric data based on a fingerprint or facial recognition, for example.
Referring to Figure 3 and as mentioned above, if the user selects to approve the transaction the transaction information is transmitted to the payment system 64
The payment system 64 may be operated by a banking or non-banking institution and is used to settle transactions. A user obtains access to payment services, being an account holder at the institution. The payment system 64 settles transactions by processing at processor 66 transaction information received from a transaction information receiver 18 over a secure network connection.
Upon successful transaction execution, the payment system 64 may generate a notification providing proof of successful transaction execution, which is sent through a secure network connection to an instant notification service 68.
The instant notification service 68 offers instant notification for transactions such as payments where the original transaction information sender expects proof of payment before shipping goods sold or services rendered.
The instant notification service 68 may either be implemented as an online service or dedicated server, which may consist of suitable computing equipment that contains a processor (and circuitry) 72 to execute processor instructions associated with transaction notification software. The instant notification service may be connected, through a secure network connection to one or more transaction information senders enrolled with the instant notification service and credentials stored in a database 74 accessible to the service.
A notification received from a payment system 64 is sent to the appropriate transaction information sender based on unique identification information contained within the notification.
The above methodology will now be described with reference to three different transaction applications.
A first embodiment of the invention, illustrated in Figure 5, allows an account holder holding an account at a bank, represented by bank server 64, to make an online purchase using a smartphone 18 while visiting an online store using a client computer 76. The payment is made to an online merchant, represented by merchant web server 78, by way of a bank credit transfer using a banking software application (not shown) running on the smartphone 18.
The banking software application provides a secure wireless connection to the account holder’s Internet banking profile with the bank.
The banking software application furthermore has cryptographic and QR code scanning capabilities for scanning and reading transaction information from a QR code to initiate the bank credit transfer.
The bank server 64 operates a payment system based on Internet banking for settling transactions.
The account holder using smartphone 18, equipped with a camera 56 and running a banking software application with cryptographic and QR code scanning capabilities with a secure wireless connection to the bank server 64, serves as an embodiment of a transaction information receiver.
The merchant uses the web server 78 running a web application that offers a checkout page with payment transaction information, and serves as an embodiment of a transaction information sender.
The signature generation service 24, key generation server 38 and instant notification service 68 may be located at trusted authorities.
Assuming the key generation server 38 completed its initial setup phase, the trusted authority distributes once-off, cryptographic system parameters and master public key 44 to the bank server 64 and signature generation service 24.
The bank server 64 in turn integrates these cryptographic system parameters and master public key 44 with the banking software application running on smartphones 18, used by their banking customers to obtain secure wireless access to their Internet banking profiles. The sequence of steps for the account holder making an online purchase or payment to the merchant, by way of a bank credit transfer from the account holder’s Internet banking profile, are as follows.
The account holder uses Internet browser software (not shown) running on a client computer 76 connected to the Internet to visit the online merchant web page hosted by the merchant web server 78.
The account holder chooses to make a payment for items ordered from the online merchant.
The online merchant web server 78 requests, through a secure network connection with the signature generation service 24, a digital signature for transaction information suitable for performing a bank credit transfer from the account holder’s bank account to the merchant’s bank account.
Transaction information will at least include:
a. Merchant identification information, to be used by the account holder for unique identification of the merchant to confirm that a funds transfer will be in favour of the intended merchant. Merchant identification information may for example, consist of the merchant business name and merchant web site URL.
b. Merchant bank account information.
c. Reference information to identify the payment, such as an online order number.
d. The amount due to the merchant.
e. Receiver identification information.
The signature generation service 24 generates an identity-based digital signature over the transaction information received from the uniquely identified online merchant, using a transaction private key 34 obtained from the key generation server 38. The digital signature and transaction public key 36 to be used for signature verification are returned through a secure connection to the merchant server 78.
The merchant server 78 uses transaction composing software to compose secure authenticated transaction information consisting of, for example, metadata, transaction information, a transaction public key and a digital signature. The secure authenticated transaction information is encoded within a QR code and displayed on the checkout page.
The account holder receives the checkout page within a browser session running on the client computer 76.
The account holder uses smartphone 18 running a banking software application with access to an Internet banking profile, to scan the QR code displayed on the client computer 76 screen.
The banking software application scans the QR code as described and the verification process proceeds as has been described above.
Firstly, the transaction public key is extracted and it is verified that the transaction public key has not expired.
If the transaction public key has not expired, the authenticity and integrity of the transaction information is verified by checking the validity of the digital signature using the transaction public key with an identity-based digital signature scheme using known cryptographic system parameters and a master public key as described.
Once it has been ascertained that the digital signature is valid, the received transaction information is further processed to determine if the transaction information is uniquely associated with the sender of the transaction information and the receiver of the transaction information. This is done by verifying a transaction association value as has been described.
The executable application running on the processor 52 verifies the transaction association value by obtaining identification information of the sender from the transaction public key and obtaining identification information of the receiver from the received transaction information.
The processor 52 now calculates a transaction association value by hashing the identification information of the sender and receiver to obtain a transaction association value.
A list of previously stored approved transaction association values is next retrieved from the memory 62 of the mobile communications device.
The calculated transaction association value is compared with the values stored in the list to determine if the calculated value is found within the list.
If the calculated value is found within the list, then the transaction association value is considered verified and the transaction information is displayed to the receiver via the display 60 of the mobile communications device 18.
The user will also be prompted via the display 60 to approve the transaction by inputting an approve command via the user interface 58.
If the user input is received to approve the transaction, the transaction proceeds as will be described below.
If the user input received is to decline the transaction, the transaction is cancelled by not transmitting the transaction information to the bank server 64. In this case, a notification is displayed to the user that the transaction has been cancelled. If the calculated transaction association value is not found within the retrieved list of transaction association values then a message is displayed to the user via the display 60 of the mobile communications device 18.
The message will inform the user that the transaction involves a new sender and/or receiver of transaction information and identification information for both the sender and receiver will be displayed together with a request for approval of this information before continuing to display transaction information also for approval by the user.
As mentioned above, upon successful verification of the QR code, transaction information is shown to the account holder to be approved or rejected, with an example shown in Figure 6a.
Information to be reviewed consists of the type of transaction 80 to be performed, merchant identification information 82, the amount due 84 to the merchant, optionally merchant bank account information and payment reference information 86, and a choice to reject 88 or approve 90 the transaction.
The account holder reviews the transaction information and approves by way of, for example, a PIN or biometric data based on fingerprint or facial recognition.
In response to approval by the account holder, the banking software application running on the smartphone 18 transmits the transaction information to the bank server 64 over a secure wireless connection for transaction processing and execution at the bank.
In case of successful transaction execution, the bank server 64 sends a proof-of-payment notice, containing at least transaction payment details combined with merchant identification information, to the notification service 68, over a secure network connection. The notification service 68 in turn uses the merchant identification information from the proof-of-payment notice to forward the notification to the merchant server 78 being paid.
The merchant server 78, upon receipt of the notice, recognises the payment based on reference information indicating the order number, and concludes the purchase made by the account holder through a message on the checkout page indicating that payment was received.
It should be appreciated that a variation of the secure authenticated transaction information encoded in a 2D-code may include using an electronic data message format or electronic file format to convey the authenticated transaction information instead of using a 2D-code and that this variation still falls within the scope of the invention.
A second embodiment of the invention, illustrated in Figure 7, employs a variation and allows an account holder holding an account at a bank, represented by bank server 64, to make an online purchase using the smartphone 18 while visiting an online store using an Internet browser application running on the same smartphone 18.
Similarly to the previous embodiment, the payment is made to the online merchant, represented by merchant web server 78, by way of a bank credit transfer using a banking software application (not shown) running on the smartphone 18. But in contrast with the previous embodiment, the banking software application receives the secure authenticated transaction information using an electronic data message format as opposed to scanning a QR code conveying the secure authenticated transaction information.
In this example, the account holder will use Internet browser software (not shown) running on a smartphone 18, wirelessly connected to the Internet to visit the online merchant web page hosted by the merchant web server 78. The account holder chooses to make a payment for items ordered from the online merchant.
The online merchant 78 requests, through a secure network connection with the signature generation service 24, a digital signature for transaction information suitable for performing a bank credit transfer from the account holder’s bank account to the merchant’s bank account. This step is performed consistently with the corresponding step in the first embodiment. The signature generation service 24 generates an identity-based digital signature over the transaction information received from the uniquely identified online merchant 78, using a transaction private key 34 obtained from the key generation server 24. The digital signature and transaction public key 36 to be used for signature verification are returned through a secure connection to the merchant server 78.
The merchant server 78 uses transaction composing software to compose secure authenticated transaction information consisting of, for example, metadata, transaction information, a transaction public key 36 and a digital signature.
The web application running on the merchant web server 78 detects that a smartphone is used to visit the online store. Accordingly the secure authenticated transaction information is embedded in an electronic data message format that can be passed, in the form of a JavaScript object, from a web page payment button on the checkout page to a native smartphone banking software application.
The account holder receives the checkout page, containing the payment button, within a browser session running on the smartphone 18.
When the account holder presses the payment button, the secure authenticated transaction information is passed as a data message by, for example, using a JavaScript object, from the checkout page to the banking software application. The banking software application reads the received data message to check that that the transaction public key 36 has not expired and that the digital signature verifies successfully using the transaction public key 36 obtained from the data message. This process, which includes transaction association value verification, is the same as has been described above with reference to the previous embodiment.
Upon successful verification of the data message in the manner described above, transaction information is shown to the account holder to be approved or rejected as shown in Figure 6a.
The account holder reviews the transaction information and approves by way of, for example, a PIN or biometric data based on fingerprint or facial recognition. In response to approval by the account holder, the banking software application running on the smartphone 18 transmits the transaction information to the bank server 64 over a secure wireless connection for transaction processing and execution at the bank.
In case of successful transaction execution, the bank server 64 sends a proof-of-payment notice, containing at least transaction payment details combined with merchant identification information, to the notification service 68, over a secure network connection.
The notification service 68 in turn uses the merchant identification information from the proof-of-payment notice to forward the notification to the merchant server 78 being paid.
The merchant server 78, upon receipt of the notice, recognises the payment based on reference information indicating the order number, and concludes the purchase made by the account holder through a message on the checkout page indicating that payment was received. A third embodiment of the invention, illustrated in Figure 8, allows an account holder holding an account at a bank, represented by bank server 64, to make a peer-to-peer payment to another account holder holding an account at another bank represented by bank server 92.
The payment is made by way of a bank credit transfer using a banking software application (not shown) running on each account holder’s smartphone 18. The banking software application provides a secure wireless connection to each account holder’s Internet banking profile with banking servers 64 and 92 respectively.
The banking software application furthermore has cryptographic and QR code scanning capabilities for scanning and reading transaction information from a QR code to initiate the bank credit transfer.
The first account holder using smartphone 18a, equipped with a camera 56 and running a banking software application with cryptographic and QR code scanning capabilities with a secure wireless connection to bank server 92, serves as an embodiment of a transaction information sender.
The second account holder using smartphone 18b, equipped with a camera 56 and running a banking software application with cryptographic and QR code scanning capabilities with a secure wireless connection to the bank server 64, serves as an embodiment of a transaction information receiver.
The first account holder with smartphone 18a uses the banking software application running on smartphone 18a to create a payment request which includes specifying the amount requested from the second account holder with smartphone 18b.
The banking software application on smartphone 18a requests, through a secure wireless network connection with bank server 92, a digital signature for transaction information suitable for receiving funds through a bank credit transfer from the bank account of the second account holder using smartphone 18b.
Transaction information will include one or more of:
a. Identification information for the first account holder to be used by the second account holder for unique identification of the first account holder to confirm that a funds transfer will be in favour of the intended individual. Account holder identification information may for example consist of a mobile number.
b. The first account holder bank account information.
c. Reference information to identify the payment.
d. The amount requested.
The bank server 92 requests the digital signature, on behalf of the first account holder, from the signature generation service 24.
Hence, the signature generation service 24 generates an identity-based digital signature over the transaction information received from the uniquely identified bank server 92, using a transaction private key 34 obtained from the key generation server 24.
The digital signature and transaction public key 36 to be used for signature verification are returned through a secure connection.
The banking software application running on smartphone 18a receives the digital signature and transaction public 34 key from banking server 92 which is used to compose secure authenticated transaction information representing the payment request.
The secure authenticated transaction information may include, for example, metadata, transaction information, a transaction public key 36 and a digital signature. The secure authenticated transaction information is encoded within a QR code, and displayed on the screen of smartphone 18a which is in turn displayed to the second account holder.
The second account holder using smartphone 18b running a banking software application, scans the QR code presented on smartphone 18a.
The QR code is scanned, checking that that the transaction public key 36 has not expired and that the digital signature verifies successfully using the transaction public key 36 obtained from the QR code. This process is the same as has been described above with reference to the previous embodiment.
Upon successful verification of the QR code, transaction information is shown to the second account holder via 18b to be approved or rejected.
The second account holder reviews the transaction information and approves by way of, for example, a PIN or biometric data based on fingerprint or facial recognition. In response to approval by the account holder, the banking software application running on smartphone 18b transmits the transaction information to bank server 64 over a secure wireless connection for transaction processing and making a credit transfer to the bank account belonging to the first account holder.
Upon successful transaction execution, banking server 64 creates a proof of payment notice. To ensure that the notice can be securely verified, bank server 64 also requests, from digital signature service 24, a digital signature for the notice.
The digital signature is computed over the transaction payment information using an identity-based digital signature scheme and transaction private key 34 obtained from the key generation server 24. The digital signature and transaction public key 36, to be used for signature verification, are returned with the proof of payment notice through the secure connection with smartphone 18b.
The banking software application running on smartphone 18b composes secure authenticated transaction information consisting of, for example, metadata, the transaction payment information, a transaction public key and a digital signature received from the proof of payment notification. The secure authenticated transaction information, representing proof of payment, is encoded within a QR code displayed on the screen of smartphone 18b.
Account holder using smartphone 18a running a banking software application, scans the QR code displayed on smartphone 18b. Upon successful verification of the QR code, using the transaction public key 36 obtained from the QR code, transaction payment information is shown to account holder providing proof that the peer-to-peer payment was in fact successfully executed.
This embodiment of the invention is obviously not limited to the assumption that both account holders communicate face to face. The embodiment would be equally relevant to account holders being far apart since the QR codes are protected against fraudulent modification and it would be quite easy to exchange the QR codes through other means such as GSM text messages or even instant messaging applications allowing instant communication over the Internet.
It should be appreciated that a variation of the latter embodiment of the invention may consist of excluding the amount to be paid from the payment request such that the remaining information within the secure authenticated transaction information can be used in a QR code as a way of sharing bank account information.
Hence, another embodiment of the invention may therefore be used by an account holder to add a new beneficiary (i.e. a recipient of funds) to his or her Internet banking profile, for purposes of future bank credit transfer(s) to be made by the account holder to the recipient.
The account holder may scan this QR code from, for example, a printed utility bill or printed invoice displaying the QR code. The sequence of steps for the account holder to add a new beneficiary to his or her Internet banking profile, are as follows.
The account holder uses a smartphone 18 running a banking software application to scan the QR code as described above, checking that that the transaction public key 36 has not expired and that the digital signature verifies successfully using the transaction public key 36 obtained from the QR code.
Upon successful verification of the QR code, transaction information is shown to the account holder to be approved or rejected, with an example shown in Figure 6b.
Information to be reviewed consists of the type of transaction 94 to be performed, beneficiary identification information 96, beneficiary bank account information 98 and a choice to reject 100 or approve 102 the transaction.
The account holder reviews the transaction information and approves by way of, for example, a PIN or biometric data based on fingerprint or facial recognition. In response to approval by the account holder, the banking software application running on the smartphone 18 transmits the transaction information to the bank over a secure wireless connection for the beneficiary to be added to the account holder’s Internet banking account.
From these exemplary embodiments of the invention, it should be evident that the system and method for secure authentication of transaction information described above, eliminates the drawbacks associated with at least online payments when paying by way of a bank credit transfer. The user (or account holder) is completely relieved from the burden of manually entering transaction information such as bank account information, reference information and a purchase amount. This eliminates the risk of human error such as typing errors which typically occurs in typing long account numbers.
The fact that transaction information is digitally signed, in accordance with the invention, also protects the integrity and authenticity of information providing complete protection against any accidental or fraudulent changes which may occur due to malware in the browser used to visit an online merchant website.
A maximum level of convenience is made possible through a simple combination of actions consisting of: scanning a 2D-code, reviewing transaction information, approving a transaction to be executed through PIN or biometric data recognition.
Apart from an improved user experience offered by the invention, a further benefit is the fact that the 2D-code conveying transaction information can be instantly verified through verification of the digital signature without a requirement for any external authentication service. The advantage here is saving time in making yet another secure connection to such an authentication service, which is important as this connection time would prolong the time to conclude a purchase transaction. A longer transaction time would in turn diminish user experience.
An additional benefit is the fact that the 2D-code conveying transaction information can be verified through verification of the digital signature without requiring that a public key certificate be embedded in the 2D-code for purposes of verification. This results in a 2D-code which has a much lower density which in turn improves scanning speed and scanning reliability when a user uses a smartphone to scan the 2D-code.
It is conceivable that a user would avoid using a smartphone running an Internet banking application, to perform a credit transfer payment if required to manually enter a fair amount of transaction information. The simple reason being the risk of typing errors when using the small virtual keyboard associated with most smartphones. Such a user would most likely perform such a payment using a client computer and larger keyboard typically located at home or the office. With this invention, this problem is solved in the event that a 2D-code is available for making a payment using a smartphone. Hence, this invention introduces another benefit to the user in that the user can truly make payments on-the-go rather than being limited to specific locations for making payments.
It should be appreciated that where embodiments of the invention are described for making a payment by way of a funds transfer from one bank account to another bank account, that the invention is not limited to bank credit transfers. The invention would equally apply to for example, a bitcoin payment. In the latter case no bank is involved and the payment destination does not consist of a bank account details but rather a bitcoin address. So for a bitcoin payment, transaction information would for example consist of recipient identification information, such as a name and URL, a bitcoin address and the amount due. This type of variation therefore still falls within the scope of the invention.
A yet further variation of the invention, for making a payment by way of a funds transfer from one bank account to another bank account, would be to substitute bank account information with a reference to bank account information, for example, a mobile number. With this variation, the payment or funds transfer may be effected by way of reference.
The invention described in this specification is by way of exemplary embodiments only and it should be appreciated that several further modifications may be made and different configurations be used without departing from the scope of the invention as described in this specification.

Claims

CLAIMS:
1 . A method for effecting a transaction using a mobile communications device associated with a user who is a receiver of transaction information, the method comprising: receiving a data set on the mobile communications device, the data set containing at least metadata, transaction information, a transaction public key and a digital signature; verifying that the transaction public key has not expired; if the transaction public key has not expired, verifying the authenticity and integrity of the transaction information by checking the validity of the digital signature using the transaction public key with an identity-based digital signature scheme using known cryptographic system parameters and a master public key; if the digital signature is valid, verifying that the received transaction information is uniquely associated with a sender of the transaction information and the receiver of the transaction information by verifying a transaction association value, wherein the transaction association value is verified by: obtaining identification information of the sender from the transaction public key; obtaining identification information of the receiver from the received transaction information; calculating a transaction association value by hashing the identification information of the sender and receiver to obtain a transaction association value; retrieving from a memory of the mobile communications device a list of previously stored approved transaction association values; comparing the calculated transaction association value with the values stored in the list; and if the calculated transaction association value is found within the list then verifying the transaction association value; if the transaction association value is verified then displaying the transaction information to the receiver via a display of the mobile communications device; receiving a user input to approve the transaction; and in response to receiving an approval user input, transmitting the transaction information from the mobile communications device to a payment system to effect the transaction.
2. A method according to claim 1 where the method further includes, if the calculated transaction association value is not found within the retrieved list of transaction association values then displaying one or more messages to the user via the display of the mobile communications device, the message/s: informing the user that the transaction involves a new sender and/or receiver of transaction information; showing identification information for both the sender and receiver of transaction information and requesting approval of this information; receiving an approval user input; and transmitting the transaction information from the mobile communications device to a payment system to effect the transaction and adding the transaction association value to the list of approved transaction association values.
3. A method according to claim 1 or claim 2 wherein the transaction information includes one or more of:
a. Identification information for an account holder;
b. Account holder bank account information;
c. Reference information to identify the payment; and d. An amount requested to be paid.
4. A method according to claim 3 wherein the account holder identification information is a mobile number.
5. A method according to any preceding claim wherein the digital signature is generated by signature generation software which uses a transaction private key to generate a digital signature on the transaction information received as part of a signature request from a transaction information sender.
6. A method according to claim 5 wherein the digital signature is computed using an Identity- Based Signature (IBS) scheme.
7. A method according to any preceding claim wherein two options are displayed to the user, an approve transaction option and a decline transaction option, together with a prompt to the user to approve the transaction or decline the transaction.
8. A method according to claim 7 wherein if the user input received is to decline the transaction, the transaction is cancelled by not transmitting the transaction information and a notification is displayed to the user that the transaction has been cancelled.
9. A mobile communications device for effecting a transaction, the mobile communications device associated with a user who is a receiver of transaction information and comprising: a communications module for receiving a data set on the mobile communications device, the data set containing at least metadata, transaction information, a transaction public key and a digital signature; a processor for: verifying that the transaction public key has not expired; if the transaction public key has not expired, verifying the authenticity and integrity of the transaction information by checking the validity of the digital signature using the transaction public key with an identity-based digital signature scheme using known cryptographic system parameters and a master public key; if the digital signature is valid, verifying that the received transaction information is uniquely associated with a sender of the transaction information and the receiver of the transaction information by verifying a transaction association value, wherein the transaction association value is verified by: obtaining identification information of the sender from the transaction public key; obtaining identification information of the receiver from the received transaction information; calculating a transaction association value by hashing the identification information of the sender and receiver to obtain a transaction association value; retrieving from a memory of the mobile communications device a list of previously stored approved transaction association values; comparing the calculated transaction association value with the values stored in the list; and if the calculated transaction association value is found within the list then verifying the transaction association value; a display for displaying the transaction information to the receiver if the transaction association value is verified; a user interface for receiving a user input to approve the transaction; wherein in response to receiving an approval user input, the processor transmits the transaction information from the mobile communications device via the communications module to a payment system to effect the transaction.
10. A mobile communications device according to claim 9 wherein if the processor determines that the calculated transaction association value is not found within the retrieved list of transaction association values then displaying one or more messages to the user via the display of the mobile communications device, the message/s: informing the user that the transaction involves a new sender and/or receiver of transaction information; showing identification information for both the sender and receiver of transaction information and requesting approval of this information; receiving an approval user input; and transmitting the transaction information from the mobile communications device to a payment system to effect the transaction and adding the transaction association value to the list of approved transaction association values.
1 1. A mobile communications device according to claim 9 or claim 10 wherein the transaction information includes one or more of:
a. Identification information for an account holder;
b. Account holder bank account information;
c. Reference information to identify the payment; and d. An amount requested to be paid.
12. A mobile communications device according to claim 1 1 wherein the account holder identification information is a mobile number.
13. A mobile communications device according to any one of claims 9 to 12 wherein two options are displayed to the user via the display, an approve transaction and a decline transaction option, together with a prompt to the user to approve the transaction or decline the transaction.
14. A mobile communications device according to claim 13 wherein if the user input received is to decline the transaction, the transaction is cancelled by not transmitting the transaction information and a notification is displayed to the user that the transaction has been cancelled.
PCT/IB2020/052684 2019-03-29 2020-03-23 A system and method for effecting a transaction using a mobile communications device associated with a receiver of transaction information WO2020201898A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
ZA2021/07296A ZA202107296B (en) 2019-03-29 2021-09-28 A system and method for effecting a transaction using a mobile communications device associated with a receiver of transaction information

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
ZA201901957 2019-03-29
ZA2019/01957 2019-03-29

Publications (1)

Publication Number Publication Date
WO2020201898A1 true WO2020201898A1 (en) 2020-10-08

Family

ID=70190009

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2020/052684 WO2020201898A1 (en) 2019-03-29 2020-03-23 A system and method for effecting a transaction using a mobile communications device associated with a receiver of transaction information

Country Status (2)

Country Link
WO (1) WO2020201898A1 (en)
ZA (1) ZA202107296B (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210357915A1 (en) * 2018-12-30 2021-11-18 Tunnel International Inc. Methods, devices, and systems for secure payments
US11605045B2 (en) 2012-09-07 2023-03-14 MapMyld, Inc. Address exchange systems and methods

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6317729B1 (en) * 1997-04-08 2001-11-13 Linda J. Camp Method for certifying delivery of secure electronic transactions
US20070125840A1 (en) * 2005-12-06 2007-06-07 Boncle, Inc. Extended electronic wallet management
WO2010081218A1 (en) * 2009-01-13 2010-07-22 Neville Stephen W Secure protocol for transactions
US20140101036A1 (en) * 2012-10-10 2014-04-10 Mastercard International Incorporated Methods and systems for conducting remote point of sale transactions
US20140250008A1 (en) * 2013-03-01 2014-09-04 Symantec, Inc. Service assisted reliable transaction signing
US20150142670A1 (en) * 2013-11-20 2015-05-21 Sue Zloth Systems and methods for software based encryption

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6317729B1 (en) * 1997-04-08 2001-11-13 Linda J. Camp Method for certifying delivery of secure electronic transactions
US20070125840A1 (en) * 2005-12-06 2007-06-07 Boncle, Inc. Extended electronic wallet management
WO2010081218A1 (en) * 2009-01-13 2010-07-22 Neville Stephen W Secure protocol for transactions
US20140101036A1 (en) * 2012-10-10 2014-04-10 Mastercard International Incorporated Methods and systems for conducting remote point of sale transactions
US20140250008A1 (en) * 2013-03-01 2014-09-04 Symantec, Inc. Service assisted reliable transaction signing
US20150142670A1 (en) * 2013-11-20 2015-05-21 Sue Zloth Systems and methods for software based encryption

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11605045B2 (en) 2012-09-07 2023-03-14 MapMyld, Inc. Address exchange systems and methods
US20210357915A1 (en) * 2018-12-30 2021-11-18 Tunnel International Inc. Methods, devices, and systems for secure payments

Also Published As

Publication number Publication date
ZA202107296B (en) 2022-08-31

Similar Documents

Publication Publication Date Title
US20240305628A1 (en) Techniques for token proximity transactions
US20200336315A1 (en) Validation cryptogram for transaction
US11282074B2 (en) Automated application programming interface (API) system and method
US11989719B2 (en) Adaptable authentication processing
US20220318799A1 (en) Systems And Methods For Using A Transaction Identifier To Protect Sensitive Credentials
CN110612546B (en) Method and apparatus for digital asset account management
US20150294313A1 (en) Systems, apparatus and methods for improved authentication
CN109716373B (en) Cryptographically authenticated and tokenized transactions
AU2011207602B2 (en) Verification mechanism
WO2015199977A1 (en) Systems and methods providing payment transactions
US11716200B2 (en) Techniques for performing secure operations
WO2020201898A1 (en) A system and method for effecting a transaction using a mobile communications device associated with a receiver of transaction information
CN111937023B (en) Security authentication system and method
US12106288B2 (en) Authentication system and method
US20240242206A1 (en) User verification with digital tag
US20240333506A1 (en) Processing system using secret linked to multiple accounts

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20717279

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20717279

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 20717279

Country of ref document: EP

Kind code of ref document: A1

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205 DATED 06/05/2022)