SYSTEM AND METHODS FOR USING LIMIT-USE ENCRYPTED CODE TO TRANSFER VALUES SECURELY AMONG USERS

Abstract

A system and method for facilitating a secured value transfer. A first user and the system obtain a pair of encryption and decryption apparatuses. The first user creates a request including his unique identifier and a value to be transferred. The first user encrypts the request using the encryption apparatus and sends it to the second user. The second user sends to the system the request and the second user's unique identifier. The system uses the decryption apparatus to decrypt the request. The system checks the usage of the request against a threshold limit. After a successful usage check, the system then transfers the value from the first user to the second user. The system may comprise (a) a plurality of system server for exchanging data with users' personal computing devices, registering users, and conducting transactions, and (b) data storages storing user accounts and other persistent data.

Claims

1. A method of facilitating secured value transfer among users using limit-use code, comprising: creating, by a first device of a provider, an encryption apparatus and a decryption apparatus that is capable of decrypting data encrypted by the encryption apparatus; transmitting, by the first device of the provider, a first unique identifier of the provider and the decryption apparatus to a server; storing by the server, the decryption apparatus in association with the first unique identifier of the provider; creating, by the first device of the provider, a request containing at least a reference to value to be transferred to a recipient; encrypting, by the provider device, the request using the encryption apparatus; attaching, by the provider device, the first unique identifier of the provider to the encrypted request; transmitting the encrypted request and the attached first unique identifier of the provider to a second device of the recipient; transmitting, by the second device of the recipient to the server, the encrypted request and the attached first unique identifier of the provider along with a second unique identifier of the recipient; retrieving, by the server the decryption apparatus associated with the first unique identifier of the provider; decrypting, the encrypted request using the decryption apparatus associated with the first unique identifier of the provider; determining, by the server, that the request satisfies a usage limit; validating, by the server, the request based at least in part on the determination that the request satisfies the usage limit; transferring, by the server, the value from the provider to the recipient using the reference included in the request.

2. The method of claim 1, further comprising: wherein creating, by the first device of the provider, a request containing at least a reference to value to be transferred to a recipient, further comprises enclosing in the request data whereby the request can be uniquely identified by at least a portion of content of the request; before determining, by the server, that the request satisfies a usage limit checking, using at least the portion of the content of the request as a reference to retrieve a usage record of the request; creating a usage record of the request, if a usage record of the request has not been created; wherein determining, by the server, that the request satisfies a usage limit comprises determining, by the server, that the usage record of the request does not exceed a usage limit; and, updating the usage record of the request.

3. The method of claim 1, further comprising: wherein creating, by a first device of a provider, an encryption apparatus and a decryption apparatus that is capable of decrypting data encrypted by the encryption apparatus, comprises generating, by the first device of the provider, a pair of encryption and decryption keys based on a cryptography algorithm; wherein transmitting, by the first device of the provider, a first unique identifier of the provider and the decryption apparatus to a server, comprises transmitting, by the first device of the provider, a first unique identifier of the provider and the decryption key to a server; wherein storing by the server, the decryption apparatus in association with the first unique identifier of the provider, comprises storing by the server, the decryption key in association with the first unique identifier of the provider; wherein encrypting, by the provider device, the request using the encryption apparatus, comprises encrypting, by the provider device, the request using the cryptography algorithm and the encryption key; wherein retrieving, by the server the decryption apparatus associated with the first unique identifier of the provider, comprises retrieving, by the server the decryption key associated with the first unique identifier of the provider; wherein decrypting, the encrypted request using the decryption apparatus associated with the first unique identifier of the provider, comprises decrypting, the encrypted request using the cryptography algorithm and the decryption key associated with the first unique identifier of the provider.

4. The method of claim 3, wherein the encryption algorithm is a symmetric algorithm, and the encryption key and decryption key are a same.

5. The method of claim 1, further comprising: prior to creating a request by the provider, registering, by the provider a Personal Identification Number (PIN) with the server; requesting, by the second device of the recipient, the PIN from the provider; receiving, by the second device of the recipient, the PIN from the provider; sending, by the second device of the recipient, the PIN to the server, and wherein determining, by the server, that the request satisfies a usage limit, further comprises determining whether the PIN received from the second device of the recipient matches the PIN registered by the provider with the server.

6. The method of claim 1, wherein the usage limit is defined as the expiration date of a request, the method further comprising, wherein determining by the server that the request satisfies a usage limit, comprises determining by the server that the time of the request is no later than the expiration date of the request.

7. The method of claim 1, further comprises, wherein creating, by the first device of the provider, a request containing at least a reference to value to be transferred to a recipient, further comprises enclosing in the request a limit limiting value to be transferred to the recipient, and; wherein determining, by the server, that the request satisfies a usage limit, further comprises determining, by the server, that the request satisfies the limit enclosed in the request.

8. The method of claim 7, further comprising: wherein transmitting, by the second device of the recipient to the server, the encrypted request received from the first device of the provider and a second unique identifier of the recipient, further comprises transmitting, by the second device of the recipient to the server, a reference to value to be requested by the recipient; and, wherein determining, by the server, that the request satisfies the limit enclosed in the request, comprises determining that the value requested by the recipient does not exceed the limit enclosed in the request.

9. The method of claim 1, further comprising: prior to determining, by the server, that the request satisfies a usage limit, registering a set of rules, by the provider or the recipient, with the server, wherein a rule of the set of rules limits value to be transferred; and wherein determining, by the server, that the request satisfies a usage limit, further comprises determining, by the server, whether the request satisfies the set of rules.

10. The method of claim 1, wherein the value to be transferred is a data record.

11. The method of claim 10, further comprising: validating, by a third user, a data record; registering, by the third user with the server, the validated record; sending to the provider device, the reference to the validated record; wherein creating, by the first device of the provider, a request containing at least a reference to value to be transferred to a recipient, comprises creating, by the first device of the provider, a request containing at least the reference to the validated record; and wherein transferring, by the server, the value from the provider to the recipient using the reference included in the request, comprises transferring the validated record to the recipient.

12. The method of claim 1, wherein transmitting the encrypted request and the attached first unique identifier of the provider to a second device of the recipient comprises, encoding, by the first device of the provider, the encrypted request and the attached first unique identifier of the provider in a graphic code; scanning and decoding, by the second device of the recipient, the graphic code.

13. The method of claim 12, further comprising displaying the graphic code on the first device of the provider.

14. The method of claim 12, further comprising printing the graphic code on a medium visible to the second device of the recipient.

15. The method of claim 1, wherein the server also serves as a communication gateway between the first device of the provider and the second device of the recipient.

16. The method of claim 1, wherein transmitting the encrypted request and the attached first unique identifier of the provider to a second device of a recipient comprises is carried out in electrical, electromagnetic, or optional signals carrying information on a plurality of wired or wireless network.

17. The method of claim 1, wherein the transmission of the encrypted request to the recipient device is carried out in accordance with Near Field Communication protocol using provider and recipient devices capable of conducting Near Field Communication.

18. The method of claim 1, further comprising: registering by a recipient with the server a coupon that presets value to be transferred; presenting the coupon to the provider; wherein creating, by the first device of the provider, a request containing at least a reference to value to be transferred to a recipient, comprises creating, by the first device of the provider, a request containing at least a reference to the coupon; wherein determining, by the server, that the request satisfies a usage limit, comprises retrieving the coupon using the reference to the coupon contained in the request, and determining, by the server, that the value presetted by the coupon satisfies a usage limit.

19. The method of claim 1, further comprising: computing, by the provider device, a digest of a plain text to be attached to the encrypted request; when creating a request by the provider device, enclosing in the request the digest; after encrypting the request by the provider device, attaching the plain text to the encrypted request; and wherein validating, by the server, the request based at least in part on the determination that the request satisfies the usage limit after decrypting the encrypted request by the server, further comprises verifying, by the server, the digest in the request by computing a second digest of the plain text attached to the encrypted request, and comparing the second digest with the digest in the request.

20. The method of claim 19, further comprising accessing, by the recipient, the plain text attached to the request.

21. The method of claim 20, wherein the plain text specifies terms for the value transfer and the recipient decides whether to proceed with the value transfer at least in part based on the plain text accessed by the recipient.

22. The method of claim 1, further comprising: after transferring by the server the value from the provider to the recipient using the reference included in the request, creating by the server a plurality of tickets and marking the provider as the owner of these tickets.

23. The method of claim 1, further comprising: retrieving from the server the references of tickets under the provider's possession; wherein creating, by the first device of the provider, a request containing at least a reference to value to be transferred to a recipient, comprises creating, by the first device of the provider, a reference to a ticket that the provider selects to transfer; and, wherein transferring, by the server, the value from the provider to the recipient using the reference included in the request, comprises transferring, by the server, the ownership of the ticket from the provider to the recipient.

24. The method of claim 1, further comprising: retrieving from the server the references of tickets under the provider's possession and that have not been redeemed; wherein creating, by the first device of the provider, a request containing at least a reference to value to be transferred to a recipient, comprises creating, by the first device of the provider, a request containing a reference to a ticket that the provider selects to transfer; and, wherein transferring, by the server, the value from the provider to the recipient using the reference included in the request, comprises marking, by the server, the ticket as redeemed.

25. A system for facilitating secured value transfer among users using limit-use code, comprising, a first device of a provider comprising, means for creating an encryption apparatus and a decryption apparatus based on a cryptography technique; storage means for storing the encryption apparatus; means for sending the decryption apparatus with the first unique identifier of the provider to a system server; means for creating a request containing at least a reference to value to be transferred to a recipient; means for using the encryption apparatus to encrypt the request; means for sending the encrypted request and the first unique identifier of the provider to a second device of the recipient; a second device of the recipient comprising, means for receiving the encrypted request and the first unique identifier of the provider from the first device of the provider; means for sending the encrypted request and the first unique identifier of the provider along with a second unique identifier of the recipient to the system server; the system server comprising, means for users to register accounts, wherein each account is associated with a unique user identifier; means for receiving the decryption apparatus and the first unique identifier of the provider from the first device of the provider; storage means for storing the decryption apparatus in association with the first unique identifier of the provider and retrieving the decryption apparatus using the first unique identifier of the provider; means for receiving the encrypted request, the first unique identifier of the provider, and the second unique identifier of the recipient from the second device of the recipient; means for using the decryption apparatus to decrypt the encrypted request; means for determining that the request satisfies a usage limit; means for transferring value referenced in the request from the provider to the recipient.

26. A system of claim 25, wherein the system server is configured to operate in a cluster of inter-connected computing devices or operate concurrently on a same computer hardware.

27. A system of claim 25, further comprising a financial server that comprises means for interacting with financial institutions to execute value-transfer transactions.

28. A system of claim 25, further comprising a communication media whereby the first device of the provider can transmit data to the second device of the recipient device.

29. A system of claim 25, further comprising, a medium that is capable of displaying a graphic code; wherein the first device of the provider further comprises means for encoding data in a graphic code and means for having the graphic code displayed or printed on the medium; and, wherein the second device of the recipient further comprises means for scanning the graphic code displayed on the medium and decoding the graphic code.

30. A system of claim 25, further comprising, wherein the first device of the provider further comprising, wherein means for sending the encrypted request and the first unique identifier of the provider to a second device of the recipient, comprises means for sending the encrypted request and the first unique identifier of the provider to a second device of the recipient using Near-Field Communication protocol; wherein the second device of the recipient further comprising, wherein means for receiving the encrypted request and the first unique identifier of the provider from the first device of the provider, comprises means for receiving the encrypted request and the first unique identifier of the provider from the first device of the provider using Near-Field Communication protocol.

31. A system of claim 25, wherein decryption apparatus and encryption apparatus are implemented in software program or hardware logic, in accordance to a symmetric or an asymmetric cryptography algorithm.

32. A system of claim 25, further comprising, wherein the first device of the provider further comprises, an implementation of a cryptographic algorithm that can generate a pair of encryption and decryption keys, and that can use the encryption key to encrypt a request; wherein means for sending the decryption apparatus with the first unique identifier of the provider to a system server, comprises means for sending the decryption key with the first unique identifier of the provider to a system server wherein the system server further comprises, wherein means for receiving the decryption apparatus and the first unique identifier of the provider from the first device of the provider, comprises means for receiving the decryption key and the first unique identifier of the provider from the first device of the provider; wherein storage means for storing the decryption apparatus in association with the first unique identifier of the provider and retrieving the decryption apparatus using the first unique identifier of the provider, comprises storage means for storing the decryption key in association with the first unique identifier of the provider and retrieving the decryption key using the first unique identifier of the provider; and, an implementation of the cryptographic algorithm that can use the decryption key to decrypt the encrypted request.

33. A system of claim 25, wherein the second device of the recipient further comprises, means for displaying a message that requests the provider to enter a PIN; and, an input device whereby the provider can enter a PIN.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The detailed description is set forth with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The use of the same reference numbers in different figures indicates the same items.

[0018] FIG. 1 is a block diagram depicting a system for facilitating a secured value transfer among users, in accordance with an embodiment of the present disclosure.

[0019] FIG. 2 is a flow graph depicting one method of securely transferring values among users using limit-use encrypted code, in accordance with an embodiment of the present disclosure.

[0020] FIG. 3 is a flow graph depicting one method of securely transferring values among users using limit-use encrypted code, wherein payer cryptographic apparatuses are implemented as cryptographic algorithms and a pair of decryption and encryption keys.

[0021] FIG. 4 is a flow diagram providing an enlarged view of the method used in FIG. 3 by the system and a payer to agree on payer cryptographic algorithms and a pair of payer decryption and encryption keys.

[0022] FIG. 5 is a flow graph depicting one method of securely transferring values, wherein a payer can send a payee a verifiable plain text attached to a request.

[0023] FIG. 6A is a flow graph providing an enlarged view of the method used in FIG. 5 to extend a value-sending request with a plain text, and FIG. 6B is a flow graph providing an enlarged view of the method used in FIG. 5 to validate the plain text attached to a request.

[0024] FIG. 7 is a flow diagram depicting one method of securely transferring values, wherein system cryptographic apparatuses are used to protect payer's user id.

[0025] FIG. 8A is a flow diagram providing an enlarged view of the method used in FIG. 7 by the system and a payer to agree on system cryptographic algorithms and a pair of system decryption and encryption keys. FIG. 8B is a flow diagram providing an enlarged view of the method used in FIG. 7 to encrypt payer's user id using the system encryption algorithm and key.

[0026] FIG. 8C is a flow diagram providing an enlarged view of the method used in FIG. 7 to decrypt payer's user id.

[0027] FIG. 9 depicts one form of conducting a secured value transfer from a payer to a payee, in accordance with an embodiment of the present disclosure.

[0028] FIG. 10 depicts one form of conducting a secured value transfer with a payer's PIN, in accordance with an embodiment of the present disclosure.

[0029] FIG. 11 depicts one form of conducting a secured value transfer, wherein a payee specifies the value being transferred and a payer sets the limit for values to be transferred, in accordance with an embodiment of the present disclosure.

[0030] FIG. 12 depicts one form of conducting a secured value transfer wherein a payer redeems a coupon provided by a payee and a ticket is created after the value transfer, in accordance with an embodiment of the present disclosure.

[0031] FIG. 13A is an enlarged view of the method used in FIG. 12 to create a coupon.

[0032] FIG. 13B is an enlarged view of the method used in FIG. 12 to create a ticket.

[0033] FIG. 14 depicts one form of conducting a secured value transfer wherein a payer redeems a coupon in a graphic code presented by a payee, in accordance with an embodiment of the present disclosure.

[0034] FIG. 15 is an enlarged view of the method used in FIG. 14 to select and display a coupon.

[0035] FIG. 16 depicts one form of redeeming a ticket using a method of conducting a secured value transfer, in accordance with an embodiment of the present disclosure.

[0036] FIG. 17 depicts one form of transferring a validated record using a method of conducting a secured value transfer, in accordance with an embodiment of the present disclosure.

DETAILED DESCRIPTION

[0037] In the following description, various embodiments are described. For purposes of explanation, specific configurations and details are set forth in order to provide a thorough understanding of the embodiments. However, it will also be apparent to one skilled in the art that the embodiments may be practiced without the specific details. Furthermore, well-known features may be omitted or simplified in order not to obscure the embodiment being described.

[0038] The following description is presented to enable any person having ordinary skill in the art to make and use the present disclosure, and is provided in the context of particular applications of the present disclosure and their requirements. Various modifications to the disclosed embodiments will be readily apparent to those having ordinary skill in the art and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present disclosure. Thus, the present disclosure is not intended to be limited to the embodiments shown, but is to be accorded in the widest scope consistent with the principles and features disclosed herein.

[0039] The illustrations of executions of an embodiment of the current disclosure incorporate general-purpose computers as well as special purpose digital devices such as smart-phones. Details of such devices (e.g. processor, memory, data storage, display, camera, wired/wireless communication capability) are omitted for the sake of clarity.

[0040] It may also be understood that the system and methods of the present disclosure might be implemented using variety of technologies. For example, the methods described herein may be implemented as software program on a computer, or as a hardware circuit, or various combinations of hardware and software. In particular, the methods described herein may be implemented by a series of computer instructions residing on a storage medium such as disk drives and other computer readable medium. The methods may use a variety of communication media that facilitate information exchange between components (e.g. system servers and client computing devices) of an embodiment of the present convention. Examples of communication media include a printed or displayed graphic code, and carrier waves. Exemplary forms of carrier waves include electrical, electromagnetic, or optical signals carrying information on a plurality of wired and wireless networks.

INTRODUCTION

[0041] In one embodiment of the present disclosure a system and methods are provided for transferring values securely among users using limit-use encrypted code. Values being transferred may be monetary in nature or may take other forms, such credits, debits, vouchers, coupons, tickets, personal information, prescriptions, medical records, and certificates such as drive licenses and the proof of insurance, etc as long as the values are acceptable for both a payer and a payee.

[0042] Personal computing devices may be used to assist users on computational tasks defined in an embodiment of the present disclosure. A personal computing device may or may not be portable in nature, and may deploy virtually any communication media, including both wired and wireless. Examples of personal computing device include Personal Computer (PC), Personal Data Assistants (PDA), smart-phones, and other digital handheld devices.

[0043] Personal payment devices are personal computing devices used by payers and payees to execute computational tasks defined by methods in the present disclosure.

[0044] In some methods defined in the present disclosure, a payee's personal payment device sends data to the system. The connection between the payee's personal payment device and the system may be permanent or temporary, and may be through a local network or a publicly accessible network such as the Internet.

[0045] One embodiment of the present disclosure comprises a means of transmitting data from a first user (“payer”) to a second user (“payee”). Transmission may be conducted using various media and procedures. For instance, the data may be transferred using near-field communication (NFC)-enabled client computing devices, or it can be encoded as a graphic code such as a Quick Response (QR) code and scanned into the payee's personal payment device.

[0046] In the present disclosure, a pair of decryption and encryption apparatuses are used to encrypt and decrypt a value-sending request made by a payer. Virtually any pair of decryption and encryption apparatuses may be used, provided that the data encrypted by the encryption apparatus may be decrypted with the decryption apparatus within a reasonable time and cost. Examples of cryptography apparatus include symmetric and asymmetric cryptography algorithms, being implemented in software program or hardware logic. In one implementation of an embodiment of the present disclosure, a public-private key cryptography algorithm such as Data Encryption Standard (DES) is used. Prior to a value transfer, the system and the payer's personal payment device receive an implementation of the DES algorithm. The payer's personal payment device uses its DES algorithm to generate a public-private key pair K.sub.public, K.sub.private. The payer personal payment device keeps the private key K.sub.private, and sends the public key K.sub.public to the system.

[0047] In the present disclosure, the system checks the usage limit of a request created by a payer. Usage limit may be defined using virtually any means for specifying the validity of a token. In one embodiment of the present disclosure, a usage limit is defined as the maximal number of times that the same value-sending request may be used. In this embodiment the system keeps a record on how many times the same request has been sent to it. In another embodiment hereof, the usage limit is defined as the expiration date of a value-sending request, and the system rejects any request received after its expiration date. Usage limit may be defined as a system-wide policy. Or it may be user-specific and associated with a user's account. Or it can be transaction-specific, in which case a custom usage limit may be encoded in a request.

[0048] A system according to this embodiment of the present disclosure comprises a plurality of computer servers configured to register users or to process requests for value exchanges. Illustratively, users who wish to involve in a transaction register with a server prior to the transaction. A subset of system servers also process encrypted requests created by payers and sent via payees. The process includes decrypting an encrypted request, and checking the usage limit of the request.

[0049] In an extension of this embodiment of the disclosure, the system may include a plurality of web servers hosting Internet portal (e.g. a website), through which a user can use an internet-connected personal computing device to access and manage his account.

[0050] The system according to one embodiment of the present disclosure may also be configured to allow users to perform normal financial operations, including banking operations and electronic ticketing etc. Optionally external financial entity may be involved to hold the value in escrow until a transaction is closed.

[0051] Value may be introduced into the system via cash, check, or virtually any other methods that are acceptable in common business practices. Values may be withdrawn from the system in similar forms.

[0052] In one method of the present disclosure, a payee may use a payment coupon to preset some features of a transaction. A payment coupon includes a reference to the payee. It may also include any of the following optional information: price, product/service involved, expiration date etc. The payment coupon may be presented to a payer using a communication media. For instance, it may be displayed as a graphic code on a digital device or on paper, or it can be transmitted to the payer's personal payment device using a wireless connection. The user may initiate a value-sending request by redeeming a payment coupon. Virtually any information that facilitates or promotes a financial transaction in common business practices may be incorporated into a payment coupon.

[0053] In alternative embodiment of the disclosure, a system described herein may be used for forms of communication other than value exchanges. For instance, the system may be used to distribute to client computing devices a software program that implements the methods of this disclosure.

An Embodiment of a System for Facilitating a Secured Value Transfer

[0054] FIG. 1 is a block diagram depicting a system for facilitating a secured value transfer among users using limit-use encrypted code, in accordance with an embodiment of the present disclosure. Alternative embodiments of the disclosure may incorporate any subset of the components of the illustrated system.

[0055] The system of FIG. 1 includes a plurality of system servers (101). For clarity, components of same type and usage are represented by one instance. For example, element 101 represents a plurality of system servers. A system server (101) may be connected to a plurality of financial servers (102) and a plurality of databases (103). The connection may be implemented using various communication technologies, e.g. Ethernet, Fiber Optical Channel, etc. A subset of system servers (101) may also serve as a communication gateway and may be connected with a payer's (106) and a payee's (107) personal computing devices. Personal computing devices may be any computing devices used by users to execute their computational tasks, in accordance with methods of the present disclosure. Payer's (108) and payee's (109) personal payment devices may be a subset of personal computing devices used by payers and payees to execute their computational tasks during value-transfer transactions. A solid line represents a connection during a transaction, whereas a dash line represents a connection that is not required during a transaction but may be requested prior to or after a transaction.

[0056] System servers (101) may register users and perform other system tasks, in accordance with methods of the present disclosure. These tasks may include (a) obtaining the payer decryption apparatus; and (b) receiving, decrypting, and validating requests; and (c) conducting a value-transfer transaction. Depending on the configurations of value-transfer transactions, task (c) may be carried out in collaboration with additional servers such as financial servers (102). Physically system servers (101) may comprise a plurality of inter-connected computer servers. In one embodiment of the present disclosure, system servers (101) may also host a website. The website may serve as a portal whereby a user can access and manage his account.

[0057] Databases (103) may serve as a persistent data storage that can record and retrieve data related to the value transfer. They may store users' account information as well as information that are persistent across different sessions and transactions. User information may include user identification and contact information (e.g. name, email address), transaction record, account balance, preferred communication settings, or cryptography apparatuses. Database (103) may be implemented using different forms and technologies, for example, using a centralized architecture design or a distributed design where the data is partitioned and distributed into multiple networked computers to improve performance.

[0058] When values being transferred are in a financial form, additional servers may be involved as financial servers (102). These financial servers communicate with financial institutions (105) and initialize financial transaction to transfer values. Financial server (102) may communicate with financial institution (105) to inject values to or extract them from the system. Since the methods in present disclosure may be used for transferring virtually any form of values, financial servers (102) shall be broadly interpreted as servers that execute value-transfer transactions.

[0059] Users deploy various personal computing devices (106 and 107) to fulfill their tasks, in accordance with methods of the present disclosure. Virtually any computing device with a plurality of processors and/or a storage storing instruction may be used as personal computing devices. The illustrative system in FIG. 1 lists some examples, including personal computing devices used by payer (106) and by payee (107) to communicate with system servers (101), as well as personal payment devices used by a payer (108) and by a payee (109) in a value-transfer transaction. A variety of computing devices may be used as client computing devices, including Smart phones, Personal Data Assistants (PDAs), and other mobile computing devices, provided that the devices possess hardware and/or software suitable for fulfilling tasks defined in methods of the present disclosure.

[0060] A payer may use a personal payment device to create and encrypt a value-sending request. The encrypted value-sending request may then be transmitted to a payee's personal payment device. Transmission may be conducted through virtually any communication media using direct or indirect links. In one embodiment of the present disclosure, the request may be transmitted using near-field communication (NFC), which is a peer-to-peer wireless connection. In another embodiment of the present disclosure, the request may be encoded as a graphic code, for instance, Quick Response (QR) code, and scanned into a payee's personal payment device.

[0061] In one method defined in the present disclosure, a payee's personal payment device (109) receives an encrypted request from payer's personal payment device (108). The payee's client computing device (109) may be connected to a system server (101) during a transaction. The payee may use his personal payment device (109) to forward the request to the system server (101). In one method of the present disclosure, payer's PIN may be used as a second form of authentication. Payee's client computing device (109) may be capable of displaying a message that requests the payer for her PIN. It may also have an input device whereby the payer may enter her PIN.

[0062] Illustratively an entity operating the value transferring system may act as a Certificate Authority and certify individual users, while certificated users may in turn certify individual transactions using encrypted value-sending requests. Certified users may be issued with identity certificates for use in value transferring transaction.

One Method of Securely Transferring Values Between Users Using Limit-Use Encrypted Code

[0063] With reference now to FIG. 2, an illustrative method of transferring a value securely in accordance to one embodiment of the present disclosure. The illustrated method may be used with the system depicted in FIG. 1.

[0064] Prior to a transaction, users register with the system. User registration process may be carried out concurrently by individual users with no particular order: a payee registers with the system in state 201, and a payer registers with the system in state 204. During the registration a user may be assigned with a unique record. The record, referred to as user ID, identifies the user within the system. In state 202 the payer agrees with the system on cryptographic apparatuses, referred to as payer cryptography apparatuses. The cryptography apparatuses may come in form of a pair of a decryption apparatus and an encryption apparatus. Virtually any form of cryptography apparatuses may be used with this method of secured value transfer, given that a message encrypted with an encryption apparatus may be decrypted with a decryption apparatus within reasonable time and resources. The cryptography apparatuses may be implemented as software program, hardware logic, or any combination of both. The process of reaching an agreement may involve the communication between the payer and the system, or though a third party as an authentication authority. In one implementation of this method, the cryptography apparatuses may be implemented using an asymmetric cryptographic algorithm, also known as a public-key cryptographic algorithm, such as one defined by Data Encryption Standard (DES). In this implementation, a pair of the public and private keys are generated using the asymmetric cryptographic algorithm. The public key K.sub.public may be stored on a system server and the private key K.sub.private may be stored on the payer's personal payment device. In another implementation of this method, the cryptography apparatuses may be implemented using a symmetric cryptographic algorithm. In this implementation, a cryptographic key may be generated using the symmetric cryptographic algorithm. The key may be stored both on a system server and on the payer's personal payment device.

[0065] A payer initiates a transaction by creating a value-sending request in state 205. The request may include payer's user id and other information from which the amount of value being transferred may be calculated. In state 206 the payer encrypts the value-sending request using a payer cryptography apparatus. In one implementation of this method, the payer encrypts the value-sending request using the payer's private key K.sub.private. In state 207 the payer sends the encrypted request to the payee.

[0066] Once receiving the encrypted request from the payer, in state 209 the payee sends to the system the request and the payee's user ID.

[0067] After receiving the request via the payee, in state 209 the system decrypts the request, using a payer cryptographic apparatus. In one implementation of the method, the request may be decrypted using the payer's public key K.sub.public. In state 211 the system server checks the usage of the value-sending request. If it reaches its usage limit, then the request will be denied. Otherwise, the system server updates the usage record for the request in state 212, and transfers the value from the payer to the payee in state 213.

[0068] The rest of the description will be organized as follows: FIG. 2 illustrates a method of securely transferring a value among users with limit-use code, in accordance with one embodiment of the present disclosure. Various variants may be extended from this method. FIG. 3 depicts an embodiment of the method in which payer cryptographic apparatuses are implemented using an asymmetric cryptographic algorithm and a pair of private and public keys. FIG. 5 extends the method of FIG. 2 with additional steps that allows a payer to send out a verifiable plain text. FIG. 7 adds additional steps and means whereby additional cryptographic apparatuses are used to protect the payer's identity.

[0069] FIGS. 9-17 depict several embodiments of the present disclosures, using variants of methods depicted in FIGS. 2-7 and variants of the system depicted in FIG. 1. FIG. 9 depicts an embodiment of the present disclosure, using a variant of the method depicted in FIG. 2 and the system depicted in FIG. 1. FIG. 10 extends the embodiment depicted in FIG. 9 with additional steps and means that enable the use of a Personal Identification Number (PIN) as an additional authentication method. FIG. 11 adds additional steps and means whereby a payee proposes value being transferred and a payer sets a limit for the value. FIG. 12 extends the embodiment depicted in FIG. 9 with additional steps and means that enable the use of coupons and tickets. FIG. 14 adds additional steps and means that enable the use of coupons encoded in a graphic code, for example, in the Quick Response (QR) code. FIG. 16 adds additional steps and means that enable the redemption of a ticket. Finally, FIG. 17 depicts an embodiment of the present disclosure, wherein the value being transferred is a record validated by a third user.

[0070] It shall be noted that additional steps and means defined in these methods and embodiments may be combined to form a new method or an embodiment. Such extension and combination will be readily apparent to those having ordinary skill in the art, and the general principles defined herein may be applied to other methods and embodiments without departing from the spirit and scope of the present disclosure. Thus, the present disclosure is not intended to be limited to the methods and embodiments shown, but is to be accorded in the widest scope consistent with the principles and features disclosed herein.

One Method of Securely Transferring Values with Private-Public Key Exchange

[0071] FIG. 3 illustrates a method of secured value transfer wherein payer cryptographic devices may be provided in a form of an asymmetric cryptographic algorithm and a pair of encryption and decryption keys. With reference now to FIG. 4, illustrating the details of a method used by a payer and the system to exchange private and public keys.

[0072] Before the key exchange, the system and a payer agree on a cryptography algorithm (401). There may be many ways to reach such an agreement: in one embodiment of this method, the cryptography algorithm is selected by developers of the system. In another embodiment of the method, the agreement may be reached through a negotiation between a payer and the system. After an agreement is reached, the payer and the system obtain an implementation of the cryptographic algorithm (402 and 403). There are many ways for the payer and the system to obtain an implementation of the algorithm: the algorithm may be implemented on the payer's personal payment device as well as on a system server, or, the payer and the system may download the implementation from a public domain.

[0073] After obtaining an implementation of the cryptographic algorithm, the payer uses it to generate a pair of encryption (private) key and decryption (public) key (404). The payer then sends the decryption key to the system (405). The payer uses the encryption key with the cryptographic algorithm to encrypt a value-sending request (206 in FIG. 3), and the system uses the payer decryption key with the cryptographic algorithm to decrypt the request, received via the payee (209 in FIG. 3).

One Method of Securely Transferring Values with Verifiable Plain Texts

[0074] With reference now to FIG. 5, illustrating a method of securely transferring a value wherein a payer may also send out a verifiable plain text. This additional capability enables a payer to attach with a request a message accessible to a payee, and the message may be validated by the system to make sure that it is not altered in any way by the payee or others.

[0075] One application of a verifiable plain text is to allow a payer to communicate with a payee terms associated with underlying value-transfer transaction. A payee may read these terms in a verifiable plain text, and if he agrees with these terms, he can forward the request to the system for the further process. The system can then verify the integrity of the plain text attached with the request forwarded by the payee. The system may use the verifiable plain text as evidence showing that the payee agrees the terms described in the plain text attached with the request.

[0076] The method in FIG. 5 extends the method in FIG. 2 with three steps: at step 501 the payer encrypts the request and attaches a plain text to the request, wherein the encrypted request contains the information for verifying the integrity of the plain text; at step 502 the payee accesses the plain text attached to the request; at step 503 the system uses the information contained in the request to verify the attached plain text.

[0077] With the reference now to FIG. 6A, providing enlarged views of step 501 in FIG. 5. At step 601 the payer computes a record d from the plain text. The record, referred to as a digest, is used to validate the plain text. There are various methods that may be used for computing a digest of a plain text. If two texts are different, their digests are also different. In some applications, for performance consideration, the digests of two different texts are different with a high probability. Examples of methods computing digests include SHA family of cryptographic hash functions. After computing the digest, the payer adds the digest into the request at step 602, and uses the payer encryption apparatus to encrypt the request at step 603. The payer then attaches the plain text to the request at step 604.

[0078] With the reference now to FIG. 6B, providing an enlarged view of step 503 in FIG. 5. After decrypting the request at step 210 (FIG. 5), the system extracts the digest from the request at step 605, and uses the digest to validate the plain text attached to the request at step 606. The validation process usually involves in computing a digest of the plain text attached to the request, and then checking whether it is consistent with the digest contained in the request. If the validation fails, the system exits from the workflow, indicating that the plain text is corrupted at step 607.

One Method of Securely Transferring Values with System Cryptographic Apparatuses

[0079] With reference now to FIG. 7, illustrating a method of securely transferring a value, wherein system cryptography apparatuses are used in addition to payer cryptography apparatuses. System cryptography apparatuses allow users to communicate with the system securely without using user-specific payer cryptographic apparatuses. One use of system cryptographic apparatuses is to encrypt payer's identity in a multiple user environment. In an application where multiple users are registered with the system, the system associates a payer decryption apparatus with the payer's user ID. In this environment, the system uses a payer's user ID to retrieve the payer's decryption apparatus. Therefore, the information on the payer's user ID is attached to a request, and it has to be accessible to the system. The system cryptography apparatus provides a means to encrypt and decrypt the payer's ID without resort to user-specific payer cryptography apparatuses.

[0080] The method of FIG. 7 extends the method of FIG. 3 with the following steps: in addition to agreeing on payer cryptography apparatuses, the system and the payer also agree on system cryptographic apparatuses at step 701. The payer encrypts the request with both payer and system encryption apparatuses at step 702. The system decrypts the request with both user and system decryption apparatuses.

[0081] With reference now to FIG. 8A, providing an enlarged view of the agreement on the system cryptographic apparatuses at step 701. The system selects a cryptography algorithm at step 801. The payer and the system then obtain the cryptography algorithm at step 802 and at step 803, respectively. The approaches of obtaining a system cryptography algorithm is similar to those of obtaining a payer cryptography algorithm. For example, the algorithm may be implemented on the payer's personal payment device and on a system server, or it may be downloaded from a public domain. The system then generates a pair of public and private key using the system cryptography algorithm, and sends the public key to the payer as the system encryption key at step 805.

[0082] With reference now to FIG. 8B, providing an enlarged view of encrypting a value-sending request with payer and system encryption apparatuses at step 702. The payer uses payer encryption apparatus to encrypt the request at step 806. The payer then uses the system encryption apparatus to encrypt the payer's user ID at step 807, and attaches the encrypted user id to the encrypted value-sending request at step 808.

[0083] With reference now to FIG. 8C, providing an enlarged view of encrypting a value-sending request with payer and system encryption apparatuses at step 703. At step 809, the system uses the system decryption apparatus to decrypt the payer's user ID attached to the request. At step 810, the system uses the payer's user ID to retrieve the payer decryption apparatus. Finally, at step 811, the system uses the payer decryption apparatus to decrypt the request.

Conducting a Secured Value Transfer with Limit-Use Encrypted Code

[0084] With reference now to FIG. 9, illustrating a form of secured value transfer using the method of FIG. 2 and the embodiment of system of FIG. 1. Functions of a payer (911) and a payee (912) are implemented by payer's personal payment devices (108) and payee's personal devices (109).

[0085] At step (901) a payer (911) uses her personal payment devices (108) to create and to encrypt a request. The request includes payer's user ID, and the value being transferred. The encrypted request is transmitted from the payer's personal payment devices (108) to a payee's personal payment devices (109). Payee's personal client computing device (108) send to the system server (101) the encrypted request and payee's user ID at step (904). System server (101) decrypts the request at step (905) and checks its usage limit at step (906). After a successful validation on usage limit, the system server (101) initializes the value transfer from the payer to the payee. If necessary, an external financial institution (109) will be contacted to replenish the payer's account at step 910, using payer's financial information.

Conducting a Secured Value Transfer with PIN Authentication

[0086] With reference now to FIG. 10, illustrating a form of secured value transfer with additional authentication required using Personal Identification Number (PIN). This method extends the method of FIG. 9 with steps and means for additional authentication using a payer's PIN. For clarity, this description will emphasize on these additional steps and means.

[0087] A payer chooses her PIN prior to a transaction, and the system stores her PIN in the databases (103). After receiving a request via a payee, but before conducting the requested transaction, a PIN request may be sent by the system to payee's personal computing device at step 1001. The payee's client computing device displays the request and the payer enters her PIN at step 1002. The payee sends back to the system the received PIN. System server retrieves the payer's PIN at step 1003 and validates the received PIN again the stored PIN at step 1004.

Conducting a Secured Value Transfer Wherein a Payee Specifies a Value being Transferred and a Payer Sets the Limit for the Value

[0088] With reference now to FIG. 11, illustrating a form of secured value transfer wherein a payee specifies the value being transferred and the payer sets the limit for the value. This method extends the method of FIG. 3 with steps and means that enable the payee to specify the amount of the value being transferred and the payer to set the limit for the value being transferred. For clarity, this description will emphasize on these additional steps and means.

[0089] At step 1102 the payer creates and encrypts a value-sending request. Instead of specifying the value being transferred in the request, the payer specifies in a request a limit for the value that may be transferred. After receiving the request from the payer, the payee enters the value to be transferred, referred to as “charge”, at step 1103. At step 1104 the payee sends to the system the request received from the payer, the payee's user ID, and the charge entered by the payee. At step 1104 the system checks whether the charge exceeds the limit specified in the request, and rejects the transaction if so.

Conducting a Secured Value Transfer Wherein Coupons are Used to Preset Values being Transferred

[0090] With reference now to FIG. 12, illustrating a form of secured value transfer wherein a payee uses a coupon to preset the value being transferred and the payer initializes value-sending request by redeeming the coupon. The transaction flow in FIG. 12 extends that of FIG. 2 with steps and means for creating and redeeming a coupon. An optional ticket may also be generated as a proof of the transaction. For clarity, this description will emphasize on these additional steps and means.

[0091] At step 1201 the payee uses the system to create a record that specifies the value being transferred. A reference to the record, referred to as a “coupon”, may be sent to the payer at step 1203. The payer may redeem the coupon by including it in a request. At step 1202 the payer creates and encrypts a request, which includes a plurality of coupons. After receiving a value-receiving request and decrypting the value-sending request in it, the system computes the value being transferred in step 1204. Upon a successful value-transfer transaction, the system creates a ticket for each “ticketable” coupon.

[0092] With the reference now to FIG. 13A, providing an enlarged view of creating a coupon at step 1201. At step 1301 a payee uses his personal computing device to initialize a request to the system for creating a coupon. The coupon specifies a value being transferred. It may also include optional data such as the information indicating whether a ticket is generated when the coupon is redeemed. Such a coupon is referred to as a “ticketable” coupon in this description. At step 1302 the system creates a record for the coupon upon the request from the payee. If the payee requests a “ticketable” coupon, the system marks new coupon as “ticketable”.

[0093] With the reference now to FIG. 13B, providing an enlarged view of creating a ticket at step 1205. After a successful value transfer, the system checks the coupons included in the value-sending request. For each of the coupons that are ticketable, the system creates a ticket and marks the payer as its owner at step 1308, and it also marks the ticket as “new” at step 1309.

Conducting a Secured Value Transfer Wherein Communication Between Payer and Payee are Carried Out Through Graphic Codes

[0094] With reference now to FIG. 14, illustrating a form of secured value transfer, wherein communication between payer and payee are carried out using graphic codes. Examples of graphic coding formats are bar code, Quick Response (QR) code, etc. Communication in a graphic format may be presented on various media suitable for displaying the graphic code. Examples of media include papers, outdoor billboards, and the screens of personal payment devices, etc. The graphic code may be scanned into personal payment devices. The transaction flow of FIG. 14 extends the transaction flows of FIG. 9 and FIG. 12 with additional steps and means that enable communication in graphic code. For clarity, this description emphasizes on these additional steps and means.

[0095] Before a value-transfer transaction, a payee sends a payer some coupons through graphic codes. At step 1401 the payer selects and displays a coupon. The payee presents to the payer the coupon encoded in a graphic code (1402) at step 1403a, and at step 1403b the payer scans the coupon using her personal payment device (108). Before starting a value-send request, the payer browses her personal payment devices for scanned coupons and selects those to be redeemed at step 1404. The payer then creates a value-sending request with these coupons and encrypts the request at step 1202. The payer uses her personal payment device to encode the request in a graphic code (1405) at step 1406a, and the payee scans the coupon into his personal payment device at step 1406b. The rest of the transaction then follows the flow depicted in FIG. 12.

[0096] With the reference now to FIG. 15, providing an enlarged view of selecting and displaying a coupon at step 1401. At step 1507 the payee uses his personal computing device to browse a list of coupons. The personal computing device (107) is connected to a system server (101) as depicted in FIG. 1, in accordance to one embodiment of the present disclosure.

Using a Method for Secured Value Transfer to Redeem a Ticket

[0097] With reference now to FIG. 16, illustrating a form of redeeming a ticket using a method for secured value transfer, in accordance to one embodiment of the present disclosure. The transaction flow of FIG. 16 extends the transaction flow of FIG. 2 with methods and means that allows a secured redemption of a ticket. In this case the value being transferred is a ticket. The outcome of a value-transfer transaction is the redemption of the ticket.

[0098] At step 1601, a payer uses her personal payment device to retrieve a list of tickets under her possession. The payer then selects a plurality of tickets to redeem at step 1602. At step 1603 the payer then creates a request wherein the value being transferred is these tickets. The transaction flow then follows that of FIG. 9 until the system processes and validates the value-receiving request from the payee. At step 1604 the system proceeds to redeem the ticket, and notifies the payee the result at step 1605.

Securely Transferring from a First User to a Second User Data Records Validated by a Third User

[0099] With reference now to FIG. 17, illustrating a form of securely transferring data records validated by a third user, in accordance to one embodiment of the present disclosure. Examples of such data records include driver licenses, proof of insurance, passports, medical records, prescriptions, etc. The transaction flow of FIG. 17 extends the transaction flow of FIG. 9 with additional steps and means whereby a data record validated by a third party can be securely transferred from a payer to a payee. For clarity, this description emphasizes on these additional steps and means.

[0100] Before the transaction, a third user, referred to as an agent (1701) in this description, validates a record (1702) at step 1703. The agent registers the validated record with the system at step 1704. A reference to the record may be sent to a payer at step 1705. When initializing a transfer of the data record to a payee, the payer creates and encrypts a value-sending request at step 1706. The request encloses the reference to the data record as the value being transferred. The transaction flow then follows that of FIG. 9 until the system processes and validates the value-receiving request from the payee. At step 1707 the system proceeds to send the validated data record to the payee.