CN107730256B

CN107730256B - Multi-factor multi-channel ID authentication and transaction control and multi-option payment system and method

Info

Publication number: CN107730256B
Application number: CN201710943287.5A
Authority: CN
Inventors: 熊楚渝
Original assignee: Chengdu Cyberkey Technologies Co ltd
Current assignee: Chengdu Tianyao Technology Co.,Ltd.
Priority date: 2011-09-09
Filing date: 2012-09-10
Publication date: 2022-01-04
Anticipated expiration: 2032-09-10
Also published as: CN107730256A; CN103116842B8; CN107730240A; CN103116842A; CN107730240B; CN103116842B

Abstract

The invention provides a multi-factor multi-channel ID authentication and transaction control and multi-option payment system and method, a system and method for multi-factor multi-channel ID authentication and transaction control and a multi-option system and method for paying for an article selected from a merchant. Authentication and transaction control may be performed only between the electronic device and the service provider's server without third party involvement. For the service provider's server, the device's server facilitates personalization, binding, unbinding and rebinding of the device. When the buyer selects a payment option via the electronic device, a payment message is sent to the payment portal. The payment portal selects an appropriate participant entity based on the selected payment options of the message and sends the buyer's account information to the selected participant entity. Authentication between the participating entity and the buyer's account is performed through multi-factor multi-channel identity authentication and transaction control.

Description

Multi-factor multi-channel ID authentication and transaction control and multi-option payment system and method

Technical Field

In general, the present invention relates to the field of Identity (ID) authentication and transaction control used in electronic payment processes, as well as electronic payment systems and methods. More particularly, the present invention relates to a multi-factor, multi-channel identity authentication and transaction control system and electronic payment system and method for secure, multi-channel, multi-option payments.

Background

In modern society, authentication and transaction control are common and essential to commerce, especially worldwide. Most authentication and transaction control is based on a single factor, single channel. The factor may be any authentication factor, such as one that one has (e.g., a token), one that one knows (e.g., a password), one's own (e.g., a fingerprint), or related to one (e.g., a social network). The channel may be any information communication channel such as the internet, telephone, private network, etc.

Identity authentication and transaction control based on a single factor, single channel is considered vulnerable, one form of which is commonly referred to as a man-in-the-middle (MITM) attack. In a MITM attack, a fraudster uses devices connected to the client and application server by relaying requests and responses, thereby stealing data and/or on behalf of the client browser for fraud purposes.

Furthermore, with the rapid growth of global commerce, identity authentication and transaction control systems must handle multiple IDs for a single user in a simple, flexible manner. Today, consumers often have multiple IDs, including passports, driver's licenses, mailbox accounts, job site IDs, credit cards, bank accounts, entertainment accounts, social network accounts, consumer accounts, and the like. It is the right of the consumer to own multiple IDs and select the appropriate ID in different situations while keeping the ID secret. However, existing authentication and transaction control schemes require centralized management of authentication and transaction control, which effectively deprives the consumer of the right to maintain and control his/her own multiple IDs.

In addition, it is cumbersome for the consumer to handle multiple IDs, especially when these IDs and associated passwords must be changed frequently for security. Also, third party control is not desired by the service provider during the transaction, who typically wants to maintain full control and management of the transaction. Moreover, in some situations, consumers do not want their actions to be tied to their unique identity. Thus, maintaining anonymity during the transaction is also desirable to the user.

Thus, the present applicant has recognized a need to develop a multi-factor, multi-channel identity authentication and transaction control system and method that can support commerce worldwide without the need for centralized stations, relieve the user of the burden of remembering IDs and passwords, provide full control and management for service providers, and maintain anonymous consumers during specific transactions.

Conventional electronic payment systems require that the buyer's account information be saved in a payment portal. The payment portal receives payment instructions from the buyer and verifies the buyer's account based on the saved account information. Typically, only one payment option is available to the buyer in association with the previously saved account message. Thus, existing electronic payment systems do not allow a buyer to select an appropriate payment option from a plurality of available payment options. In addition, permanently saving the buyer's account information in the payment portal can present security and privacy concerns.

Accordingly, the present applicant has recognized a need to develop an electronic payment system and method that provides a plurality of payment options for a buyer without requiring the buyer's account information to be saved in a payment portal.

Disclosure of Invention

According to an aspect of the invention, a method of multi-factor multi-channel identity authentication and transaction control is provided in which a user uses a device that communicates with at least one service provider. The method comprises the following steps: sharing at least one symmetric key with a server of the device; binding the service provider's server to share the at least one symmetric key with the service provider's server; sending an identity authentication request to a server of the service provider; receiving an instruction message from a server of the service provider; generating a response message based on the instruction message; and sending a response message to a server of the service provider for multi-channel multi-factor identity authentication directly between the device and the service provider based on the response message and at least one symmetric key shared by the device and the service provider. A computer program product for use with a computer is also provided. The product includes a computer-readable storage medium having recorded thereon a computer-executable program for causing a computer to perform the above-described method.

In accordance with another aspect of the present invention, a method of multi-factor multi-channel identity authentication and transaction control is provided in which a user uses a handheld electronic device in communication with at least one service provider. The method comprises the following steps: binding the device to share at least one symmetric key with the device, the at least one symmetric key shared between the device and a server of the device; receiving an identity authentication request from the device; generating an instruction message; sending an instruction message to the device; receiving a response message generated by the device; and performing a multi-channel multi-factor identity authentication of the device directly between the device and the service provider based on the response message and at least one symmetric key shared between the device and a server of the service provider. A computer program product for use with a computer is also provided. The product includes a computer-readable storage medium having recorded thereon a computer-executable program for causing a computer to perform the above-described method.

According to another aspect of the invention, there is provided a method of maintaining anonymity of a user device from a service provider during multi-factor multi-channel authentication and transaction of the user device, wherein the user uses a handheld electronic device communicating with a server of the device through a terminal. The method comprises the following steps: receiving, by the terminal, a request from the device; exchanging transaction related data with the device; generating a one-time anonymous identifier for the device, the one-time anonymous identifier valid for a predetermined time; and sending the one-time anonymous identifier to the device, the one-time anonymous identifier being retrievable by the device within a predetermined time. A computer program product for use with a computer is also provided. The product includes a computer-readable storage medium having recorded thereon a computer-executable program for causing a computer to perform the above-described method.

According to another aspect of the invention, a method of multi-channel authentication of a user using a handheld electronic device communicating with a server of a service provider through a terminal is provided. The method comprises the following steps: the equipment receives an instruction message sent from a server through a terminal; the device generating a response message based on the instruction message and at least one symmetric key shared by the device and the server; the equipment sends a response message to the terminal; and the terminal transmits the response message to a destination predetermined by the server. A computer program product for use with a computer is also provided. The product includes a computer-readable storage medium having recorded thereon a computer-executable program for causing a computer to perform the above-described method.

According to another aspect of the invention, a method of multi-channel authentication of a user using a handheld electronic device in communication with a server of a service provider and a terminal is provided. The method comprises the following steps: the device sends an authentication request to a server through a first communication channel; the device receives, through a first communication channel, an instruction message generated by a server based on an authentication request; the device sends an authentication credential to the server over a second communication channel based on the instruction message, the second communication channel being different from the first communication channel; and the terminal receiving an authentication message generated by the server based on the authentication credential. A computer program product for use with a computer is also provided. The product includes a computer-readable storage medium having recorded thereon a computer-executable program for causing a computer to perform the above-described method.

According to another aspect of the invention, a method of multi-channel authentication of a user using a handheld electronic device in communication with a server of a service provider and a terminal is provided. The method comprises the following steps: the server receiving a request from the device over a first communication channel; the server generates an instruction message based on the authentication request and sends the instruction message to the equipment through a first communication channel; the server receiving authentication credentials from the device over a second communication channel, the second communication channel being different from the first communication channel; and the server generates an authentication message based on the authentication credential and sends the authentication message to the terminal. A computer program product for use with a computer is also provided. The product includes a computer-readable storage medium having recorded thereon a computer-executable program for causing a computer to perform the above-described method.

In accordance with another aspect of the present invention, a multi-factor, multi-channel authentication and transaction control data processing system is provided in which a user uses a handheld electronic device in communication with at least one service provider. The system comprises: a processor; a personalization module configured to personalize the device and a server of the device to allow the device and the server of the device to share at least one symmetric key; a binding module configured to bind the device and the server of the service provider so as to allow the device and the server of the service provider to share at least one symmetric key; a transmission module configured to transmit an identity authentication or transaction control request to a server of a service provider; a receiving module configured to receive an instruction message from a server of a service provider; and a processing module operable to execute on the processor and configured to generate a response message based on the instruction message. The transmission module is further configured to send a response message to a server of the service provider for multi-channel multi-factor identity authentication or transaction control of the device.

In accordance with another aspect of the present invention, a multi-factor, multi-channel authentication and transaction control data processing system is provided in which a user uses a handheld electronic device in communication with at least one service provider. The system comprises: a processor; a binding module configured to bind a server of a service provider to a device so as to allow the server of the service provider and the device to share at least one symmetric key, the at least one symmetric key being shared between the device and the server of the device; a receiving module configured to receive an identity authentication or transaction control request from a device; a processing module operable to execute on the processor and configured to generate an instruction message upon receipt of a request; and a transmission module configured to send the instruction message to the device. The receiving module is further configured to receive a response message generated by the device and the processing module is further configured to perform multi-channel multi-factor identity authentication or transaction control on the device based on the response message.

According to another aspect of the invention, a method is provided for allowing a buyer to use an electronic device to pay for an item selected from the buyer. The method comprises the following steps: receiving a code representing transaction-related information related to the selected item; retrieving transaction-related information from the code; verifying transaction related information; selecting at least one payment option from a plurality of predetermined payment options; generating a payment message based on the transaction-related information and the payment options; and sending the payment message to a payment portal in communication with the plurality of participant entities. The payment message includes a first segment representing the payment option and a second segment representing account data of the buyer relating to the payment option. Each of the participating entities is associated with at least one of a plurality of predetermined payment options.

According to another aspect of the present invention, there is provided a method of allowing a buyer to pay for an item selected from a merchant via a payment portal in communication with a plurality of participating entities, each of the participating entities being associated with at least one of a plurality of predetermined payment options. The method comprises the following steps: receiving a payment message including a first segment representing a payment option selected by the buyer from a plurality of predetermined payment options and a second segment representing account data of the buyer relating to the selected payment option; selecting a participating entity related to the selected payment option based on the first segment of the payment message; sending a second segment of the payment message to the selected participating entity to verify the buyer's account associated with the selected payment option; receiving an instruction message from the selected participating entity, the instruction message being generated based on the validity of the buyer account; and sending the instruction message to the merchant's server.

According to another aspect of the present invention, there is provided a computer program product for use with a computer, the computer program product comprising a computer-readable storage medium having recorded thereon a computer-executable program for causing the computer to perform a process for allowing a buyer to use an electronic device to pay for an item selected from the buyer. The processing comprises the following steps: receiving a code representing transaction-related information related to the selected item; retrieving transaction-related information from the code; verifying transaction related information; selecting at least one payment option from a plurality of predetermined payment options; generating a payment message based on the transaction-related information and the payment options; and sending the payment message to a payment portal in communication with the plurality of participant entities. The payment message includes a first segment representing the payment option and a second segment representing account data of the buyer relating to the payment option. Each of the participating entities is associated with at least one of a plurality of predetermined payment options.

According to another aspect of the present invention, a data processing system is provided that allows a buyer to use an electronic device to pay for an item selected from the buyer. The system comprises: a transceiver configured to receive a code representing transaction-related information related to a selected item; a processor configured to retrieve transaction-related information from the code; a display configured to display transaction related information such that the transaction related information can be verified by a buyer; and a user interface configured to allow the purchaser to select one payment option from a plurality of predetermined payment options. The processor is further configured to generate a payment message based on the transaction-related information and the payment options. The payment message includes a first segment representing the payment option and a second segment representing account data of the buyer relating to the payment option. The transceiver is further configured to send the payment message to a payment portal in communication with a plurality of participant entities, each of the participant entities being associated with at least one of a plurality of predetermined payment options.

According to another aspect of the present invention, there is provided a computer program product for use with a computer, the computer program product comprising a computer-readable storage medium having recorded thereon a computer-executable program for causing the computer to perform a process for allowing a buyer to pay for an item selected from the buyer through a payment portal in communication with a plurality of participating entities, each of the participating entities being associated with at least one of a plurality of predetermined payment options. The processing comprises the following steps: receiving a payment message including a first segment representing a payment option selected by the buyer from a plurality of predetermined payment options and a second segment representing account data of the buyer relating to the selected payment option; selecting a participating entity related to the selected payment option based on the first segment of the payment message; sending a second segment of the payment message to the selected participating entity to verify the buyer's account associated with the selected payment option; receiving an instruction message from the selected participating entity, the instruction message generated based on the validity of the buyer account; and sending the instruction message to the merchant's server.

According to another aspect of the present invention, there is provided a data processing system for allowing a buyer to pay for items selected from a merchant via a payment portal in communication with a plurality of participating entities, each of the participating entities being associated with at least one of a plurality of predetermined payment options. The system comprises: a transceiver configured to receive a payment message including a first segment representing a payment option selected by a buyer and a second segment representing account data of the buyer relating to the selected payment option; and a processor configured to select a participant entity associated with the selected payment option based on the first segment of the payment message. The transceiver is further configured to send a second segment of the payment message to the selected participating entity for verification of the buyer's account, receive an instruction message from the selected participating entity generated based on the validity of the buyer's account, and send the instruction message to the merchant's server.

Drawings

The above objects and advantages of the present invention will become more readily apparent to those skilled in the art from the following detailed description of various embodiments of the invention when taken in conjunction with the accompanying drawings, wherein like reference numerals designate like elements throughout the several views and wherein:

FIGS. 1A-1D are diagrams of various designs of a handheld electronic authenticator;

FIG. 2 is a block diagram of a logic design of a handheld electronic authenticator according to an embodiment of the present invention;

FIG. 3 is a block diagram of read protected memory 255 and RAM 265 in the storage system of compute module 205 in FIG. 2;

FIG. 4 is a block diagram of a logical design of a foil of a handheld electronic authenticator according to an embodiment of the present invention;

FIG. 5 is a flow chart of a process for start-up/maintenance of a handheld electronic authenticator according to an embodiment of the present invention;

fig. 6 is a flowchart of a detailed procedure of startup/maintenance performed in the server of the authenticator;

FIG. 7 is a flow chart of a process for startup/maintenance of a foil of a handheld electronic authenticator in accordance with a preferred embodiment of the present invention;

FIG. 8 is a flowchart of a detailed process of startup/maintenance in a service provider's server;

FIG. 9 is a flow diagram of a process of identity authentication according to an embodiment of the present invention;

FIG. 10 is a flowchart of a detailed process of identity authentication;

FIG. 11 is a subsequent flow diagram of the detailed process of identity authentication of FIG. 10;

FIG. 12 is a subsequent flow diagram of the detailed process of identity authentication of FIG. 11;

FIG. 13 is a flow diagram of a process of signature generation according to an embodiment of the present invention;

FIG. 14 is a flow chart of a process for requesting services from a service provider using a handheld electronic authenticator;

FIG. 15 is a flow chart of a process for using a handheld electronic authenticator in a transaction with a third party;

FIG. 16 is a flow chart of a process for using a handheld electronic authenticator in a transaction for more data needed by a service provider;

FIG. 17 is a block diagram illustrating a multi-factor, multi-channel identity authentication and transaction control system according to an embodiment of the present invention;

18A-18D are schematic diagrams illustrating communication between a handheld electronic device and a terminal of a multi-factor multi-channel authentication and transaction control system;

FIGS. 19A-19B are schematic diagrams illustrating communication between a handheld electronic device and a server of a service provider;

fig. 20 is a schematic diagram showing communication between a terminal and a server of a service provider;

FIG. 21 is a schematic diagram showing communication between a server of a device and a server of a service provider;

FIG. 22 is a schematic diagram illustrating a personalization process of a device;

FIG. 23A is a diagram illustrating a binding process in which a device associates with a server of a service provider to allow the device and server to share one or more symmetric keys;

FIG. 23B is a diagram showing a process for obtaining a one-time anonymous name from a server of a device during a binding process;

FIG. 24 is a schematic diagram showing an identity authentication process;

FIG. 25 is a schematic diagram showing a transaction control process;

FIG. 26 is a schematic diagram showing a process of unbinding a device from a service provider;

FIG. 27 is a schematic diagram showing a process of re-binding a device with one or more service providers;

FIG. 28 is a schematic diagram showing a data processing system for use with a device for multi-factor multi-channel identity authentication and control;

FIG. 29 is a schematic diagram showing a data processing system for use with a service provider's server for multi-factor multi-channel identity authentication and control;

FIG. 30 is a block diagram illustrating a payment system according to an embodiment of the present invention;

FIG. 31 is a flow chart illustrating a method for allowing a buyer to use an electronic device to pay for an item selected from the merchant in accordance with another embodiment of the present invention; and

FIG. 32 is a flow diagram illustrating a method for allowing a buyer to pay for an item selected from a merchant through a payment portal in communication with a plurality of participating entities, in accordance with another embodiment of the present invention.

Detailed Description

Fig. 1A-1D are diagrams of various designs of a handheld electronic authenticator. Referring to fig. 1A through 1D, each design provided by the authenticator has a keyboard (i.e., 105, 115, 130, and 140) with a plurality of keys to receive user input. The authenticator also has a display unit made of a Liquid Crystal Display (LCD), i.e., 110, 120, 125 and 135. The unique features of the above design are as follows. Referring to fig. 1A, the keyboard 105 and the display unit 110 may rotate about a common center point 145. In fig. 1B, the authenticator is foldable along a longitudinal rotation axis 150 connecting the keyboard unit 130 and the display unit 125. In fig. 1C, the keypad 115 and the display unit 120 are manufactured in one piece in the shape of a conventional key. In fig. 1D, the authenticator is rectangular like a calculator.

FIG. 2 is a block diagram of a logic design of a handheld electronic authenticator according to an embodiment of the present invention. Referring to fig. 2, the authenticator includes a calculation module 205, a support module 210, and other modules 215.

The calculation module 205 contains a calculation unit including a processor 250 for calculating the authentication code and a storage system for storing various data of the authenticator. The storage system includes: a read/write protection memory 255 for protecting data from external intrusion; a Read Only Memory (ROM)260 storing static data; and a Random Access Memory (RAM)265 that stores dynamic data generated during the authentication process. In addition to computing various authentication codes, the computing module 205 also performs other computing activities of the authenticator, such as executing instructions, decrypting messages, etc., which will be described in more detail below.

The support module 210 provides support for the computing module 205 in inputting/outputting data, providing power, and other aids to the proper functioning of the authenticator. The support module 210 includes: a display unit 220 such as an LCD screen for displaying data on the display unit 220 and a controller therein; a keyboard unit 225 such as a keyboard having 14 to 18 keys and 1 to 2 hidden keys for inputting data; and a power supply unit including a battery and a control circuit thereof.

Other modules 215 provide other functionality that may be added to the authenticator. A clock or timer 235 provides timing functions. The communication module 240 provides transmission capability for an external device based on a communication technology such as a Radio Frequency Identification (RFID) technology or an infrared technology. The biometric (biometric) module 245 takes as input a biometric of the user, such as the user's fingerprint, voice, or facial features, and incorporates an authentication code that is considered as an additional factor in the authentication process. The authenticator is extensible because more functionality can be added to the other modules 215. These modules may be implemented as hardware, software, or firmware components on the authenticator.

FIG. 3 illustrates read-protected memory 255 and RAM 265 in the storage system of compute module 205 in FIG. 2. As described above, the memory system may include read/write protected memory 255, ROM 260, and RAM 265. Referring to fig. 3, the public serial number 320, the key 325 of the authenticator, and the communication key 326 are stored in the read-protected memory 255 of the authenticator and are protected from external intrusion. The public serial number 320, the key 325, and the communication key 326 are secret information about the authenticator and are stored in the read-protect memory 255, and cannot be read by an external device under normal conditions even if they flow out from the authenticator.

The key and number stored in the read-protect memory 255 are set by the manufacturer of the authenticator during the manufacturing process of the authenticator. The server of the authenticator uses these keys and numbers to identify and provide services, i.e. start-up services and maintenance services, to the authenticator. The server of the authenticator may be one provided by the manufacturer or by an independent entity. In one embodiment, to enable communication between the authenticator and the server of the authenticator, the server of the authenticator obtains information about the key and number of the authenticator from the manufacturer before providing any services to the authenticator. The service procedure will be described in more detail below.

Key 325 is used to generate one or more one-time authentication codes (OTACs) for authentication using the server of the authenticator. In communicating with the server of the authenticator, the authenticator encrypts and decrypts data using the communication key 326 by using a symmetric cryptography scheme (symmetric cryptography scheme) or an asymmetric cryptography scheme (asymmetric cryptography scheme) determined by the server of the authenticator. When a symmetric cryptography scheme is selected, the authenticator and the authenticator's server encrypt and decrypt messages that communicate with each other using the same key. When an asymmetric cryptography scheme is chosen, the communication key is a private key of a pair of public and private keys, where the key pair is determined by the manufacturer. The authenticator uses the private key to encrypt and decrypt messages communicated with the authenticator's server. The server of the authenticator uses the public key to encrypt and decrypt messages from the authenticator. Symmetric and asymmetric cryptography schemes are well known in the art and a detailed description thereof is omitted for the sake of brevity.

The memory 310 stores dynamic data maintained by the server of the authenticator. For example, the server of the authenticator instructs the authenticator to write, change, and/or update data in memory 310. In one embodiment, an entity that maintains the memory 310 (also referred to herein as a "maintenance entity") controls the writing and updating of data in the memory 310, such as a server of an authenticator. In this embodiment, any entity (other than the maintenance entity) that contains the user of the authenticator cannot write directly to the memory 310. A user or another entity wishing to change the store 310 sends a request to the maintenance entity. For example, the memory may be set by a user or another entity by requesting and receiving code from a maintenance entity. Such code may contain encrypted commands and data executable within the computing module 205 to set up the memory.

The server that maintains the authenticator for memory 310 may include: the authenticator's public name 330, a plurality of access Personal Identification Numbers (PINs) 335 through 340, and other information stored therein. The server of the authenticator sets the above information through commands and data sent to the authenticator during start-up and maintenance. The start-up and maintenance procedures will be described in more detail below.

The memory 315 stores a plurality of foils 1 to N. Each foil in working condition is established to be exclusively associated with a service provider. The service provider is the entity with which the authenticator provides the OTAC for authentication. The service provider may be a credit card company, bank, online account, etc. Each of the foils is maintained by its respective service provider. Each foil provides the information required to generate the OTACs for its associated service provider. The authenticator may provide as many OTACs as the number of foils at the same time. When a particular service provider is specified by the user, the authenticator will calculate the OTAC based on the information stored on the foil associated with that service provider. The generation of OTACs will be described in more detail below.

Fig. 4 is a block diagram illustrating a logical design of one of foils 1 through N315 of fig. 3 according to an embodiment of the present invention. Referring to fig. 4, the foil 400 includes: static data 405 maintained by the service provider and dynamic data 410 maintained by the service provider and the authenticator. The static data 405 is maintained exclusively by the service provider associated with the foil. The static data 405 includes the foil's public name 415, the internally used foil serial number 420, the foil's key 425, the foil's communication key 430, the access PIN 435, other information 440, and the type 445. The service provider sets the static data through commands and data sent to the authenticator during the association process. The association process will be described in more detail below. Static data may be maintained/changed by the service provider on an irregular basis, as compared to dynamic data, which may be dynamic or frequently changing.

The dynamic data 410 maintained by the service provider and authenticator includes: quantity variable 450, such as the credit card balance when the service provider is a credit card company; a trace variable 455, which is a one-time variable that changes its value; an activity variable 460 storing information about activities performed by the service provider in the past; and other dynamic data 465 that stores more information about the service provider. Dynamic data 410 is commonly maintained by the service provider and the authenticator. That is, both the service provider and the authenticator may write to the memory storing the dynamic data 410. At the same time, the service provider maintains a copy of the dynamic data 410. When there is a change in the dynamic data 410 in the authenticator or service provider, the other copies will be updated accordingly while the authenticator is being maintained.

Fig. 5 is a flow chart illustrating a maintenance process for a handheld electronic authenticator according to an embodiment of the present invention. As depicted in fig. 3, the memory 310 is maintained by the server of the authenticator. When the user intends to update an item stored in the memory 310, such as the public name 330 of the authenticator, then a request must be sent to the server of the authenticator. Referring to fig. 5, in step 505, a user of an authenticator sends a request to a server of the authenticator. If the authenticator is authenticated by the authenticator's server using a similar process as used to authenticate the authenticator by the service provider, the authenticator's server will provide maintenance services to the authenticator. The authentication process of the service provider will be explained in more detail below. In step 510, the server of the authenticator sends the code back to the authenticator for providing the relevant data requested by the authenticator. The code is encrypted using the cryptographic scheme described above. In step 515, the user enters the encrypted code into the authenticator via a communication device such as a keyboard or other device. In step 520, the user presses a key (e.g., a hidden key) to initiate internal maintenance of the authenticator. By receiving the signal from the hidden key, the authenticator decrypts the encrypted code on the memory 310 and sets the data contained therein.

Figure 6 shows the process implemented internally by the server of the authenticator in figure 5 from when the maintenance request is received (in step 505) until the code is sent out (in step 510). Referring to fig. 5, after receiving a maintenance request from the authenticator, the authenticator will first authenticate whether the authenticator is an authenticated device by checking the OTAC generated based on the authenticator's key 325. The authentication process herein is similar to the authentication process used in service providers and will be described in more detail below. The server of the authenticator will then generate a work frame instruction in step 605. The work frame instructions contain maintenance data and commands corresponding to a user's maintenance request. In step 610, the server merges the maintained data according to the work frame instructions. In step 615, the server encrypts the frame according to a predetermined cryptographic scheme by using an encryption key associated with the authenticator and generates a code to be transmitted to the authenticator. Step 510 will then be performed according to the process described above in connection with fig. 5.

The start-up procedure performed prior to the first use of the authenticator is similar to the maintenance procedure described above in connection with fig. 5 to 6. When the authenticator completes the boot process, the service provider can start providing OTACs at any time.

Fig. 7 is a flow chart of a maintenance process of a foil of an authenticator according to an embodiment of the present invention. Referring to fig. 7, in step 705, the authenticator sends a request for maintenance to the service provider associated with the foil. In step 710, the service provider sends a request to the server of the authenticator for a start-up and maintenance request from the authenticator. The request contains the name of the authenticator and other information to indicate the particular authenticator to the server of the authenticator. In response, the server of the authenticator sends a work frame instruction and the authenticator's key back to the service provider in step 715. The work frame instruction contains data corresponding to the user's maintenance request maintained by the server of the authenticator. The key is 1) a communication key used to encrypt and decrypt codes sent between the service provider and the authenticator, and 2) a portion of the key to be combined with other portions to form the key and the communication key. In step 720, the service provider processes the information received from the server of the authenticator and sends the code back to the authenticator. In step 725, the user enters the code through a communication device such as a keyboard. In step 730, the user presses the hidden key to initiate internal maintenance of the foil. By receiving the signal from the hidden key, the authenticator decrypts the encrypted code and combines the data obtained from the code with the key in the authenticator to form the key of the foil and the communication key, and sets the data contained therein on the foil.

Fig. 8 illustrates a process performed internally by the service provider's server after receiving the work frame file (in step 715) for sending out code (in step 720) in fig. 7. Referring to fig. 8, after receiving the working frame file from the authenticator, the service provider selects settings for a particular foil in step 805. In step 810, the service provider places data maintained by the service provider corresponding to the server request into the received work frame file. In step 815, the server encrypts the frame file by using the key received in step 715. The server encrypts the frame file into a code consisting of a sequence of numbers using the key received in 715, according to a cryptographic scheme chosen by the service provider. The cryptographic scheme may be a symmetric cryptographic scheme or an asymmetric cryptographic scheme. The code generated using an asymmetric cryptography scheme is longer than the code generated using a symmetric cryptography scheme, but it is also more secure. The service provider may choose one of these two schemes or the other scheme that is more suitable for its purpose.

The initiation process of establishing an association between a service provider and an authenticator is similar to the maintenance process described above in connection with fig. 7-8. When the authenticator completes the boot process, OTACs can be started by the service provider at any time.

Each foil is started and maintained using the same procedure as described above in connection with fig. 7-8. After start-up or maintenance, the authenticator will be able to generate OTACs using the information provided on the foil of the authenticator used for authentication. The authentication process of the service provider will be described in more detail below.

One advantage provided by the present invention is that the service provider's server establishes a specific foil key 425 and a communication key 430. To make OTACs unpredictable, the key 425 and the communication key 430 are strictly confidential information, preventing others, such as hackers, from emulating the code. In current OTAC-based authentication systems, the manufacturer establishes and knows the key in the authenticator. In the present invention, since the service provider establishes the design of the key, and in the foil, the manufacturer does not know the key and cannot predict the code between the authenticator and the service provider. This design is more secure than current OTAC-based authentication systems because it eliminates the manufacturer from the system, which could be a potential source of compromised keys.

After start-up or maintenance, the specific foil is favorably associated with the service provider and is ready to provide OTACs for authentication. An authenticator may be used in authentication.

Fig. 9 is a flowchart illustrating an authentication process according to an embodiment of the present invention. Referring to fig. 9, in step 905, the user inputs data to instruct the authenticator to request OTACs with respect to the service provider. In step 910, the authenticator generates an OTAC based on the information associated with the service provider stored on the foil. In step 915, the user provides the public name 415 of the foil associated with the service provider and the OTAC to the service provider for authentication. Step 915 may be implemented by entering the OTAC into the service provider's website through an authentication page or interface. In step 920, the service provider determines whether to grant authentication, deny authentication, or send a request back to the authenticator for a new OTAC.

Fig. 10 to 12 describe the authentication process described in fig. 9 in detail. The OTAC is generated as a function of a plurality of inputs to a predetermined algorithm. Referring to fig. 10, as shown in 1005 and 1006, the inputs for generating the OTACs may include: a common name of the foil, a key, tracking information related to dynamic variables, activity information about past activities occurring on the foil, other information, server requests, and methods. The input is stored in both the authenticator as shown at 1005 and the server of the service provider as shown at 1006. Under ideal operating conditions, the two sets of

inputs

1005 and 1006 are identical. In steps 1010 and 1011, both the authenticator and the service provider generate OTACs based on the

inputs

1005 and 1006. The OTAC from the authenticator is an authentication code that the authenticator generates using one or more combinations of the information to be authenticated shown in 1005. The OTAC from the service provider is a verification code that is independently generated by the service provider using one or more combinations of the information shown in 1006, which is used to authenticate the authentication code. In steps 1020 and 1025, the authentication code and verification code are compared to each other. For example, the service provider compares the verification code with the authentication code received from the authenticator.

FIG. 11 is a flow chart subsequent to FIG. 10 further illustrating the step of comparing the authentication code and the verification code. Referring to fig. 11, in step 1105, the authentication code and the verification code are compared with each other. For example, the server compares the authentication code sent from the authenticator with the authentication code received at the service provider's server. If the two codes match, then in step 1115, the server may authenticate the authentication code and grant the requested access to the user of the authenticator. If the two codes do not match, the server will change the tracking input and the activity input within a predetermined range and generate a new verification code in order to adjust for the allowable inconsistency between the tracking input and the activity input of the authenticator and the service provider. This step is performed for the reasons described above, and both the tracking input and the activity input are dynamic data maintained by the authenticator and the service provider. Under ideal conditions, the tracking and activities in the authenticator and the service provider are the same. However, under normal operating conditions, multiple synchronizations of dynamic data cannot be updated or adjusted in time. Therefore, there may be small differences. These differences are allowed and are explained in one embodiment of the present invention.

In step 1110, the newly generated verification code within the predetermined range is further compared with the authentication code. If there is a match, the server will authenticate the authenticator in step 1120. If the authentication code deviates by a large extent from the verification code, the server will reject the authenticator in step 1128. If the authentication code is outside of the threshold, the authentication code may be determined to be widely divergent. The threshold is predetermined by the service provider according to its security policy. If the authentication code does not deviate by a large extent nor is it correct, the server will perform the next level of authentication in step 1125. After the next level of authentication, the service provider will decide whether to eventually reject the authentication request in step 1130 or send a request for a new authentication code in step 1135.

FIG. 12 is a flowchart subsequent to FIG. 11, further illustrating the step 1135 of requesting a new authentication code. As described above, when the authentication code does not match the verification code but does not deviate much, the service provider will send a request for a new authentication code. Referring to fig. 12, when the authenticator receives a code including a request from a service provider, the code is input to the authenticator in the other device or through a user key of the other device in step 1330. In this process, the authenticator generates a new authentication code with new server requests, tracking and activity inputs. The authenticator then sends the new OTAC to the service provider again. In response to receiving the new authentication code, the new authentication code is compared to the new verification code entered based on the new server request, tracking and activity, using the same steps as shown in FIG. 11.

The authenticator may also be used to generate electronic signatures. The process of determining the authenticity of the signature is similar to that described above in connection with fig. 10-12. Fig. 13 is a flow chart of a process of signature generation according to the present invention. The input for generating the signature may include: the common name of the foil, the key, tracking information relating to the dynamic variable, activity information about past activities occurring on the foil, other information, a signing request and a signing method. Any combination of a plurality of information may be used to generate the signature. The input is stored in both the authenticator shown in 1305 and the service provider's server shown in 1306. Under ideal conditions, the two sets of

inputs

1305 and 1306 are identical. In steps 1310 and 1311, the authenticator and the service provider both generate a signature OTAC based on the

inputs

1305 and 1306. The signature OTAC from the authenticator is the signature authentication code to be authenticated. The signed OTAC from the service provider is a signed verification code used to authenticate the authentication code. In steps 1320 and 1325, the signature authentication code and the signature verification code are aggregated together and compared to each other. For example, the server compares the signatures. The process for authenticating the signature authentication code thereafter proceeds as in the processes described in fig. 11 to 12. When the signature authentication code is authenticated, the signature is recorded and the basic transaction is confirmed.

Fig. 14-16 are flow diagrams of a process for using a handheld electronic authenticator in conducting a transaction.

Fig. 14 is a flow chart of a process for requesting services from a service provider using a handheld electronic authenticator. Referring to fig. 14, in step 1405, a user with an authenticator uses the public name on the foil and the OTAC generated therein to gain access to the service provider. In step 1410, the service provider approves, rejects, or requests a new OTAC using the procedures described above in connection with fig. 10-13. Similarly, the user may have access to all service providers, each associated with one of the foils of the authenticator. Using OTACs in combination with the public name of the foil (associated with the service provider), while the user can make a commercial transaction with the service provider, confidential information has never been disclosed in the process.

Fig. 15 is a flow chart of a process for using a handheld electronic authenticator in a transaction with a third party. The third party is the party, e.g. the supplier, who processes the transaction by the user of the authenticator during the transaction. The third party needs information of the user of the authenticator to conduct the transaction, such as a credit card number. The user of the authenticator can provide the public name of the foil and the OTAC to a third party without providing the credit card number to the vendor. This process is shown in fig. 15. Referring to fig. 15, the user of the authenticator provides the public name of the foil (associated with the service provider) and his OTAC to the opposite party of the transaction requiring confidential information (e.g. a bank account). In step 1505, the user party provides the public name and the OTAC. In step 1510, the partner requests access to the service provider using the public name and the OTAC. In step 1515, the service provider's server will approve, reject or request a new OTAC, as described above in connection with fig. 10-12. Since OTACs are dynamic variables, e.g., based on time, a counterparty cannot access a service provider after the period of time for which the OTACs are valid has elapsed.

Fig. 16 is a flow chart of a process for using a handheld electronic authenticator in a transaction for more data needed by a service provider. Referring to fig. 16, in step 1605, the user of the authenticator sends the public name of one foil and the OTAC to the server of the service provider. In step 1610, the service provider's server retrieves more data from the database. In step 1615, the service provider's server sends a transaction request to the transaction server. In step 1620, the transaction result is returned to the user when the authenticator is authorized, or a request or access denial for a new OTAC is returned.

As shown in fig. 14-16, during the transaction, only the common name of the foil and the foil generated OTAC are used to access the service provider. Confidential information such as credit card numbers or social security codes is not disclosed. When a transaction requires authentication, the public name of the foil (associated with its service provider) and the OTAC are used as a proxy for the confidential information. This approach provides the user with the convenience of alleviating the user's need to remember all of his/her confidential information. It also provides better security because the confidential information is not disclosed to either the third party or the communication channel used to obtain the access service provider.

Fig. 17 is a block diagram illustrating a multi-factor multi-channel authentication and transaction control system 2000 in accordance with an embodiment of the present invention. The system 2000 includes a handheld electronic device 2102, a terminal 2104 in communication with the handheld electronic device 2102, and a server 2106 of a service provider. The service provider is able to communicate with both the handheld electronic device 2102 and the terminal 2104 via the server 2106. The system 2000 further includes a server 2108 of the handheld electronic device 2102, which is capable of communicating with the handheld electronic device 2102, the service provider's server 2106, and the terminal 2104.

The handheld electronic device 2102 includes, but is not limited to, hardware and/or software components implemented in hardware, such as a cell phone or smart phone with specialized software. The handheld electronic device 2102 has a plurality of foils, each foil being associated with one or more service providers. The handheld electronic device 2102 also has components associated with the server 2108 of the device. For example, the handheld electronic device 2102 may also provide scanning, networking, displaying barcodes, performing Near Field Communication (NFC), and the like.

The terminal 2104 includes, but is not limited to, hardware and/or software components implemented in hardware. For example, the terminal 2104 may be a computer, a point-of-sale (POS) machine, or the like, having a web browser or possibly a user interface. The service provider's server 2106 includes, but is not limited to, a computer, processor, etc., that is capable of maintaining a database and implementing predetermined algorithms. The terminal 2104 and the service provider's server 2106 may be integrated into the same computer. The device's server 2108 is similar to the service provider's server 2106. In one embodiment, the device's server 2108 functions under predetermined circumstances, such as during the personalization and binding processes of identity authentication and transaction control described later. In one embodiment, the server 2108 does not participate in any processing during the authentication and transaction control processes. In one embodiment, server 2108 and server 2106 each provide at least one high security level communication channel. Therefore, even if the security level of the other communication channels of the server is not high, the security risk can be properly solved because the server 2106 and the server 2108 protect the authentication and the transaction control.

Fig. 18A to 18D are schematic diagrams illustrating communication between the handheld electronic device 2102 and the terminal 2104.

Fig. 18A illustrates scan-in communication (scan-in communication) in which information, such as a Quick Response (QR) code, is scanned from a terminal 2104 to a handheld electronic device 2102. Fig. 18B shows scan-back communication (scan-back communication) in which information such as a QR code is scanned back from the handheld electronic device 2102 to the camera 2112 of the terminal 2104. These two types of communication may be combined to provide scan-scan communication. For example, the user scans a barcode on the terminal screen using the handheld electronic device 2102, and the handheld electronic device 2102 then generates a corresponding barcode and displays the barcode on its own screen; the user then points the screen of the device 2102 at the camera 2112 of the terminal, which terminal 2104 reads and decodes the barcode generated by the device 2102.

Fig. 18C shows a typed communication in which a user enters information from the device 2102 into the terminal 2104 or from the terminal 2104 into the device 2102 via the keyboard 2114. The input communication may be combined with the scan input communication. For example, a user may scan a barcode on a screen of the terminal and then enter information displayed on a screen of the device into the terminal in response to the barcode.

Fig. 18D illustrates read/write communication, where the device 2102 can read information from the NFC tag 2116 of the terminal 2104 and write information from the terminal 2104 to its own NFC tag 2118. Similarly, the terminal 2104 may read information from the NFC tag 2118 of the device 2102 and write information from the device 2102 to its own NFC tag 2116. NFC communication is a form of communication that is activated only within a very short distance (the so-called near field). Such communication may be accomplished using various technologies, such as radio, acoustic, infrared, magnetic, optical (e.g., QR scanning). All of these categories are within the scope of the present invention.

The above-described communication between the device 2102 and the terminal 2104 may be one-way communication (such as scan-in communication) or two-way communication (such as scan-in and scan-back communication). These kinds of communications make the overall system 2000 user-friendly and faithfully reflect the user's intent, such that communications are only effectuated when the user wishes to utilize the communications. However, those of ordinary skill in the art will appreciate that communication between the device 2102 and the terminal 2104 is not limited to the types and forms described above.

Fig. 19A to 19B are schematic diagrams illustrating communication between the handheld electronic device 2102 and the server 2106 of the service provider.

The device 2102 may communicate directly with the server 2106, as shown in figure 19A. This direct communication may be enabled through the network capabilities of the device 2102, such as 2G, 3G, or WIFI communication, among others. The direct communication is a two-way communication.

The device 2102 can communicate indirectly with a server 2106 through a terminal 2104 as an intermediate station, as shown in fig. 19B. In indirect communication, the server 2106 transmits an instruction message including a message to be prepared by the terminal 2104, an encryption method of the message, a destination of the message, and the like, to the terminal 2104. The terminal 2104 sends the processed message to the device 2102. After receiving the message from the terminal 2104, the device 2102 generates a response message and sends the response message back to the terminal 2104. After receiving the response message, the terminal 2104 sends it to the server 2106 or to another server 2106', which is designated by the server 2106 and is typically another server of the same service provider. Different servers may communicate with each other and the communication may be considered an internal communication, with a satisfactory level of security. For example, the terminal 2104 does not decrypt the message, but rather sends the message according to instructions. The device 2102 and the server 2106 share a symmetric key, allowing the device 2102 and the server 2106 to establish a highly secure communication channel and communicate with each other appropriately. Therefore, even if communication passes through the terminal 2104, the communication is multi-channel communication, enabling effective detection of an attack (such as a MITM attack).

Fig. 20 is a schematic diagram illustrating communication between a terminal 2104 and a service provider's server, such as server 2106 and server 2106'. The communication between the terminal and the server may be synchronized, such as a TCP/IP socket. Alternatively, the communication may be an asynchronous communication, such as a JAXA interaction. For example, the terminal 2104 may have an internet communication channel with a server. Through the internet, the server can instruct the terminal 2104 to send information to the destination determined by the server. Since the system 2000 integrates several levels of one-time code, the server-side will recognize any violations of instructions, such as violations caused by an attack.

Figure 21 is a schematic diagram illustrating communication between the server 2108 of the device 2102 and a server of a service provider, such as server 2106 and server 2106'. Communication between the server 2108 of the device 2102 and the servers 2106, 2106' of the service provider is only used when the device 2102 is associated (by a binding process) or disassociated (by a unbinding process) with the service provider. The device server 2108 communicates with all servers of the service provider in a high security level communication channel. The communication of the server can be a high security level communication and the communication during the binding/unbinding process can be implemented in a common communication channel. Thus, the device's server and the service provider's server protect the communication even if an attacker were to intrude into the communication channel. To ensure a higher level of security, the communication channel between the servers may be set to a higher level of security.

According to an exemplary aspect of the invention, a multi-factor multi-channel identity authentication and transaction control method is provided. The method will now be described with reference to the system 2000 shown in fig. 17.

The method includes personalizing (personalizing) the handheld electronic device 2102 to allow the device to share at least one symmetric key with a server 2108 of the device. Personalization of the device 2102 may be accomplished on-site when the device 2102 is manufactured or by installing pre-personalized hardware to the device 2102.

Alternatively, personalization may be achieved by the process shown in fig. 22. After a user installs a software component on his/her device (such as a smartphone), the software component has not been personalized. Thus, there is no unique data for the device. The following process may create unique data for the device and thereby personalize the device.

First, a user of the device 2102 sends a personalization request, which may be sent to the server 2108 of the device via the terminal 2104. After exchanging transaction related data (such as payment, identification, etc.), the server 2108 generates and sends a first key exchange message to the terminal 2104. The device 2102 receives a first key exchange message from the terminal 2104 and generates a second key exchange message based on the first key exchange message. The second key exchange message is sent to the server 2108, either directly or indirectly through the terminal 2104, and this process is performed over multiple channels. The server 2108 then generates one or more symmetric keys based on the first key exchange message and the second key exchange message, and shares the symmetric keys with the device 2102. The above steps may be repeated a number of times depending on the safety requirements. The key exchange method may be the known Diffie-Hellman key exchange algorithm or a similar key exchange method. Furthermore, although QR code scanning is shown, the personalization process may be used in conjunction with NFC.

Alternatively, the personalization process described above can be used to embed the private key into the device 2102 and the public key into the server 2108, which can be generated and delegated according to a different authorization than the server 2108.

Fig. 23A is a schematic diagram illustrating the binding process of this method, wherein the device 2102 is associated with the server 2106 of the service provider to allow the device 2102 and the server 2106 to share one or more symmetric keys.

After personalization, the device 2102 has a unique public name and only shares confidential information of the device 2102 with the device's server 2108. Now the device 2102 needs to bind a server of the service provider (such as server 2106), after which the device 2102 has a symmetric key shared with the particular service provider, which is shared only by the device 2102 and the server 2106. The device may bind any number of service providers depending on the application. The server 2108 of the device can facilitate this binding process.

First, the user determines the name to present to the service provider. He/she may use the public name of the device or may obtain a one-time anonymous name for the device from the server 2108 of the device. If he/she chooses to use a public name or is asked to use a public name, there is a potential risk of revealing his/her identity. If he/she chooses to use a one-time anonymous name, the service provider is unable to reveal his/her identity. In order to use the one-time anonymous name, he/she may operate according to the steps shown in fig. 23B described later.

Next, the user sends a binding request to the service provider, for example, through the terminal 2104. After exchanging transaction related information (such as payment, identification, etc.), the service provider's server 2106 requests an identifier (public name or one-time anonymous name) of the device 2102 and one or more OTACs generated by the device 2102. This information is sent to the server 2106, for example, through the terminal 2104.

The service provider's server 2106 further sends the information to the device's server 2108.

Upon receiving the information from the service provider's server 2106, the device's server 2108 determines the validity of the device 2102. If the device 2102 is active, the server 2108 sends one or more binding instruction codes to the service provider's server 2106.

The service provider's server 2106 selects its own communication key and encrypts the key based on the binding instruction code. The encryption key is sent to the device 2102, for example, through the terminal 2104.

After receiving the information from the terminal, the device 2102 performs a key generation process including several types of decryption and encryption and the like based on the symmetric key shared with the server 2108 of the device and the received information. After this process, the device 2102 shares a symmetric key with the service provider.

Alternatively, the device 2102 may send a confirmation message back to the service provider's server 2106, either directly or indirectly through the terminal 2104.

The above steps can be repeated according to the safety requirement.

After the device 2102 shares the symmetric key with the service provider's server 2106, the binding process is complete. The encryption method used in passing information from the server 2106 to the device 2102 may be any strong encryption method. For example, if input needs to be entered, a reserved format encryption may be used. In any case, the communication is secure, even if not encrypted, in passing information from the server 2106 to the device 2102.

Alternatively, the above described process may be used to embed the private key into the device 2102 and to embed the public key into the service provider's server 2106. The pair of private and public keys (commonly referred to as digital certificates) may be transferred in accordance with an authorization selected by the server 2108.

Figure 23B illustrates the process of obtaining a one-time anonymous name from the device's server 2108 such that the user's identity remains anonymous to a particular service provider.

First, the user sends a request to the server 2108 of the device. After one or more rounds of exchange of transaction-related information (such as payment, authentication, etc.), the server 2108 of the device generates a one-time anonymity for the device and saves it in a database. The anonymous name is valid for a predetermined time.

Device 2102 receives messages from server 2108 via terminal 2104 and processes data according to instructions embedded in the messages. Thereafter, the one-time anonymous name is inserted into the device 2102. The device 2102 may retrieve the anonymous name for a predetermined time.

Fig. 24 is a schematic diagram showing an identity authentication process. After successfully binding the service provider, the device 2102 shares confidential information with the service provider, which is properly protected by hardware and software and is not used externally or is not transferred in any form.

First, for example, a user sends an authentication request to the server 2106 of the service provider through the terminal 2104 using a first communication channel.

Upon receiving the request, the service provider's server 2106 generates and sends an instruction message to the terminal 2104, which contains instructions for the device 2102. The instruction message is sent to the device 2102 via the terminal 2104 using a first communication channel. The first communication channel may be any information communication channel such as the internet, telephone, private network, etc. For example, the server 2106 may produce a QR code and send the code to the terminal 2104; the device 2102 may read the code from the terminal.

The device 2102 generates a response message based on the instruction message and transmits the response message to the server 2106 through a second communication channel different from the first communication channel. For example, the response message may include authentication credentials, such as a username, a one-time password, or a condition for generating a one-time password. For example, a response message may be generated by processing the QR code.

After receiving the response message, the server 2106 performs multi-channel multi-factor authentication. The server 2106 can generate an authentication message based on the authentication credentials and then send the authentication message to the terminal 2104 in order to activate the terminal. For example, authentication is based on two factors. A factor of 1 indicates that only the user with the device can generate a message; a factor of 2 indicates that only users who know a particular message (knowledge) can generate a message. Performing authentication based on a plurality of channels: one channel between the service provider and the terminal 2104 and another channel between the device 2102 and the service provider, as shown in fig. 19A to 19B. The steps of generating a response message and sending the response message to the service provider may be repeated as necessary (such as higher security requirements, suspicion of an attack, or intent to renew the key).

Fig. 25 is a schematic diagram showing a transaction control process of the method. The device 2102 may have a private key and the service provider may have a public key, both of which are collectively referred to as a digital certificate. Private/public key algorithms may be suitable for transaction control, e.g. for managing transaction records, such as digital signatures.

Assuming that the transaction is completed after the authentication, the user sends a transaction record request. The service provider's server 2106 sends a form, such as a transaction information form, to the terminal 2104. The user is required to fill out the form with transaction information, such as payment to a third party. The user fills out the form with the transaction-related data and sends it back to the server 2106 via the terminal 2104.

The server 2106 receives the information from the terminal 2104 and initially determines validity and sends an instruction message back to the terminal 2104 to request confirmation.

Upon receipt of the instruction message, the device 2102 generates a response message and sends the response message back to the server 2106 over multiple channels.

Upon receiving the response message from the device 2102, the server 2106 performs a 2-factor authentication, wherein a factor of 1 indicates that only the user with the device can generate the message; a factor of 2 means that only users who are aware of a particular message can generate a message. Authentication is performed over multiple channels: one channel between the service provider and the terminal and another channel between the device and the service provider.

The steps of preliminary determining, generating a response message, and sending the response message over multiple channels may be repeated as necessary (such as higher security requirements, suspicion of an attack, or intent to update the key).

If necessary (such as regulatory compliance, etc.), in the above steps, a digital signature of the user may be generated and sent to the service provider. For example, in the step of generating the response message, a message based on the symmetric key and/or the asymmetric key may be generated according to an instruction of the service provider.

Fig. 26 is a diagram illustrating a procedure of unbinding a device with a service provider according to the method. In some cases, the unbinding process is required to be performed, for example, when the device 2102 is lost or the user of the device intends to stop using the device for all service providers. This unbinding procedure avoids the cumbersome process of contacting all service providers individually. The unbinding process further allows the user to suspend the service.

First, for example, a user sends a request to the server 2108 of the device 2102 through the terminal 2104. At this stage, the necessary transaction steps (such as payment transactions, etc.) are completed, and authentication is accomplished through an alternate method. At this stage, the server 2108 further determines all service providers that are associated with or have records for the device.

The server 2108 then sends a unbind request to all service providers, the device 2102 being associated with all service providers and its server 2108 having a record (no record for anonymous communications). The service provider's server then determines whether a unbinding process should be performed. If so, the service provider's server disassociates with the device 2102 via the respective server to terminate sharing of the symmetric key with the device 2102.

FIG. 27 is a schematic diagram illustrating a process for re-binding a device and one or more service providers in accordance with an aspect of the method. For example, the user loses his/her device and unbinds the device from all service providers to ensure that no further transactions can be made. He/she later obtains a new device and intends to bind the device with all previous service providers. Through the re-binding process, the device can be re-bound with all service providers simultaneously.

First, the user selects a terminal (such as terminal 2104) through which the re-binding process can be conducted. The user sends a re-bind request to the server 2108 of the device via the terminal. After the necessary steps (such as payment transactions, etc.) and authentication by the backup method (since the user no longer has a previous device), a personalization process will be performed to allow the device 2102 and the server 2108 to share a set of symmetric keys, which may be the same or different from the previous symmetric key personalized before the unbinding process.

After personalization, the process of re-binding all previous service providers is started. The server 2108 of the device 2102 sends a rebinding request to all service providers with which the device is associated and whose server 2108 maintains a record (no record for anonymous communications). The service provider's server determines whether to perform a rebinding process.

If the service provider determines to re-bind, its server performs the binding step shown in FIG. 23A and generates encrypted information. This information is sent to the public service computer 2110. Similarly, all service providers send information to the same service computer 2110. After receiving all the information from the service provider, the service computer sends a notification to the device's server 2108 and the server 2108 sends a corresponding notification to the device 2102.

Upon receiving the notification from the server 2108, the user communicates with the service computer 2110 through the terminal 2104. For example, all the rebinding information is displayed on the terminal. All the rebinding information is then acquired by the device 2102 for processing, which enables a set of symmetric keys to be shared between the device 2102 and the server of the service provider. The user may also send a confirmation message back to the service provider's server. In one embodiment, the above steps are performed over a plurality of channels.

Systems and methods according to an aspect of the invention can perform the following steps: personalizing the handheld electronic device, binding the device with any selected service provider, authenticating with any service provider, controlling a transaction with any service provider, maintaining anonymity of the device with any service provider during authentication and transaction control, collectively unbinding the device from the service provider (e.g., in the event of device loss), and collectively re-binding the device and all service providers.

FIG. 28 illustrates a data processing system 3000 in accordance with another aspect of the present invention. The system 3000 is used in conjunction with the device 2102 for multi-factor multi-channel authentication or transaction control. The system 3000 includes a personalization module 3100, a binding module 3200, and a processing module 3500 in communication with a transmission module 3300 and a reception module 3400. The personalization module 3100 is configured to personalize the device 2102 and the server 2108 of the device such that the device and the server share one or more symmetric keys. The binding module 3200 is configured to bind the device 2102 and the server 2106 of the service provider together such that the device and the server 2106 share a symmetric key. The transmission module 3300 is configured to send a message to the peripheral device, such as an authentication or transaction control request to the server 2106. The receiving module is configured to receive a message from a peripheral device, such as an instructional message from a server 2106 of a service provider. The processing module 3500 is configured to generate a response message based on the received instruction message. The response message is sent to the service provider's server 2106 for multi-channel multi-factor authentication or transaction control. The system 3000 may include one or more processors or similar devices to execute one or more modules of the system 3000.

FIG. 29 illustrates a data processing system 4000 in accordance with another aspect of the invention. The system 4000 is used in conjunction with a service provider's server 2106 for multi-factor, multi-channel identity authentication and/or transaction control. The system 4000 includes a binding module 4100 and a processing module 4300 in communication with a receiving module 4200 and a transmitting module 4400. The binding module 4100 is configured to bind the server 2106 to the device 2102 so as to allow the server and the device to share one or more symmetric keys, which are shared between the device 2102 and the server 2108 of the device 2102. The receiving module 4200 is configured to receive messages from peripheral devices, such as identity authentication or transaction control requests from the device 2102. The processing module 4300 is configured to generate an instruction message after receiving a request from a device. The transmission module 4400 is configured to send messages to peripheral devices, such as an instruction message to the device 2102. The receiving module 4200 receives a response message generated by the device 2102 based on the instruction message. The processing module 4300 is further configured to perform multi-channel multi-factor identity authentication or transaction control for the device based on the received response message. The system 4000 may include one or more processors or similar devices to execute one or more modules of the system 4000.

All these processes are performed in a multi-factor, multi-channel manner. In one embodiment of the invention, the steps of identity authentication and transaction control may be performed only between the device and the service provider, without involving a third party, in addition to the personalization, binding, unbinding and rebinding steps. Thus, there is no need for a centralized server in the authentication and transaction control process. Centralized servers make it difficult to scale the overall system and expensive to operate, undermining the management of the information and privacy of the consumer by the service provider. Only the server of the device is needed to assist in the binding, unbinding and rebinding processes during which the user's ID is properly protected, such as by remaining anonymous. An advantage of exemplary embodiments of the present invention is, at least in part, that a third party is not always required in the authentication and transaction process.

Fig. 30 is a block diagram illustrating a payment system 5000 according to an exemplary embodiment of the present invention. The payment system 5000 includes an electronic device 5200, which is typically a hand-held electronic device used by individual buyers. The electronic device 5200 includes (but is not limited to) hardware and/or software components implemented in hardware, such as a cell phone or smart phone with specialized software. For example, the electronic device 5200 may also provide functionality to scan, network, display barcodes, perform Near Field Communication (NFC), and so forth.

During an electronic transaction, the electronic device 5200 communicates with a server 5400 of a merchant that sells items to consumers. For example, electronic device 5200 may communicate with servers of multiple merchants through multi-channel communication. Authentication of the electronic device 5200 and control of transactions between the device 5200 and the server 5400 have been previously discussed.

The merchant's server 5400 includes, but is not limited to, a computer, processor, etc., that is capable of maintaining a database and implementing a predetermined algorithm. For example, the merchant may be an online sales website, such as

Or

After the buyer selects one or more items and orders the selected items, the merchant's server 5400 generates a code, such as a Quick Response (QR) code, and transmits the code to the terminal 5600 through the first communication channel. The channel may be any information communication channel such as the internet, private network, etc. The code is formed based on the transaction-related information and the merchant information. Transaction-related information includes, but is not limited to, the identification of the selected item, the price of the selected item, the recipient of the selected item, the shipping address of the selected item, and the recipient of the confirmation message after shipment. The merchant information includes, but is not limited to, one or more identities of the merchant, a description of the merchant, and a signature with a symmetric key for the merchant and a payment portal (to be described later).

The terminal 5600 includes, but is not limited to, hardware and/or software components implemented in hardware. For example, the terminal 5600 may be a computer, point of sale (POS) machine, or the like, having a web browser or similar user interface. For example, the communication between the electronic device 5200 and the terminal 5600 may be a scan-in communication with which the QR code is scanned from the terminal 2104 to the handheld electronic device 5200 by the camera 5210 of the electronic device 5200.

The electronic device 5200 includes a transceiver 5220 that receives the QR code scanned by the camera 5210 and transmits the code to the processor 5230. The processor 5230 processes the QR code to retrieve and display transaction-related information on the display screen 5240. Transaction-related information includes, but is not limited to, the identification of the selected item, the price of the selected item, the recipient of the selected item, the shipping address of the selected item, and the recipient of the confirmation message after shipment. The retrieved information may be in text form or code form as long as the buyer can understand the information. For example, displaying the retrieved information on the display screen 5240 facilitates the buyer to visually verify the transaction-related information so that the transaction-related information for the goods desired by the buyer can be verified.

If the buyer determines that all transaction-related information is accurate and determines to continue to pay for the selected item, the buyer may initiate the payment process, for example, by touching a button displayed on the screen 5240. Alternatively, the purchaser may initiate the payment process by entering some specially designed code or performing biometric input so that it can be ensured that the selected item is what the purchaser intends to buy and that an additional layer of security is incorporated. In response, a user interface 5250 is displayed on the screen 5240 for the purchaser to select a payment option from a plurality of predetermined payment options. For example, payment options include (but are not limited to) credit card payments, debit card payments, third party payments, bank transfer payments, and small account payments. Based on the transaction information and the selected payment option, the processor 5230 generates a payment message that includes a first segment and a second segment.

The first segment includes a first segment related to the selected payment option and the second segment includes information about the buyer's account data related to the selected payment option. For example, if the buyer has selected the credit card payment option, a first piece of the payment message is generated to have an identifier corresponding to the credit card payment option and a second piece is generated to indicate the buyer's credit card account previously saved in the database 5260.

The payment message is sent to the payment portal 5800 through the transceiver 5220. Communication between the device 5200 and the payment portal 5800 occurs over a second communication channel. The multi-channel communication method has been discussed in advance. For example, the second communication channel is different from the first communication channel between the merchant's server 5400 and the electronic device 5200. Portal 5800 includes, but is not limited to, a computer or the like, which is capable of maintaining a database and implementing predetermined algorithms. Portal 5800 communicates with servers of a plurality of Participating Entities (PEs), such as PE 1-PE N. Each of the participating entities is associated with at least one of a plurality of predetermined payment options. For example, the participating entity may be any suitable participating financial institution, such as a bank, credit card company, third party payment institution, and small account payment institution, among others. For example, PE 1 is a credit card company, PE 2 is a bank, and PE 3 is a third party payment authority.

Portal 5800 receives the payment message through transceiver 5810. The transceiver 5810 transmits a payment message to the processor 5820. The processor 5820 selects an appropriate participant entity associated with the selected payment option based on the first segment of the payment message. For example, the processor 5820 retrieves an identifier from the first segment and compares the identifier to identifiers of participating entities stored in the database 5830 to select a participating entity that is associated with the selected payment option. For example, if the selected payment option is a credit card payment option, the processor 5820 selects PE 1, which is a credit card company associated with the buyer.

Once the participant entity is selected, the processor 5820 instructs the transceiver 5810 to send the second segment of the payment message to the participant entity. After authenticating portal 5800, the selected participant entity processes the second segment of the payment message to determine whether the buyer account associated with the selected payment option is valid. If the account is valid, the selected participating entity generates an instructional message indicating that payment is to be made via the payment option selected by the buyer. Otherwise, the selected participant entity generates an instruction message indicating that payment cannot be made via the payment option selected by the buyer.

Portal 5800 receives the instructional messages through transceiver 5810 and further transmits the instructional messages to the merchant's server 5400 through a third communication channel. For example, the third communication channel is different from the first communication channel between the merchant's server 5400 and the electronic device 5200 and the second communication channel between the electronic device 5200 and the payment portal 5800. For example, after the merchant's server 5400 receives the instruction message, the clearing house will have a money transfer occurring.

Authentication between the electronic device 5200 and the portal 5800 is described below. The payment message comprises a first submessage MPO1 for use by the payment portal 5800 and a second submessage MPE for use by the PEs associated with the payment portal. The portal 5800 authenticates the electronic device 5200 based on the first sub-message MPO1, and if the authentication is successful, the portal 5800 transmits a second sub-message MPE to the PE. The first sub-message MPO1 is formed based on transaction-related information for the good, a description of the merchant, PE-related information (such as information relating to the bank), a signature with the symmetric key of the electronic device and the portal, and a unique identifier of the buyer. The second sub-message MPE is formed based on a description of the merchant, PE-related information, encryption of buyer account information related to the PE and, optionally, a digital signature of the buyer (if required by the PE).

Several symmetric keys are established between the electronic device 5200 and the portal 5800 for authentication of the electronic device 5200, a process which has been discussed in advance. The symmetric key is the basis for 2-factor authentication. In addition, the buyer may have a unique identifier, such as a password or fingerprint, that is not shared with the portal. The buyer's account information associated with the PE may be encrypted using the PE's public key or may be encrypted by other known methods preferred by the PE.

Alternatively, the electronic device 5200 and the PE may also share a symmetric key. The establishment of the shared symmetric key has been discussed in advance. The digital signature in the second sub-message of the payment message is typically obtained by means of a public-private key pair. However, the digital signature may be obtained by other known methods preferred by the PE.

The instruction message sent by the PE to the merchant's server 5400 through portal 5800 comprises a payment protocol message including a first sub-message MPO2 for use by portal 5800 and a second sub-message MME for use by the merchant's server 5400. During communication, the portal 5800 authenticates the PE based on the first sub-message MPO 2. If the authentication is successful, the portal 5800 sends the second sub-message MME of the payment message and the first sub-message MPO1 to the merchant's server 5400. The second sub-message MME is formed based on the merchant description, buyer-related information, PE-related information, payment agreement and PE signature. The first sub-message MPO2 is formed based on a signature with a symmetric key shared between the PE and the portal 5800. The establishment of a shared symmetric key between a PE and a portal 5800 has been discussed in advance.

The transceiver 5220, processor 5230, user interface 5250, and database 5260 may be incorporated into a data processing system used in conjunction with the electronic device 5200. Transceiver 5810, processor 5820, and database 5830 may be incorporated into a data processing system for use in conjunction with a payment portal.

FIG. 31 is a flow chart illustrating a method for allowing a buyer to pay for one or more items selected from a merchant using an electronic device in accordance with an embodiment of another aspect of the present invention.

In step 6100, a code representing transaction-related information associated with the selected item is received by the electronic device. In step 6200, transaction-related information is retrieved from the code. In step 6300, the transaction-related information is verified. In step 6400, at least one payment option is selected from a plurality of predetermined payment options. In step 6500, a payment message is generated based on the transaction-related information and the payment options. The payment message includes a first segment representing payment options and a second segment representing account data of the buyer relating to the payment options. In step 6600, a payment message is sent to a payment portal in communication with a plurality of participant entities. Each of the participating entities is associated with at least one of a plurality of predetermined payment options.

FIG. 32 is a flow diagram illustrating a method for allowing a buyer to pay for one or more items selected from a merchant through a payment portal in communication with a plurality of participating entities, in accordance with an embodiment of another aspect of the present invention. Each of the participating entities is associated with at least one of a plurality of predetermined payment options.

In step 7100, a payment message is received by a payment portal. The payment message includes a first segment representing a payment option selected by the buyer from a plurality of predetermined payment options and a second segment representing account data of the buyer relating to the selected payment option. In step 7200, a participant entity associated with the selected payment option is selected based on the first segment of the payment message. In step 7300, a second segment of the payment message is sent to the selected participant entity to verify the buyer's account with respect to the selected payment option. In step 7400, an instructional message generated based on the validity of the buyer account is received from the selected participating entity. In step 7500, an instruction message is sent to the merchant's server.

Embodiments of the present invention have several advantages. For example, the buyer's account information is saved and selected on the electronic device, but not saved on the payment portal, which makes the electronic payment system more secure. In addition, the portal has the ability to expand its connectivity with multiple participating entities. Thus, the buyer has a variety of payment options.

Various aspects of the invention may be implemented as a program, software, or computer instructions embodied on a computer-or machine-usable or readable medium that, when executed on a computer, processor, and/or machine, cause the computer or machine to perform the steps of the method. A program storage device readable by a machine tangibly embodying a program of instructions executable by the machine to perform various functions and methods described in this disclosure is also provided.

The above-described systems and methods of the present invention may be implemented or performed on a general purpose computer or a special purpose computer system. The computer system may be any type of known or to be known system and may generally include a processor, memory, storage devices, input/output devices, an internal bus, and/or a communication interface for communicating with other computer systems in conjunction with communication hardware and software, etc.

The computer program product may include any tangible or tangible medium capable of storing data and/or computer instructions, e.g., readable and/or executable by a computer, machine, or the like. Examples may include, but are not limited to, memory (such as Random Access Memory (RAM), Read Only Memory (ROM), etc.), optical disks, optical storage devices, and other apparatus.

The terms "computer system" and "computer network" as may be used in the present invention may include various combinations of fixed and/or portable computer hardware, software, peripherals, and storage devices. A computer system may include multiple separate components networked or connected to perform cooperatively, or may include one or more separate components. The computer system hardware and software components of the present application may include and be incorporated into fixed and portable devices such as desktop, notebook, server, and the like. A module may be a device, software, a program, or a component of a system that implements some "functionality," which may be implemented as software, hardware, firmware, circuitry, etc.

The embodiments described above are illustrative examples, and it should not be understood that the present invention is limited to these specific embodiments. Accordingly, various changes and modifications may be effected therein by one skilled in the art without departing from the spirit and scope of the invention as defined in the appended claims.

Claims

1. A method of a user device remaining anonymous to a service provider during multi-factor multi-channel authentication and transaction to the user device, wherein the user uses a device that communicates with a server of the device through a terminal, the method comprising:

binding the equipment with a server of the service provider, realizing the personalization of the equipment by installing prefabricated personalized hardware or realizing the personalization of the equipment by installing preset personalized software on the equipment;

generating a one-time anonymous identifier for the device, the one-time anonymous identifier valid for a predetermined time; and sending the one-time anonymous identifier to the device, the one-time anonymous identifier being retrievable by the device within the predetermined time;

receiving, by the terminal, a request from the device;

exchanging transaction related data with the device;

wherein after binding the device with a server of the service provider, further comprising:

performing multi-channel multi-factor identity authentication and transaction verification on the device through a server of the service provider.

2. The method of claim 1, wherein performing multi-channel multi-factor identity authentication and transaction verification on the device by the service provider's server comprises:

transmitting, by the terminal, an authentication request to a server of the service provider using a first communication channel; sending, by the terminal, an instruction message to the device using the first communication channel;

the device generates a response message based on the instruction message and sends the response message to the server of the service provider through a second communication channel different from the first communication channel, wherein the server of the service provider performs multi-channel multi-factor identity authentication and transaction verification according to the response message.

3. The method of claim 2, wherein,

performing multi-channel multi-factor identity authentication and transaction verification on the device by the service provider's server includes: performing authentication based on two factors, performing authentication based on two channels, wherein the two factors include: one representing a first factor by which only the device can generate messages, and the other representing a second factor by which only devices that are aware of a particular message can generate messages; the two channels include: one is a first communication channel between the server of the service provider and the device and the other is a second communication channel between the server of the service provider and the terminal.

4. The method of any of claims 1 to 3, further comprising:

performing a unbinding operation of the service provider's server with the device.

5. The method of claim 4, wherein after performing the unbinding operation for the service provider's server and the device, further comprising:

performing a re-binding operation of a server of the service provider with the device.