WO2011018103A1 - Money transfer request - Google Patents

Money transfer request Download PDF

Info

Publication number
WO2011018103A1
WO2011018103A1 PCT/EP2009/060318 EP2009060318W WO2011018103A1 WO 2011018103 A1 WO2011018103 A1 WO 2011018103A1 EP 2009060318 W EP2009060318 W EP 2009060318W WO 2011018103 A1 WO2011018103 A1 WO 2011018103A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
user device
signed
service provider
private key
Prior art date
Application number
PCT/EP2009/060318
Other languages
French (fr)
Inventor
Robert Seidl
Michael Marhoefer
Markus Bauer-Hermann
Original Assignee
Nokia Siemens Networks Oy
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 Nokia Siemens Networks Oy filed Critical Nokia Siemens Networks Oy
Priority to PCT/EP2009/060318 priority Critical patent/WO2011018103A1/en
Publication of WO2011018103A1 publication Critical patent/WO2011018103A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates

Definitions

  • the present invention is directed to mobile payment mecha- nisms.
  • SMS payment involves a consumer sending a payment request via a short message service (SMS) message to a short code.
  • SMS short message service
  • a premium charge for sending this message is applied to the user's bill.
  • the supplier of goods or services (such as a merchant) is then informed that the charge has been applied and can provide the goods or service to the consumer.
  • Payment via call is similar to premium SMS payment and involves a consumer making a call to a premium telephone number, and being charged for the placement of that call.
  • the supplier of goods or services is informed when the appropriate charge has been applied and can then provide the goods or services to the consumer.
  • Direct payment involves a consumer entering credentials into a relevant website, and the supplier of goods or services sending confirmation information, perhaps using SMS, to the consumer .
  • the mechanisms described above are three of many mechanisms that are known for enabling remote payment for goods and services .
  • a problem associated with many known payment mechanisms is that the payment channels are insecure. Privacy related data (such as usernames, passwords, personal identity numbers (PINs) and transaction details) are often sent via such insecure channels and are therefore vulnerable to
  • the present invention seeks to address at least some of the problems outlined above.
  • a method for example, a method of paying
  • the first mes- sage portion includes details of a transaction (such as the goods/services concerned, price, currency, invoice number) and identification information regarding the service provider; signing the first message portion using a private key of the service provider to generate a first message; sending the first message to a user device (such as a mobile communication device) ; and receiving a second message from the user device, wherein: the second message includes the first mes- sage and a second message portion, the second message portion includes identification information for the user device, and at least the second message portion is signed using a private key of the user device.
  • the second message portion may include an indication that the payment request has been ac- cepted.
  • an apparatus such as a service provider, e.g. a car park entry system
  • a first processor adapted to generate a first message portion, wherein the first message portion includes details of a transaction (such as the goods/services concerned, price, currency, invoice number) and identification information regarding the apparatus
  • a second processor (such as an encryption device) adapted to sign the first message portion using a private key of the apparatus to generate a first message
  • a first output for out- putting the first message to a user device (such as a mobile communication device)
  • a first input for receiving a sec- ond message from the user device, wherein: the second message includes the first message and a second message portion, the second message portion includes identification information for the user device, and at least the second message portion is signed using a private key of the user device.
  • the appa- ratus may further comprise a second output for sending a third message to a charging system (such as a payment broker) , wherein the third message comprises the second message (the third message may be identical to the second message) .
  • a charging system such as a payment broker
  • the third message comprises the second message (the third message may be identical to the second message) .
  • the present invention enables a transaction request to be generated by a service provider, and an approval of that request to be generated by a user, with the request and the approval being signed by the service provider and the user respectively.
  • the use of signed messages enables insecure communication channels to be used, if desired.
  • the messages generated by the invention provide a detailed record of the transaction agreed to. Accordingly, a secure a traceable system for instructing mobile payment is provided.
  • the transaction and identification information of the first message portion may be concatenated prior to the first message portion being signed using the said private key of the service provider.
  • the second message comprises the first message concatenated with the signed second message portion.
  • the second message comprises the signed first message portion concatenated with the signed second message portion.
  • the second message comprises the first message concatenated with the second message portion, with the resulting concatenation being signed using said private key of said user device.
  • Such an arrangement is sometimes referred to as "cascading" the first and second message portions and is generally considered to be more secure than the concatenation arrangement discussed above .
  • a third message is sent to a charging system (such as a payment broker) , wherein the third message comprises the second message.
  • the third message may be identical to the second message; alternatively, the third message may differ from the second message, for example, the service provider may add details to the second message when generating the third message.
  • a fourth message may be received from the charging system, wherein the fourth message typically indicates whether the transaction has been completed and wherein the fourth message includes the third message.
  • the fourth message may comprise the third message and a fourth message portion, the fourth message portion including identification information for the charging system, wherein at least the fourth message portion is signed using a private key of the charging system.
  • the fourth message comprises the third message concatenated with the signed fourth message portion.
  • the fourth message comprises the third message concatenated with the fourth message portion, with the resulting concatenation being signed using said private key of said charging system.
  • a method comprising: receiving a first message at a user device (for example from a service provider, such as a car park entry device) , wherein the first message includes details of a transaction and the first message is signed us- ing a private key of a service provider that generated the first message; and generating a second message, wherein the second message comprises the first message and a second message portion, wherein the second message portion includes identification information for the user device, and at least the second message portion is signed using a private key of the user device.
  • an apparatus (such as a user device) comprising: a first input for receiving a first message from a service provider, wherein the first message includes details of a transaction and the first message is signed using a private key of the service provider; and a first processor for generating a second message, wherein the second message comprises the first message and a second message portion, wherein the second message portion includes identification information for the user device, and at least the second message portion is signed using a private key of the apparatus (i.e. a user de- vice); and a first output for outputting the second message.
  • the first message portion may include details of a transaction and identification information regarding the service provider that are concatenated prior to be signed by the pri- vate key of the service provider.
  • the second message comprises the first message concatenated with the signed second message portion.
  • the second message comprises the first message concatenated with the second message portion, with the resulting concatenation being signed using said private key of said user device.
  • Generating the second message may include interacting with the user. For example, the user may be prompted to indicate whether or not a requested transaction is accepted. Alternatively, or in addition, the user may be requested to enter identification details, such as a password or a PIN.
  • the invention may include receiving (typically from one or both of the service provider and the charging system) a confirmation message (typically indicating that the transaction is complete), wherein the confirmation message comprises: the second message and a fourth message portion, the fourth mes- sage portion including identification information for a charging system, wherein at least the fourth message portion is signed using a private key (such as a private key of the charging system) .
  • some forms of the present invention enable a transaction request to be generated by a service provider, an approval of that request to be generated by a user, and a confirmation that the transaction has been completed to be gen- erated by a charging system, with the request, the approval and the confirmation being signed by the service provider, the user and the charging system respectively.
  • the use of signed messages enables insecure communication channels to be used, if desired.
  • the messages generated by the invention provide a detailed record of the transaction carried out. Accordingly, a secure and traceable mechanism is provided for enabling mobile transactions.
  • a method comprising: receiving a message at a charging system, wherein the message comprises a first message portion and a second message portion, wherein the first message portion is generated by a service provider and includes details of a transaction and identification information regarding the service provider and is signed using a private key of the service provider, and wherein the second message portion includes identification information of a user device (which details may be concatenated) and wherein at least the second message portion is signed using a private key of the user de- vice; and completing, under the control of the charging system, the transaction defined in the details of the transaction.
  • the method may further comprise identifying an identity manager for the service provider from the identification information included in the first message portion and/or iden- tifying an identity manager for the user device from the identification information included in the second message portion; and obtaining further information regarding the service provider and/or the user device from the said identity manager (s), wherein the step of completing the transaction defined in the details of the transaction may include using the information obtained from the identity managers .
  • an apparatus (such as a charging system or a payment broker) comprising: a first input for receiving a message, wherein the message comprises a first message portion and a second message portion, wherein the first message portion is generated by a service provider and includes details of a transac- tion and identification information regarding the service provider and is signed using a private key of the service provider, and wherein the second message portion includes identification information of a user device and wherein at least the second message portion is signed using a private key of the user device; and a first processor adapted to complete, under the control of the charging system, the transaction defined in the details of the transaction.
  • the apparatus may further comprise a second processor adapted to identify an identity manager for the service provider from the identification information included in the first message portion and to identity an identity manager for the user device from the identification information included in the second message portion; and a third processor adapted to obtain further information regarding the service provider and the user device from the said identity managers, wherein the second processor completes the said transaction using information obtained from the identity managers.
  • the message comprises the signed first message portion concatenated with the signed second message portion.
  • the message comprises the signed first message portion concatenated with the second message portion, with the resulting concatenation being signed using said private key of said user device.
  • the invention may further comprise sending a confirmation message (typically to the service provider and/or the user device), the confirmation message comprising: the first message portion, signed by the private key of the service provider; the second message portion, wherein at least the second message portion is signed by the private key of the user device; and a third message portion, including identification information for the charging system, wherein at least the third message portion is signed using a private key of the charging system.
  • the charging system can be arranged to provide a confirmation that includes details of the transaction (signed by the service provider providing the goods or service concerned) , confirmation information (signed by the user device used to confirm the transaction) , and confirmation of the completion of the transaction (signed by the relevant payment broker) .
  • a record of the elements of the transaction, signed by the relevant parties to the transaction is generated and can be stored at the payment broker, user device and service provider, as desired.
  • the elements of the confirmation message are cascaded. In alternative forms of the invention, the elements of the confirmation message are concatenated.
  • inputs and outputs it is not essential that separate physical nodes are provided.
  • an input and an output may be provided as a single input/output node.
  • a first output and a second output may be provided as a single physical output or a first input and a second input may be provided as a single physical input.
  • processors it is not essential that separate processors are provided.
  • the functionality of a first and a second processor may be provided by a single processor, such as a general purpose central processor unit (CPU) of a particular device.
  • CPU central processor unit
  • a message comprising: a first portion generated and signed (typically using a private key of a service provider) , the first portion including transaction details and identification details for the service provider; and a second portion generated by a user device, the second portion including identification details for the user device (the second portion may additionally include an indication that the transaction is approved by a user of the user device) , wherein at least the second portion is signed using a private key of the user device.
  • the transaction details and identification details that make up the first portion of the message may be concatenated prior to be signed by the service provider .
  • the message comprises the signed first message portion concatenated with the signed second message portion.
  • the message comprises the signed first message portion concatenated with the second message portion, with the resulting concatenation being signed using said private key of said user device.
  • the message may further comprise a third portion generated and signed using a private key of a charging system (such as a payment broker) , wherein the third portion includes a confirmation that the transaction has been completed and includes identification details for the charging system and wherein at least the third portion is signed using a private key of the charging system.
  • the first, second and third message portions are each signed and the signed message portions are concatenated.
  • the message comprises the signed first message portion concatenated with the second message portion, with the resulting concatenation being signed using said private key of said user device, wherein the signed result is concatenated with the third message portion and that concatenation is signed using said private key of said charging system.
  • a computer program comprising: code for generating a first message portion at a service provider, wherein the first message portion includes details of a transaction and identification information regarding the service provider; code for signing the first message portion using a private key of the service provider to generate a first message; code for sending the first message to a user device; and code for receiving a second message from the user device, wherein: the second message includes the first message and a second message portion, the second message portion includes identification information for the user device, and at least the second message portion is signed using a private key of the user device.
  • the computer program may be a computer program product comprising a computer-readable medium bearing computer program code embodied therein for use with a computer.
  • a computer program comprising: code for receiving a first mes- sage at a user device, wherein the first message includes details of a transaction and the first message is signed using a private key of a service provider that generated the first message; and code for generating a second message, wherein the second message comprises the first message and a second message portion, wherein the second message portion includes identification information for the user device, and at least the second message portion is signed using a private key of the user device.
  • the computer program may be a computer program product comprising a computer-readable medium bearing computer program code embodied therein for use with a computer.
  • a computer program comprising: code for receiving a message at a charging system, wherein the message comprises a first message portion and a second message portion, wherein the first message portion is generated by a service provider and includes details of a transaction and identification information regarding the service provider and is signed using a private key of the service provider, and wherein the second message portion includes identification information of a user device and wherein at least the second message portion is signed using a private key of the user device; and code for completing the transaction defined in the details of the transaction.
  • the computer program may further comprise: code for identifying an identity manager for the service provider from the identification information included in the first message portion; code for identifying an identity manager for the user device from the identification information included in the second message portion; and code for obtaining further information regarding the service provider and the user device from the said identity managers .
  • the code for completing the said transaction may include using information ob- tained from the identity manager.
  • the computer program may be a computer program product comprising a computer-readable medium bearing computer program code embodied therein for use with a computer. Exemplary embodiments of the invention are described below, by way of example only, with reference to the following numbered schematic drawings.
  • Figure 1 is a block diagram of a system in accor- dance with an aspect of the present invention
  • FIG. 2 is a message sequence in accordance with an aspect of the present invention.
  • FIG. 3 is a block diagram of a system in accordance with an aspect of the present invention.
  • FIG. 4 is a message sequence in accordance with an aspect of the present invention.
  • Figure 5 is a message sequence in accordance with an aspect of the present invention.
  • Figure 1 is a block diagram of a system, indicated generally by the reference numeral 1, in accordance with an aspect of the present invention.
  • the system 1 comprises a user device 2, a service provider 4, a payment broker 6, an identity man- ager 8 for the user device, and an identity manager 10 for the service provider.
  • the service provider 4 requests payment for the provision of goods or services to the user device 2.
  • the user device 2 may, for example, be a mobile communication device.
  • the user device may be a computer, such as a laptop, connected to a network, such as the Internet.
  • the user device 2 approves the payment and the payment broker 6 is used to process the payment.
  • the payment broker uses the identity managers 8 and 10 when processing the payment instructions, as de- scribed in detail below.
  • Figure 2 is a message sequence, indicated generally by the reference numeral 20, showing an exemplary use of the system 1.
  • the message sequence 20 begins with a message 22 being sent from the service provider 4 to the user device 2.
  • the message 22 takes the form: ⁇ A + B ⁇ p KSP , where:
  • A provides details of the relevant transaction and typically includes some of: the amount of money requested, an indication of the goods or services being paid for, an in- dication of the currency of the requested payment, an invoice number etc.;
  • B may, for example, be a token identifying the entity.
  • An example of such a token is an information card;
  • PKSP is a private key of the service provider 4, used to sign the message A+B;
  • the user device 2 receives the message 22.
  • the user device 2 can use the public key of the service provider 4 to extract the message A + B and can therefore check that the details of the transaction, as given in the message A, are correct. If satisfied, the user confirms that the payment should be made.
  • the confirmation takes the form of: ⁇ C + D ⁇ PK ⁇ E , where:
  • C includes at least an indication that the payment request is accepted by the user.
  • C might include further information, such as an encoded token to retrieve further infor- mation, such as details of the bank account of the user;
  • D is used to identify the user of the user device.
  • D may, for example, be a token identifying the entity.
  • An example of such a token is an information card;
  • PKUE is a private key of the user device 2, used to sign the message C+D;
  • the confirmation may concatenated with the message 22 to provide a message 24 having the following form:
  • the confirmation may be cascaded with the message 22 to provide the message 24 having the following form:
  • the cascading procedure is generally considered to be more secure, since the public keys of both the service provider and the user device are required in order to extract the details of the transaction, as given in the message A.
  • the message 24 is forwarded to the payment broker 6 by the service provider 4 as message 26.
  • the payment broker 6 extracts the message elements B and D from the message 26 and uses those message elements to identify the identity managers 8 and 10 that can be used to identify the user device 2 and the service provider 4 respectively.
  • the payment broker 6 sends an assertion request 28 to the identity manager 8 for the user device.
  • the identity manager 8 identifies the user and provides an assertion response 30.
  • the payment broker 6 sends an assertion request 32 to the identity manager 10 for the service provider.
  • the identity manager 10 identifies the service provider and provides an assertion response 34.
  • the payment broker is able to use the identity managers 8 and 10 to resolve the identities of the user de- vice 2 and the service provider 4 respectively.
  • the identity managers 8 and 10 can also provide additional information to the payment broker concerning those entities. For example, the bank account details of the service provider 4 and the user of the user device 2 may be provided by the identity managers .
  • the transaction (as defined in the message element A) can then be processed by the payment broker 6 and the payment broker can add a result of the transaction to the message sequence.
  • the result message may take the following form:
  • F is used to identify the payment broker.
  • F may, for example, be a token identifying the entity.
  • An example of such a token is an information card;
  • PKPB is a private key of the payment broker 6, used to
  • the result of the transaction may be concatenated with the earlier messages, to generate the following final message:
  • the final message including the transaction information is sent from the payment broker 6 to the service provider 4 as message 36, and is also sent to the user device 2 as message 38.
  • both parties to the transaction receive a message, signed by all parties to the transaction, that can be decoded with the assistance of the relevant identity managers.
  • the present invention enables a message concerning a transaction to be generated, with different parties to the transaction preparing and signing portions of the message.
  • the use of signed messages enables insecure communication paths to be used, if desired.
  • the user and the service provider both receive the full message, they can both use the message at any time to confirm what was ordered, what payments were made, and who made and received the payments .
  • Figure 3 is a block diagram of a system, indicated generally by the reference numeral 40, demonstrating an exemplary use of the principles of the present invention.
  • the system 40 comprises a user device 42, similar to the user device 2, a user 43 of the user device 42, an entry device 44 (similar to the service provider 4), such as a device at the entrance to a car park that is requesting payment from the user 43, a charging system 46 (similar to the payment broker 6) , a bank 47 (or similar institution) for the user device, a bank 48 (or similar institution) for the entry device, an identity manger 49 for the user device (similar to the iden- tity manger 8) and an identity manager 50 for the entry device (similar to the identity manger 10) .
  • Figure 4 shows an exemplary message flow, indicated generally by the reference numeral 60, demonstrating an exemplary use of the system 40.
  • the message sequence 60 begins with the user 43 approaching the entry device 44. On detecting the presence of the user device 42, the entry device 44 sends a message 62 to the user device 42. The message 62 triggers the start of an applica- tion on the user device 42 for the payment of parking charges .
  • the message 62 is a charging request, and is similar to the message 22 described above. Accordingly, the message 62 may take the following format:
  • the transaction details may specify that a car park charge of 3 Euro is requested by the entry device 44;
  • ID details E u provides information (such as an information card) for identifying the user.
  • the identity details may, for example, enable a payment broker to obtain the bank account details for payment of the parking charge (as described further below) ;
  • PKED is a private key of the entry device 44
  • the user device 42 extracts the payment information from the message 62 using the public key of the entry device 44 and presents a message 64 to the user 43.
  • the message 64 presents the request for payment received from the entry device 44 to the user.
  • the message 64 may present the following message to the user 43:
  • the user confirms that payment should be made and an "OK" message 66 is returned to the user device 42.
  • the application on the user device 42 prompts the user to enter identification information, such as a password or personal identity number (PIN) , in a message 68.
  • identification information such as a password or personal identity number (PIN)
  • PIN personal identity number
  • the user device 42 (or the application running on that device) has received a payment request 62 from the entry device 44, a confirmation 66 that the payment should be made, and authentication information 70 from the user 43.
  • the user device 42 creates a message 72 for sending to the entry device 44.
  • the message 72 is similar to the message 24 described above. Accordingly, the message 72 may take the following form:
  • ID details ⁇ E is used to identify the user of the user device and may, for example, be an information card;
  • PKUE is a private key of the user device 42; • ⁇ +' indicates that the message elements are concatenated.
  • the confirmation may be cascaded with the message 62 to provide the message 72 having the following form:
  • the entry device On receipt of the message 72, the entry device sends a mes- sage 74 to the charging system 46 requesting that the payment (duly authorised by the user 43) be made.
  • the message 74 may be identical to the message 72, however this need not always be the case.
  • the entry device 44 might add further information to the received message 72 before providing the message 74.
  • the charging system 46 handles the transfer of the parking fee from the user device 42 to the entry device 44, as described below with reference to Figure 5.
  • the charging system 46 sends a confirmation message 76 to the entry device 44 and a confirmation message 78 to the user device 42 confirmation that payment has been duly made.
  • the user device 42 forwards the confirmation to the user 43.
  • the entry device 44 has received payment and the user can be provided with entry into the car park.
  • the messages 76 and 78 may take one of the following forms (although other forms are possible) :
  • ID detailscs may, for example, be a token identifying the entity.
  • An example of such a token is an information card;
  • PKCS is a private key of the charging system 46
  • the charging system 46 handles the transfer of parking fees from the user 43 to the owner of entry device 44. More specifically, in the present example, the charging system 46 handles the transfer of funds from the bank account 47 of the user to the bank account 48 of the entry device.
  • Figure 5 shows a message sequence, indicated generally by the reference numeral 90, showing a transfer of messages between the charging system 46, the bank 47 for the user of the user device, the bank 48 for the entry device, the identity manger 49 for the user device and the identity manager 50 for the entry device.
  • the charging system 46 receives message 74, which may have one of the following forms (although other forms are possible) :
  • the charging system 46 has transaction details and identification details of the parties to the transaction. In order to implement the requested transaction, further identification information is required. This can be obtained from the relevant identity managers.
  • the message sequence 90 starts with the charging system 46 sending a message 92 to the identity manager 49 for the user device requesting identity information regarding the user device 42 and/or the user 43.
  • the message 92 makes use of the identification details of the user device (ID details ⁇ E ) in- eluded in the message 74 to identify the identity manager 49 for the user device and to provide the user device with the information required to identify the user.
  • the message 92 could, for example, take the form of a SAML attribute request .
  • the identity manager 49 identifies the user device and provides the requested details.
  • the requested details may take many forms including, for example, details of a bank account from which the user's funds can be obtained (i.e. details of the bank account 47), a credit card number, or an online payment account number.
  • the charging system 46 sends a message 94 to the identity manager 50 for the entry device 44 requesting identity information regarding the entry device 44.
  • the message 94 makes use of the identification details of the entry device (ID details E D) included in the message 74 to identify the identity manager 50 for the entry device and to provide the user device with the information required to identify the user.
  • the message 94 could, for example, take the form of a SAML attribute request.
  • the identity manager 50 identifies the entry device and provides the requested details.
  • the requested details may take many forms including, for ex- ample, details of a bank account to which funds should be transferred (i.e. details of the bank account 48), a credit card number, or an online payment account number. These details are provided to the charging system in message 95 and could, for example, be provided in the form of a SAML asser- tion
  • the charging system 46 knows the details of the requested transaction and knows the bank account details of the paying party (the user device 42) and the receiving party (the entry device 44) . Accordingly, the charging system contacts the bank accounts 47 and 48 to request the transfer of funds; this may be achieved in a number of ways, one of which is outlined below. Of course, the skilled person will be aware of many alternatives fund transfer mecha- nisms that could be used.
  • the charging sequence sends a message 96 to the bank account 47 of the user device, requesting the transfer of funds to the bank account 48 for the entry device.
  • the message 96 includes details of the transaction and details of the bank account 48 and may be provided in a format suitable for a particular transaction mechanism, such as ebics (electronic banking Internet commu- nication standard) or SWIFT (Society for Worldwide Interbank Financial Telecommunication) .
  • the bank account 47 sends a message 97 to the bank account 48 to transfer the funds and the bank account 48 acknowledges receipt of the funds in message 98.
  • the bank account 47 for the user device sends a message 99 to the charging system 46 confirming that the transaction has been completed.
  • the charging system can then send the message 76 to the entry device 44 and the message 78 to the user device 42, as described above with reference to Figure 4.
  • the present invention has been described with reference to the payment of car parking fees. Of course, this is just one of many exemplary uses of the present invention.
  • the present invention has generally been described including message in accordance with the Security Assertion Markup Language (SAML) protocol. This is not essential. The skilled person will be aware of many alternatives to the SAML protocol that could be used to implement the present invention.
  • SAML Security Assertion Markup Language

Abstract

The invention relates to a mobile payment mechanism in which a user device, a service provider and a payment broker communicate with one another to complete a transaction. A message is generated concerning the transaction consisting of message portions generated and signed by each of the user device, service provider and payment broker. Accordingly, a secure and traceable mechanism is provided for enabling mobile payments.

Description

Money Transfer Request
The present invention is directed to mobile payment mecha- nisms.
A variety of mechanisms have been developed to enable the use of mobile communication devices and computers to make payments for goods and services. Known methods include the use of premium SMS messages, payment via call and direct payment.
Premium SMS payment involves a consumer sending a payment request via a short message service (SMS) message to a short code. A premium charge for sending this message is applied to the user's bill. The supplier of goods or services (such as a merchant) is then informed that the charge has been applied and can provide the goods or service to the consumer.
Payment via call is similar to premium SMS payment and involves a consumer making a call to a premium telephone number, and being charged for the placement of that call. The supplier of goods or services is informed when the appropriate charge has been applied and can then provide the goods or services to the consumer.
Direct payment involves a consumer entering credentials into a relevant website, and the supplier of goods or services sending confirmation information, perhaps using SMS, to the consumer .
The mechanisms described above are three of many mechanisms that are known for enabling remote payment for goods and services . A problem associated with many known payment mechanisms is that the payment channels are insecure. Privacy related data (such as usernames, passwords, personal identity numbers (PINs) and transaction details) are often sent via such insecure channels and are therefore vulnerable to
interception. Even if the transport protocol is encrypted, a malicious user or a receiving merchant could tamper with the data before it reaches a charging system or payment broker. Accordingly, the existing methods provide many options for malicious parties to misuse mobile or internet payment mechanisms for fraud, phishing or tracking of privacy or security data. A further problem is that many known payment methods require operation in a synchronous manner. This means either that the various required operations need to be completed whilst a particular remote connection is maintained, or that the various required operations need to be completed within a given time. This can present practical difficulties that can lead to the failure of some legitimate payment attempts .
The present invention seeks to address at least some of the problems outlined above.
In accordance with an aspect of the invention, there is provided a method (for example, a method of paying
for/completing a transaction) comprising: generating a first message portion at a service provider, wherein the first mes- sage portion includes details of a transaction (such as the goods/services concerned, price, currency, invoice number) and identification information regarding the service provider; signing the first message portion using a private key of the service provider to generate a first message; sending the first message to a user device (such as a mobile communication device) ; and receiving a second message from the user device, wherein: the second message includes the first mes- sage and a second message portion, the second message portion includes identification information for the user device, and at least the second message portion is signed using a private key of the user device. The second message portion may include an indication that the payment request has been ac- cepted.
In accordance with an aspect of the present invention, there is provided an apparatus (such as a service provider, e.g. a car park entry system) comprising: a first processor adapted to generate a first message portion, wherein the first message portion includes details of a transaction (such as the goods/services concerned, price, currency, invoice number) and identification information regarding the apparatus; a second processor (such as an encryption device) adapted to sign the first message portion using a private key of the apparatus to generate a first message; a first output for out- putting the first message to a user device (such as a mobile communication device) ; and a first input for receiving a sec- ond message from the user device, wherein: the second message includes the first message and a second message portion, the second message portion includes identification information for the user device, and at least the second message portion is signed using a private key of the user device. The appa- ratus may further comprise a second output for sending a third message to a charging system (such as a payment broker) , wherein the third message comprises the second message (the third message may be identical to the second message) . Thus, the present invention enables a transaction request to be generated by a service provider, and an approval of that request to be generated by a user, with the request and the approval being signed by the service provider and the user respectively. The use of signed messages enables insecure communication channels to be used, if desired. Furthermore, the messages generated by the invention provide a detailed record of the transaction agreed to. Accordingly, a secure a traceable system for instructing mobile payment is provided.
The transaction and identification information of the first message portion may be concatenated prior to the first message portion being signed using the said private key of the service provider.
In some forms of the invention, the second message comprises the first message concatenated with the signed second message portion. Thus, in such an arrangement, the second message comprises the signed first message portion concatenated with the signed second message portion.
In alternative forms of the invention, the second message comprises the first message concatenated with the second message portion, with the resulting concatenation being signed using said private key of said user device. Such an arrangement is sometimes referred to as "cascading" the first and second message portions and is generally considered to be more secure than the concatenation arrangement discussed above .
In some forms of the invention, a third message is sent to a charging system (such as a payment broker) , wherein the third message comprises the second message. The third message may be identical to the second message; alternatively, the third message may differ from the second message, for example, the service provider may add details to the second message when generating the third message. Furthermore, a fourth message may be received from the charging system, wherein the fourth message typically indicates whether the transaction has been completed and wherein the fourth message includes the third message. The fourth message may comprise the third message and a fourth message portion, the fourth message portion including identification information for the charging system, wherein at least the fourth message portion is signed using a private key of the charging system.
In some forms of the invention, the fourth message comprises the third message concatenated with the signed fourth message portion. In alternative forms of the invention, the fourth message comprises the third message concatenated with the fourth message portion, with the resulting concatenation being signed using said private key of said charging system. In accordance with an aspect of the invention, there is provided a method comprising: receiving a first message at a user device (for example from a service provider, such as a car park entry device) , wherein the first message includes details of a transaction and the first message is signed us- ing a private key of a service provider that generated the first message; and generating a second message, wherein the second message comprises the first message and a second message portion, wherein the second message portion includes identification information for the user device, and at least the second message portion is signed using a private key of the user device.
In accordance with an aspect of the invention, there is provided an apparatus (such as a user device) comprising: a first input for receiving a first message from a service provider, wherein the first message includes details of a transaction and the first message is signed using a private key of the service provider; and a first processor for generating a second message, wherein the second message comprises the first message and a second message portion, wherein the second message portion includes identification information for the user device, and at least the second message portion is signed using a private key of the apparatus (i.e. a user de- vice); and a first output for outputting the second message.
The first message portion may include details of a transaction and identification information regarding the service provider that are concatenated prior to be signed by the pri- vate key of the service provider.
In some forms of the invention, the second message comprises the first message concatenated with the signed second message portion. In alternative forms of the invention, the second message comprises the first message concatenated with the second message portion, with the resulting concatenation being signed using said private key of said user device.
Generating the second message may include interacting with the user. For example, the user may be prompted to indicate whether or not a requested transaction is accepted. Alternatively, or in addition, the user may be requested to enter identification details, such as a password or a PIN. The invention may include receiving (typically from one or both of the service provider and the charging system) a confirmation message (typically indicating that the transaction is complete), wherein the confirmation message comprises: the second message and a fourth message portion, the fourth mes- sage portion including identification information for a charging system, wherein at least the fourth message portion is signed using a private key (such as a private key of the charging system) .
Thus, some forms of the present invention enable a transaction request to be generated by a service provider, an approval of that request to be generated by a user, and a confirmation that the transaction has been completed to be gen- erated by a charging system, with the request, the approval and the confirmation being signed by the service provider, the user and the charging system respectively. The use of signed messages enables insecure communication channels to be used, if desired. Furthermore, the messages generated by the invention provide a detailed record of the transaction carried out. Accordingly, a secure and traceable mechanism is provided for enabling mobile transactions.
According to a further aspect of the invention, there is pro- vided a method comprising: receiving a message at a charging system, wherein the message comprises a first message portion and a second message portion, wherein the first message portion is generated by a service provider and includes details of a transaction and identification information regarding the service provider and is signed using a private key of the service provider, and wherein the second message portion includes identification information of a user device (which details may be concatenated) and wherein at least the second message portion is signed using a private key of the user de- vice; and completing, under the control of the charging system, the transaction defined in the details of the transaction. The method may further comprise identifying an identity manager for the service provider from the identification information included in the first message portion and/or iden- tifying an identity manager for the user device from the identification information included in the second message portion; and obtaining further information regarding the service provider and/or the user device from the said identity manager (s), wherein the step of completing the transaction defined in the details of the transaction may include using the information obtained from the identity managers .
According to an aspect of the invention, there is provided an apparatus (such as a charging system or a payment broker) comprising: a first input for receiving a message, wherein the message comprises a first message portion and a second message portion, wherein the first message portion is generated by a service provider and includes details of a transac- tion and identification information regarding the service provider and is signed using a private key of the service provider, and wherein the second message portion includes identification information of a user device and wherein at least the second message portion is signed using a private key of the user device; and a first processor adapted to complete, under the control of the charging system, the transaction defined in the details of the transaction. The apparatus may further comprise a second processor adapted to identify an identity manager for the service provider from the identification information included in the first message portion and to identity an identity manager for the user device from the identification information included in the second message portion; and a third processor adapted to obtain further information regarding the service provider and the user device from the said identity managers, wherein the second processor completes the said transaction using information obtained from the identity managers. In some forms of the invention, the message comprises the signed first message portion concatenated with the signed second message portion. In alternative forms of the invention, the message comprises the signed first message portion concatenated with the second message portion, with the resulting concatenation being signed using said private key of said user device.
The invention may further comprise sending a confirmation message (typically to the service provider and/or the user device), the confirmation message comprising: the first message portion, signed by the private key of the service provider; the second message portion, wherein at least the second message portion is signed by the private key of the user device; and a third message portion, including identification information for the charging system, wherein at least the third message portion is signed using a private key of the charging system. Thus, the charging system can be arranged to provide a confirmation that includes details of the transaction (signed by the service provider providing the goods or service concerned) , confirmation information (signed by the user device used to confirm the transaction) , and confirmation of the completion of the transaction (signed by the relevant payment broker) . Thus, a record of the elements of the transaction, signed by the relevant parties to the transaction, is generated and can be stored at the payment broker, user device and service provider, as desired.
In some forms of the invention, the elements of the confirmation message are cascaded. In alternative forms of the invention, the elements of the confirmation message are concatenated. In some of the aspects of the invention described above, reference has been made to inputs and outputs. Where multiple inputs or outputs are provided, it is not essential that separate physical nodes are provided. For example, an input and an output may be provided as a single input/output node. Similarly, a first output and a second output may be provided as a single physical output or a first input and a second input may be provided as a single physical input. Similarly, where multiple processors are described, it is not essential that separate processors are provided. For example, the functionality of a first and a second processor may be provided by a single processor, such as a general purpose central processor unit (CPU) of a particular device.
In accordance with a further aspect of the invention, there is provided a message comprising: a first portion generated and signed (typically using a private key of a service provider) , the first portion including transaction details and identification details for the service provider; and a second portion generated by a user device, the second portion including identification details for the user device (the second portion may additionally include an indication that the transaction is approved by a user of the user device) , wherein at least the second portion is signed using a private key of the user device. The transaction details and identification details that make up the first portion of the message may be concatenated prior to be signed by the service provider .
In some forms of the invention, the message comprises the signed first message portion concatenated with the signed second message portion. In alternative forms of the invention, the message comprises the signed first message portion concatenated with the second message portion, with the resulting concatenation being signed using said private key of said user device. The message may further comprise a third portion generated and signed using a private key of a charging system (such as a payment broker) , wherein the third portion includes a confirmation that the transaction has been completed and includes identification details for the charging system and wherein at least the third portion is signed using a private key of the charging system.
In some forms of the invention in which the message includes a third portion, the first, second and third message portions are each signed and the signed message portions are concatenated. In an alternative form of the invention in which the message includes a third portion, the message comprises the signed first message portion concatenated with the second message portion, with the resulting concatenation being signed using said private key of said user device, wherein the signed result is concatenated with the third message portion and that concatenation is signed using said private key of said charging system. According to an aspect of the invention, there is provided a computer program comprising: code for generating a first message portion at a service provider, wherein the first message portion includes details of a transaction and identification information regarding the service provider; code for signing the first message portion using a private key of the service provider to generate a first message; code for sending the first message to a user device; and code for receiving a second message from the user device, wherein: the second message includes the first message and a second message portion, the second message portion includes identification information for the user device, and at least the second message portion is signed using a private key of the user device. The computer program may be a computer program product comprising a computer-readable medium bearing computer program code embodied therein for use with a computer.
According to an aspect of the invention, there is provided a computer program comprising: code for receiving a first mes- sage at a user device, wherein the first message includes details of a transaction and the first message is signed using a private key of a service provider that generated the first message; and code for generating a second message, wherein the second message comprises the first message and a second message portion, wherein the second message portion includes identification information for the user device, and at least the second message portion is signed using a private key of the user device. The computer program may be a computer program product comprising a computer-readable medium bearing computer program code embodied therein for use with a computer.
According to an aspect of the invention, there is provided a computer program comprising: code for receiving a message at a charging system, wherein the message comprises a first message portion and a second message portion, wherein the first message portion is generated by a service provider and includes details of a transaction and identification information regarding the service provider and is signed using a private key of the service provider, and wherein the second message portion includes identification information of a user device and wherein at least the second message portion is signed using a private key of the user device; and code for completing the transaction defined in the details of the transaction. The computer program may further comprise: code for identifying an identity manager for the service provider from the identification information included in the first message portion; code for identifying an identity manager for the user device from the identification information included in the second message portion; and code for obtaining further information regarding the service provider and the user device from the said identity managers . The code for completing the said transaction may include using information ob- tained from the identity manager. The computer program may be a computer program product comprising a computer-readable medium bearing computer program code embodied therein for use with a computer. Exemplary embodiments of the invention are described below, by way of example only, with reference to the following numbered schematic drawings.
Figure 1 is a block diagram of a system in accor- dance with an aspect of the present invention;
Figure 2 is a message sequence in accordance with an aspect of the present invention;
Figure 3 is a block diagram of a system in accordance with an aspect of the present invention;
Figure 4 is a message sequence in accordance with an aspect of the present invention; and
Figure 5 is a message sequence in accordance with an aspect of the present invention. Figure 1 is a block diagram of a system, indicated generally by the reference numeral 1, in accordance with an aspect of the present invention. The system 1 comprises a user device 2, a service provider 4, a payment broker 6, an identity man- ager 8 for the user device, and an identity manager 10 for the service provider.
In the use of the system 1, the service provider 4 requests payment for the provision of goods or services to the user device 2. The user device 2 may, for example, be a mobile communication device. Alternatively, the user device may be a computer, such as a laptop, connected to a network, such as the Internet.
In response to the request for payment, the user device 2 approves the payment and the payment broker 6 is used to process the payment. The payment broker uses the identity managers 8 and 10 when processing the payment instructions, as de- scribed in detail below.
Figure 2 is a message sequence, indicated generally by the reference numeral 20, showing an exemplary use of the system 1.
The message sequence 20 begins with a message 22 being sent from the service provider 4 to the user device 2. The message 22 takes the form: {A + B}pKSP, where:
• A provides details of the relevant transaction and typically includes some of: the amount of money requested, an indication of the goods or services being paid for, an in- dication of the currency of the requested payment, an invoice number etc.;
• B refers to the entity requesting the payment request
(which may or may not be the same as the entity providing the goods or services in question) . B may, for example, be a token identifying the entity. An example of such a token is an information card;
• PKSP is a private key of the service provider 4, used to sign the message A+B;
• Λ+' indicates that the message elements are concatenated.
The user device 2 receives the message 22. The user device 2 can use the public key of the service provider 4 to extract the message A + B and can therefore check that the details of the transaction, as given in the message A, are correct. If satisfied, the user confirms that the payment should be made. The confirmation takes the form of: {C + D}PKϋE, where:
• C includes at least an indication that the payment request is accepted by the user. C might include further information, such as an encoded token to retrieve further infor- mation, such as details of the bank account of the user;
• D is used to identify the user of the user device. D may, for example, be a token identifying the entity. An example of such a token is an information card;
• PKUE is a private key of the user device 2, used to sign the message C+D;
• Λ+' indicates that the message elements are concatenated.
The confirmation may concatenated with the message 22 to provide a message 24 having the following form:
{ A + B } pKSp + { C + D } PKϋE Alternatively, the confirmation may be cascaded with the message 22 to provide the message 24 having the following form:
[{A + B}pKSp + {C + D}]PKϋE
The cascading procedure is generally considered to be more secure, since the public keys of both the service provider and the user device are required in order to extract the details of the transaction, as given in the message A.
The message 24 is forwarded to the payment broker 6 by the service provider 4 as message 26. The payment broker 6 extracts the message elements B and D from the message 26 and uses those message elements to identify the identity managers 8 and 10 that can be used to identify the user device 2 and the service provider 4 respectively.
On the basis of the message element D, the payment broker 6 sends an assertion request 28 to the identity manager 8 for the user device. The identity manager 8 identifies the user and provides an assertion response 30.
Similarly, on the basis of the message B, the payment broker 6 sends an assertion request 32 to the identity manager 10 for the service provider. The identity manager 10 identifies the service provider and provides an assertion response 34.
At this stage, the payment broker is able to use the identity managers 8 and 10 to resolve the identities of the user de- vice 2 and the service provider 4 respectively. The identity managers 8 and 10 can also provide additional information to the payment broker concerning those entities. For example, the bank account details of the service provider 4 and the user of the user device 2 may be provided by the identity managers .
The transaction (as defined in the message element A) can then be processed by the payment broker 6 and the payment broker can add a result of the transaction to the message sequence. The result message may take the following form:
{E + F } PKPB, where
• E reports the result of the transaction;
• F is used to identify the payment broker. F may, for example, be a token identifying the entity. An example of such a token is an information card;
• PKPB is a private key of the payment broker 6, used to
sign the message E+F;
• Λ+' indicates that the message elements are concatenated.
The result of the transaction may be concatenated with the earlier messages, to generate the following final message:
{A + B}pKSp + {C + D}PKϋE + {E + F} PKPB
Again, the message can be cascaded, rather than concatenated, to generate the following message:
{A + B}pKSp + {C + D}]PKϋE + {E + F}) PKPB
The final message, including the transaction information is sent from the payment broker 6 to the service provider 4 as message 36, and is also sent to the user device 2 as message 38. Thus, both parties to the transaction receive a message, signed by all parties to the transaction, that can be decoded with the assistance of the relevant identity managers.
Thus, the present invention enables a message concerning a transaction to be generated, with different parties to the transaction preparing and signing portions of the message. The use of signed messages enables insecure communication paths to be used, if desired. Furthermore, as the user and the service provider both receive the full message, they can both use the message at any time to confirm what was ordered, what payments were made, and who made and received the payments .
There are many potential uses of the present invention. One exemplary use is described below with reference to Figures 3 to 5.
Figure 3 is a block diagram of a system, indicated generally by the reference numeral 40, demonstrating an exemplary use of the principles of the present invention.
The system 40 comprises a user device 42, similar to the user device 2, a user 43 of the user device 42, an entry device 44 (similar to the service provider 4), such as a device at the entrance to a car park that is requesting payment from the user 43, a charging system 46 (similar to the payment broker 6) , a bank 47 (or similar institution) for the user device, a bank 48 (or similar institution) for the entry device, an identity manger 49 for the user device (similar to the iden- tity manger 8) and an identity manager 50 for the entry device (similar to the identity manger 10) .
In the use of the system 40, the user 43 approaches the entry device 44 on entry to the car park and uses the user device 42 to make a payment in order to use the car park. Figure 4 shows an exemplary message flow, indicated generally by the reference numeral 60, demonstrating an exemplary use of the system 40.
The message sequence 60 begins with the user 43 approaching the entry device 44. On detecting the presence of the user device 42, the entry device 44 sends a message 62 to the user device 42. The message 62 triggers the start of an applica- tion on the user device 42 for the payment of parking charges .
The message 62 is a charging request, and is similar to the message 22 described above. Accordingly, the message 62 may take the following format:
[Transaction details + ID detailsEu] PKED? where:
• "Transaction details" includes information such as the
amount of money requested and an indication of the service to be provided. Accordingly, the transaction details may specify that a car park charge of 3 Euro is requested by the entry device 44;
• "ID detailsEu" provides information (such as an information card) for identifying the user. The identity details may, for example, enable a payment broker to obtain the bank account details for payment of the parking charge (as described further below) ;
• PKED is a private key of the entry device 44;
• Λ+' indicates that the message elements are concatenated.
The user device 42 extracts the payment information from the message 62 using the public key of the entry device 44 and presents a message 64 to the user 43. The message 64 presents the request for payment received from the entry device 44 to the user. By way of example, the message 64 may present the following message to the user 43:
"Car park charge is 3 Euro. Do you wish to pay this charge?"
The user confirms that payment should be made and an "OK" message 66 is returned to the user device 42.
In response to the message 66, the application on the user device 42 prompts the user to enter identification information, such as a password or personal identity number (PIN) , in a message 68. The user 43 provides this information in a message 70.
At this stage, the user device 42 (or the application running on that device) has received a payment request 62 from the entry device 44, a confirmation 66 that the payment should be made, and authentication information 70 from the user 43. In response to receiving the message 70, the user device 42 creates a message 72 for sending to the entry device 44. The message 72 is similar to the message 24 described above. Accordingly, the message 72 may take the following form:
[Transaction details + ID detailsED] PKED + {Confirmation + ID
Figure imgf000021_0001
where
• "Confirmation" provides an indication that the payment re- quest is accepted by the user;
• "ID detailsϋE" is used to identify the user of the user device and may, for example, be an information card;
• PKUE is a private key of the user device 42; • Λ+' indicates that the message elements are concatenated.
Alternatively, the confirmation may be cascaded with the message 62 to provide the message 72 having the following form:
[{Transaction details + ID detailsED}pκED + {Confirmation + ID detailsϋE } ] PKUE
On receipt of the message 72, the entry device sends a mes- sage 74 to the charging system 46 requesting that the payment (duly authorised by the user 43) be made. The message 74 may be identical to the message 72, however this need not always be the case. For example, the entry device 44 might add further information to the received message 72 before providing the message 74.
On receipt of the message 74, the charging system 46 handles the transfer of the parking fee from the user device 42 to the entry device 44, as described below with reference to Figure 5.
Once the payment has been made, the charging system 46 sends a confirmation message 76 to the entry device 44 and a confirmation message 78 to the user device 42 confirmation that payment has been duly made. The user device 42 forwards the confirmation to the user 43. At this stage, the entry device 44 has received payment and the user can be provided with entry into the car park. The messages 76 and 78 may take one of the following forms (although other forms are possible) :
[Transaction details + ID detailsEu] PKED + {Confirmation + ID detailsϋE}pκuE + {Transaction complete + ID detailsCs IPKCS/ or ([{Transaction details + ID detailsED}pκED + {Confirmation + ID detailsϋE} ] PKUE + {Transaction complete + ID detailsCs} ) PKCS where:
• "Transaction complete" reports the result of the transaction;
• ID detailscs is used to identify the charging system 46.
ID detailscs may, for example, be a token identifying the entity. An example of such a token is an information card;
• PKCS is a private key of the charging system 46;
• Λ+' indicates that the message elements are concatenated.
The charging system 46 handles the transfer of parking fees from the user 43 to the owner of entry device 44. More specifically, in the present example, the charging system 46 handles the transfer of funds from the bank account 47 of the user to the bank account 48 of the entry device. Figure 5 shows a message sequence, indicated generally by the reference numeral 90, showing a transfer of messages between the charging system 46, the bank 47 for the user of the user device, the bank 48 for the entry device, the identity manger 49 for the user device and the identity manager 50 for the entry device.
As described above, the charging system 46 receives message 74, which may have one of the following forms (although other forms are possible) :
[Transaction details + ID detailsED] PKED + {Confirmation + ID detailsϋE}pκuE; or [{Transaction details + ID detailsED}pκED + {Confirmation + ID detailsϋE } ] PKUE•
Accordingly, the charging system 46 has transaction details and identification details of the parties to the transaction. In order to implement the requested transaction, further identification information is required. This can be obtained from the relevant identity managers. The message sequence 90 starts with the charging system 46 sending a message 92 to the identity manager 49 for the user device requesting identity information regarding the user device 42 and/or the user 43. The message 92 makes use of the identification details of the user device (ID detailsϋE) in- eluded in the message 74 to identify the identity manager 49 for the user device and to provide the user device with the information required to identify the user. The message 92 could, for example, take the form of a SAML attribute request .
In response to the message 92, the identity manager 49 identifies the user device and provides the requested details. The requested details may take many forms including, for example, details of a bank account from which the user's funds can be obtained (i.e. details of the bank account 47), a credit card number, or an online payment account number.
These details are provided to the charging system in message 93, and could, for example, be provided in the form of a SAML assertion .
In a similar way, the charging system 46 sends a message 94 to the identity manager 50 for the entry device 44 requesting identity information regarding the entry device 44. The message 94 makes use of the identification details of the entry device (ID detailsED) included in the message 74 to identify the identity manager 50 for the entry device and to provide the user device with the information required to identify the user. The message 94 could, for example, take the form of a SAML attribute request.
In response to the message 94, the identity manager 50 identifies the entry device and provides the requested details. The requested details may take many forms including, for ex- ample, details of a bank account to which funds should be transferred (i.e. details of the bank account 48), a credit card number, or an online payment account number. These details are provided to the charging system in message 95 and could, for example, be provided in the form of a SAML asser- tion
At this stage, the charging system 46 knows the details of the requested transaction and knows the bank account details of the paying party (the user device 42) and the receiving party (the entry device 44) . Accordingly, the charging system contacts the bank accounts 47 and 48 to request the transfer of funds; this may be achieved in a number of ways, one of which is outlined below. Of course, the skilled person will be aware of many alternatives fund transfer mecha- nisms that could be used.
As shown in the message sequence 90, the charging sequence sends a message 96 to the bank account 47 of the user device, requesting the transfer of funds to the bank account 48 for the entry device. The message 96 includes details of the transaction and details of the bank account 48 and may be provided in a format suitable for a particular transaction mechanism, such as ebics (electronic banking Internet commu- nication standard) or SWIFT (Society for Worldwide Interbank Financial Telecommunication) .
In response to the message 96, the bank account 47 sends a message 97 to the bank account 48 to transfer the funds and the bank account 48 acknowledges receipt of the funds in message 98.
Next, the bank account 47 for the user device sends a message 99 to the charging system 46 confirming that the transaction has been completed. The charging system can then send the message 76 to the entry device 44 and the message 78 to the user device 42, as described above with reference to Figure 4.
The present invention has been described with reference to the payment of car parking fees. Of course, this is just one of many exemplary uses of the present invention. The present invention has generally been described including message in accordance with the Security Assertion Markup Language (SAML) protocol. This is not essential. The skilled person will be aware of many alternatives to the SAML protocol that could be used to implement the present invention.
The embodiments of the invention described above are illustrative rather than restrictive. It will be apparent to those skilled in the art that the above devices and methods may incorporate a number of modifications without departing from the general scope of the invention. It is intended to include all such modifications within the scope of the invention insofar as they fall within the scope of the appended claims .

Claims

CLAIMS :
1. A method comprising:
generating a first message portion at a service pro- vider, wherein the first message portion includes details of a transaction and identification information regarding the service provider;
signing the first message portion using a private key of the service provider to generate a first message;
sending the first message to a user device; and receiving a second message from the user device, wherein: the second message includes the first message and a second message portion, the second message portion includes identification information for the user device, and at least the second message portion is signed using a private key of the user device.
2. A method as claimed in claim 1, wherein the second message comprises the first message concatenated with the signed second message portion.
3. A method as claimed in claim 1, wherein the second message comprises the first message concatenated with the second message portion, with the resulting concatenation being signed using said private key of said user device.
4. A method as claimed in any one of claims 1 to 3, further comprising sending a third message to a charging system, wherein the third message comprises the second message.
5. A method as claimed in claim 4, further comprising receiving a fourth message from the charging system, wherein the fourth message includes the third message.
6. A method as claimed in claim 5, wherein the fourth message comprises the third message and a fourth message portion, the fourth message portion including identification information for the charging system, wherein at least the fourth message portion is signed using a private key of the charging system.
7. A method comprising:
receiving a first message at a user device, wherein the first message includes details of a transaction and the first message is signed using a private key of a service provider that generated the first message; and
generating a second message, wherein the second message comprises the first message and a second message portion, wherein the second message portion includes identification information for the user device, and at least the second message portion is signed using a private key of the user device .
8. A method as claimed in claim 7, further comprising receiving a confirmation message, wherein the confirmation message comprises: the second message and a fourth message portion, the fourth message portion including identification information for a charging system, wherein at least the fourth message portion is signed using a private key.
9. A method comprising:
receiving a message at a charging system, wherein the message comprises a first message portion and a second mes- sage portion, wherein the first message portion is generated by a service provider and includes details of a transaction and identification information regarding the service provider and is signed using a private key of the service provider, and wherein the second message portion includes identifica- tion information of a user device and wherein at least the second message portion is signed using a private key of the user device; and
completing, under the control of the charging sys- tern, the transaction defined in the details of the transaction .
10. A method as claimed in claim 9, further comprising:
identifying an identity manager for the service pro- vider from the identification information included in the first message portion;
identifying an identity manager for the user device from the identification information included in the second message portion; and
obtaining further information regarding the service provider and the user device from the said identity managers, wherein, completing the transaction includes using information obtained from the identity managers.
11. A method as claimed in claim 9 or claim 10, further comprising sending a confirmation message, the confirmation message comprising:
the first message portion, signed by the private key of the service provider;
the second message portion, wherein at least the second message portion is signed by the private key of the user device; and
a third message portion, including identification information for the charging system, wherein at least the third message portion is signed using a private key of the charging system.
12. An apparatus comprising: a first processor adapted to generate a first message portion, wherein the first message portion includes details of a transaction and identification information regarding the apparatus;
a second processor adapted to sign the first message portion using a private key of the apparatus to generate a first message;
a first output for outputting the first message to a user device; and
a first input for receiving a second message from the user device, wherein: the second message includes the first message and a second message portion, the second message portion includes identification information for the user device, and at least the second message portion is signed using a private key of the user device.
13. An apparatus comprising:
a first input for receiving a message, wherein the message comprises a first message portion and a second message portion, wherein the first message portion is generated by a service provider and includes details of a transaction and identification information regarding the service provider and is signed using a private key of the service provider, and wherein the second message portion includes identification information of a user device and wherein at least the second message portion is signed using a private key of the user device; and
a first processor adapted to complete the transaction defined in the details of the transaction.
14. An apparatus as claimed in claim 13, further comprising:
a second processor adapted to identify an identity manager for the service provider from the identification information included in the first message portion and to iden- tity an identity manager for the user device from the identification information included in the second message portion;
a third processor adapted to obtain further information regarding the service provider and the user device from the said identity managers; and
wherein the second processor is adapted to use information obtained from the identity managers when completing the said transaction.
15. A message comprising:
a first portion generated by a service provider, the first portion including transaction details and identification details for the service provider; and
a second portion generated by a user device, the second portion including identification details for the user device, wherein the first portion is signed using a private key of the service provider and at least the second portion is signed using a private key of the user device.
16. A message as claimed in claim 15, further comprising a third portion generated by a charging system, wherein the third portion includes a confirmation that the transaction has been completed and includes identification details for the charging system and wherein at least the third portion is signed using a private key of the charging system.
17. A computer program product comprising:
means for generating a first message portion at a service provider, wherein the first message portion includes details of a transaction and identification information regarding the service provider;
means for signing the first message portion using a private key of the service provider to generate a first message; means for sending the first message to a user device; and
means for receiving a second message from the user device, wherein: the second message includes the first message and a second message portion, the second message portion includes identification information for the user device, and at least the second message portion is signed using a private key of the user device.
18. A computer program product comprising:
means for receiving a message at a charging system, wherein the message comprises a first message portion and a second message portion, wherein the first message portion is generated by a service provider and includes details of a transaction and identification information regarding the service provider and is signed using a private key of the service provider, and wherein the second message portion includes identification information of a user device and wherein at least the second message portion is signed using a private key of the user device; and
means for completing the transaction defined in the details of the transaction.
PCT/EP2009/060318 2009-08-10 2009-08-10 Money transfer request WO2011018103A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2009/060318 WO2011018103A1 (en) 2009-08-10 2009-08-10 Money transfer request

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2009/060318 WO2011018103A1 (en) 2009-08-10 2009-08-10 Money transfer request

Publications (1)

Publication Number Publication Date
WO2011018103A1 true WO2011018103A1 (en) 2011-02-17

Family

ID=42060760

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2009/060318 WO2011018103A1 (en) 2009-08-10 2009-08-10 Money transfer request

Country Status (1)

Country Link
WO (1) WO2011018103A1 (en)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5671279A (en) * 1995-11-13 1997-09-23 Netscape Communications Corporation Electronic commerce using a secure courier system

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5671279A (en) * 1995-11-13 1997-09-23 Netscape Communications Corporation Electronic commerce using a secure courier system

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"SET Secure Electronic Transaction Specification, Book 1: Business Description", INTERNET CITATION, 31 May 1997 (1997-05-31), XP002100669, Retrieved from the Internet <URL:HTTP://WWW.SETCO.ORG/DOWNLOAD.HTML> [retrieved on 19990420] *

Similar Documents

Publication Publication Date Title
AU2021200521B2 (en) Systems and methods for device push provisioning
CN107438992B (en) Integration of browser and password
US9818112B2 (en) Method and system for payment authorization and card presentation using pre-issued identities
US7003497B2 (en) System and method for confirming electronic transactions
US8417637B2 (en) Approving the use of the source of funds
US20200058028A1 (en) Data security system using mobile communications device
JP6242809B2 (en) Electronic check-based payment system and method for issuing, transferring, paying and verifying electronic checks
US20130073463A1 (en) Issuer trusted party system
CN109716373B (en) Cryptographically authenticated and tokenized transactions
CN104838399A (en) Authenticating remote transactions using mobile device
CN105264558A (en) Method and system for conducting pre-authorized financial transactions
AU2001271968A1 (en) System and method for verifying a financial instrument
KR20190043117A (en) Method for payment based on blockchain and payment server using the same
WO2016088087A1 (en) Third party access to a financial account
CN111062717B (en) Data transfer processing method, device and computer readable storage medium
CN104200365A (en) Writing and paying method for electronic check
KR20110114872A (en) System and method for unified authorization
TW201317911A (en) Cloud credit card transaction system and transaction method thereof
WO2014032206A1 (en) Quick payment system and corresponding method
US11481766B2 (en) Method for payment authorization on offline mobile devices with irreversibility assurance
KR20110107311A (en) A transaction system and mehod using mobile network, computer program therefor
US20200097968A1 (en) System and logic to convert an existing online bank transfer transaction
CN111052671A (en) System for secure authentication of user identity in an electronic system for banking transactions
WO2022154789A1 (en) Token-based off-chain interaction authorization
CN113837762B (en) Digital currency payment method and device

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: 09781650

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: 09781650

Country of ref document: EP

Kind code of ref document: A1