EP2652631A2 - Automatic user authentication, online checkout and electronic payments via mobile communication device with imaging system - Google Patents

Automatic user authentication, online checkout and electronic payments via mobile communication device with imaging system

Info

Publication number
EP2652631A2
EP2652631A2 EP11848042.5A EP11848042A EP2652631A2 EP 2652631 A2 EP2652631 A2 EP 2652631A2 EP 11848042 A EP11848042 A EP 11848042A EP 2652631 A2 EP2652631 A2 EP 2652631A2
Authority
EP
European Patent Office
Prior art keywords
payment
identifier
graphical
user
computer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP11848042.5A
Other languages
German (de)
French (fr)
Other versions
EP2652631A4 (en
Inventor
Shaun Cooley
Charles Andrew Payne
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NortonLifeLock Inc
Original Assignee
Symantec Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US12/969,471 external-priority patent/US9076171B2/en
Priority claimed from US12/969,510 external-priority patent/US8177125B1/en
Priority claimed from US12/969,303 external-priority patent/US8856902B2/en
Application filed by Symantec Corp filed Critical Symantec Corp
Publication of EP2652631A2 publication Critical patent/EP2652631A2/en
Publication of EP2652631A4 publication Critical patent/EP2652631A4/en
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
    • G06F21/35—User authentication involving the use of external additional devices, e.g. dongles or smart cards communicating wirelessly
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/36—User authentication by graphic or iconic representation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/42—User authentication using separate channels for security data
    • G06F21/43—User authentication using separate channels for security data wireless channels
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3276—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being read by the M-device
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists

Abstract

A graphical authentication identifier is used to facilitate automatic authentication of a user, the checkout of a user on a webstore, or the automatic processing of an electronic payment. A graphical identifier authentication system receives a request from an authenticating entity for a onetime use graphical authentication identifier. In response to the received request, a onetime use graphical authentication identifier to be displayed by the authenticating entity is generated. A request for user authentication information by the authenticating entity is encoded in the graphical authentication identifier, which is transmitted to the authenticating entity for display (e.g., on a login screen). The onetime use graphical authentication identifier being displayed by the authenticating entity is captured by a registered user operated computing device. In response, the requested user authentication information is transmitted to the authenticating entity, such that the user is automatically authenticated to the authenticating entity, without the user manually entering the requested user authentication information.

Description

Automatic User Authentication, Online Checkout and Electronic Payments Via Mobile Communication Device With
Imaging System
Technical Field
[001] This disclosure pertains generally to computer security, and more specifically to using graphical identifiers for automatic user authentication, automatic online checkout and automatic electronic payments.
Background
[002] Computer users typically login to many different websites (banking sites, shopping sites, work related sites, social networking sites, etc.), each of which requires a username and password. This frequent password- based logging in is inconvenient for users and creates opportunities for malicious parties to steal passwords. Users have the choice between using a different password for every website they login to, or repeating passwords across multiple sites. Using a different password for each site results in a large number of passwords for the user to manage. In such situations, users tend to forget their passwords, and therefore can find themselves unable to login to desired sites. To address this problem, some users
3 write down their passwords in accessible locations, but this creates a security risk. Another partial solution is the use of a password manager, but this only works on the computer on which the password manager is installed, or on a computer which is synchronized thereto. This leaves the user unable to login to websites from other computers, such as those in hotel business centers, internet cafes, libraries, etc.
[003] On the other hand, using the same password across multiple sites is not good security practice. If the single password becomes compromised, all of the user' s accounts become vulnerable. Some users repeat passwords only across types of sites (for example, one password for social networks and a different password for financial sites) . Even then, many users have a hard time remembering their passwords. Additionally, using a limited number of different passwords still creates more security risk than using a unique password for each site.
[004] Malicious parties are able to steal passwords through various methods such as phishing, key loggers, network traffic monitoring, malicious browser plugins, and the replay of passwords captured for other sites. Password managers prevent password theft by key loggers (and mitigate phishing to some extent) but still leave the user vulnerable to other types of password misappropriation.
[005] It would be desirable to address these issues concerning password-based logins.
[006] Two factor authentication is becoming increasingly prevalent as laws are passed that require financial institutions to implement additional security measures. Two factor authentication is authentication of a user that requires two separate means of proof of the user's identity. In one factor authentication, the user can verify his or her identity with a single factor such as
(most commonly) a password as described above, or
(alternatively) a rolling value generated by a physical token or a biometric indicator such as a finger print or retina scan. In two factor authentication, two such factors (e.g., password and rolling value) must be provided. The most common form of two factor authentication currently uses a static user entered password as the first factor, with the addition of a rolling value that is generated and displayed to the user by a hardware key fob (such as RSA SecurlD) or a specialized mobile device (such as Verisign VIP) .
[007] These hardware devices continue to generate new rolling values that are unique to the individual devices. A rolling value is a dynamic value which is regenerated every so often (e.g., every 30 seconds) or in response to given events (e.g., whenever the user presses a given input mechanism) . A hardware device of the type mentioned above keeps generating a new rolling value, typically per period of time. Such a rolling value can be used to authenticate a user, and can be thought of as a rolling password associated with the specific generating device. Such rolling values typically comprise pseudo-random numbers of a given number of digits (e.g., six), generated based on a seed value such as the current time or a chain of previous values. An authenticating device is able to generate the same current rolling value as a given generating device at any given time (i.e., the authenticating device also has the seed value or whatever key is used to generate the rolling value) . Thus, the authenticating device can verify that a received rolling value was actually generated by a given device.
[008] Rolling value generating hardware devices are undesirable to users because they comprise yet another device for the user to carry. Additionally, the user must type in the current rolling value as well as the static password, which is even more burdensome than typing in the password alone. These devices are also undesirable to administrators and IT professionals, because they are frequently lost, have limited battery life and must be replaced on a reoccurring basis. There is rolling value generating software (for example, Verisign VIP) , but this still requires the user to manually enter the current rolling value, and also presents a practical limitation to the length of possible rolling values.
[009] It would be desirable to address these issues concerning two factor authentication as well.
[010] U.S. online retail sales are estimated to reach
$248.7 billion by 2014, up more than $60 billion from 2010. Despite the prevalence of online sales, completing an online purchase still requires users to type in their name, email address, credit card information, and shipping details. To make matters worse, most online retailers require users to create accounts on their site, which adds yet another step and more data entry to the process for the user. Furthermore, every time a user enters such information to facilitate an online purchase, the user's credentials are exposed to misappropriation by malware, key loggers and phishing websites.
[011] Some online retailers allow users with accounts to store payment and shipping information, and choose from previously entered options after having logged into the webstore. However, users still need to reenter this information for each separate online merchant, and they need to login to each specific webstore each time they wish to make a purchase. Paypal and Google have alleviated this problem to some extent by allowing users to enter their identifying, payment and shipping information one time, and then choosing Paypal or Google Checkout to complete online transactions with multiple webstores. These services allow a user to choose payment and shipping details from menus, and provide the webstore with notification of payment along with the user's shipping details. Paypal and Google Checkout are a big step forward over having to enter this information individually for each purchase at each webstore, but they still fail to provide a means for checkout that does not require users to login each time they make a purchase. For example, a customer can visit a webstore, add items to his or her cart, choose checkout, and then select the Paypal or Google Checkout option. At this point, the user must login to his or her Paypal or Google Checkout account, requiring manual entry of the username and password each time the user makes a purchase.
[012] It would be desirable to address these issues too . [013] Cash is disappearing from our daily lives as a means of payment. Carrying enough cash for all purchases is tedious, and leaves individuals at risk for theft. It is becoming common to use credit cards for almost all purchases, both online and off. Paying with credit cards solves the above-mentioned problems with cash, but introduces its own set of challenges such as identify verification, stolen credit cards, stolen credit card numbers and cloned cards. Debit cards resolve some of these issues with credit cards, because the customer enters a PIN to verify his or her identity. Thus, a stolen debit card is useless without the PIN. However, thieves are able to create fake ATMs and attach devices to real ATMs that allow the cloning of debit cards and access to the PINs. Various contactless payment systems have been created that attempt to provide electronic payments, such as Visa payWave and Mastercard PayPass. These systems make it extremely difficult for thieves to clone a card, but the other above- discussed problems with credit cards are still present.
[014] It would be desirable to address these issues concerning credit card payments.
[015] On a related note, individuals often exchange money for various reasons. For example, one friend might borrow money from another and then pay it back. An individual might buy an item from a private party after finding it, for example, on Craigslist. One relative may give a cash gift to another. Carrying and exchanging cash for these transactions is problematic for the reasons described above. Paying individuals with credit cards is difficult, as most individuals do not have a merchant account. Paying an individual through PayPal is a good solution where the payee is set up to receive payments this way, but not all individuals are. Furthermore, PayPal precludes making anonymous payments, as the payer must know the email address of the person being paid.
[016] It would be desirable to address these issues concerning payments between individuals as well.
Summary
[017] A graphical identifier authentication system uses a graphical authentication identifier to facilitate the automatic authentication of a user. The graphical identifier authentication system receives a request from an authenticating entity for a onetime use graphical authentication identifier. In some embodiments, the request from the authenticating entity identifies the specific authenticating information being requested by the authenticating entity. In some embodiments, the authenticating entity is a website that requires the user to login or otherwise enter authenticating information. In response to the received request, a onetime use graphical authentication identifier to be displayed by the authenticating entity is generated. A request for user authentication information by the authenticating entity is encoded in the graphical authentication identifier. In some embodiments, this further comprises encoding an identification of the specific authenticating information being requested by the authenticating entity in the graphical authentication identifier. In any case, the generated graphical authentication identifier is transmitted to the authenticating entity for display (e.g., on a login screen) .
[018] The onetime use graphical authentication identifier being displayed by the authenticating entity is captured by a registered user operated computing device
(e.g., a mobile communication device) . In response, the requested user authentication information is transmitted to the authenticating entity, such that the user is automatically authenticated to the authenticating entity, without the user manually entering the requested user authentication information. More specifically, the graphical identifier authentication system receives a request from the user operated computing device to automatically complete authentication of the user to the authenticating entity, responsive to the user operated computing device having captured the onetime use graphical authentication identifier being displayed by the authenticating entity. In some embodiments, the request received from the user operated computing device includes the specific authentication information requested by the authenticating entity. In other embodiments, the request specifies what authentication information is being requested by the authenticating entity, without including the authentication information itself.
[019] In some embodiments, the requested authentication information comprises at least a second factor authentication rolling value that is predictable by the authenticating entity. In these instances, such a second factor authentication rolling value is generated (e.g., by a mobile communication device) , responsive to the user operated computing device capturing the onetime use graphical authentication identifier being displayed by the authenticating entity. The generated rolling value is then transmitted to the authenticating entity.
30 [020] A graphical identifier checkout system uses a graphical checkout identifier to facilitate the automatic checkout of a user on a store. The graphical identifier checkout system receives a request from a webstore for a onetime use graphical checkout identifier. In some embodiments, the request from the webstore identifies the specific checkout completion information being requested by the webstore. In response to the received request, a onetime use graphical checkout identifier to be displayed by the webstore is generated. A request for checkout completion information by the webstore is encoded in the graphical checkout identifier. In some embodiments, this further comprises encoding an identification of the specific checkout completion information being requested by the webstore in the graphical checkout identifier. In any case, the generated graphical checkout identifier is transmitted to the webstore for display (e.g., on a checkout screen) .
[021] The onetime use graphical checkout identifier being displayed by the webstore is captured by a registered user operated computing device (e.g., a mobile communication device) . In response, the requested checkout completion information is transmitted to the webstore, such that the user is automatically checked out on the webstore,
3 1 without the user manually logging in to the webstore or entering the requested checkout completion information.
More specifically, the graphical identifier checkout system receives a request from the user operated computing device to automatically complete the checkout of the user on the webstore, responsive to the user operated computing device having captured the onetime use graphical checkout identifier being displayed by the webstore. In some embodiments, the request received from the user operated computing device includes the specific checkout completion information requested by the webstore. In other embodiments, the request specifies what checkout completion information is being requested by the webstore, without including the checkout completion information itself.
[022] A graphical identifier payment system uses a graphical payment identifier to facilitate the automatic processing of an electronic payment from a user to a receiving party. The graphical identifier payment system receives a request from a payment processing entity for a onetime use graphical payment identifier. In some embodiments, the request from the payment processing entity identifies the specific payment information being requested by the payment processing entity. In some embodiments, the payment processing entity is a point of sale system. In
32 other embodiments, the payment processing entity is a credit card terminal. In response to the received request, a onetime use graphical payment identifier to be displayed by the payment processing entity is generated. A request for payment information by the payment processing entity is encoded in the graphical payment identifier. In some embodiments, this further comprises encoding an identification of the specific payment information being requested by the payment processing entity in the graphical payment identifier. In any case, the generated graphical payment identifier is transmitted to the payment processing entity for display (e.g., on a payment screen).
[023] The onetime use graphical payment identifier being displayed by the payment processing entity is captured by a registered user operated computing device
(e.g., a mobile communication device) . In response, the requested payment information is transmitted to the payment processing entity, such that the electronic payment from the user to the receiving party is executed automatically, without the user manually entering the requested payment information and without the user providing a physical credit card. More specifically, the graphical identifier payment system receives a request from the user operated computing device to automatically process the electronic
33 payment, responsive to the user operated computing device having captured the onetime use graphical payment identifier being displayed by the payment processing entity. In some embodiments, the request received from the user operated computing device includes the specific payment information requested by the payment processing entity. In other embodiments, the request specifies what payment information is being requested by the payment processing entity, without including the payment information itself.
[024] In some embodiments, a graphical payment identifier is used to facilitate the automatic processing of an electronic payment from a paying user operating a first mobile device to a payment receiving user operating a second mobile device. In these embodiments, the graphical identifier payment system receives a request for a onetime use graphical payment identifier from the paying user' s mobile device. In response, a graphical payment identifier encoding an offer to make a payment from the paying user to the payment receiving user is transmitted to and displayed by the paying user's mobile device. The displayed graphical payment identifier is captured by the payment receiving user's mobile device. In response, the payment receiving user' s mobile device transmits a request to the
34 graphical identifier payment system to initiate the processing of the electronic payment. The graphical identifier payment system transmits a request to a payment processing entity to automatically process the electronic payment, such that the electronic payment from the paying user to the payment receiving user is executed automatically, without the paying user providing a physical credit card, and without requiring the payment receiving user to accept a credit card payment. The request to the payment processing entity can include real payment information concerning both the paying user and the payment receiving user. The graphical identifier payment system can receive a confirmation from the payment processing entity that the payment has been processed, and transmit confirmations to both mobile devices for display to the users .
[025] The features and advantages described in this summary and in the following detailed description are not all-inclusive, and particularly, many additional features and advantages will be apparent to one of ordinary skill in the relevant art in view of the drawings, specification, and claims hereof. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and
35 may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter.
Brief Description of the Drawings
[026] Figure 1 is a block diagram of an exemplary network architecture in which a graphical identifier authentication system, a graphical identifier checkout system, or a graphical identifier payment system can be implemented, according to some embodiments.
[027] Figure 2 is a block diagram of a computer system suitable for implementing a graphical identifier authentication system, a graphical identifier checkout system, or a graphical identifier payment system according to some embodiments.
[028] Figure 3 is a block diagram of the operation of a graphical identifier authentication system, according to some embodiments.
[029] Figure 4 is a mock screenshot of a website displaying a graphical authentication identifier, according to some embodiments.
36 [030] Figure 5 is a diagram of a mobile communication device capturing a displayed graphical authentication identifier, according to some embodiments.
[031] Figure 6 is a block diagram of the operation of a graphical identifier checkout system, according to some embodiments .
[032] Figure 7 is a mock screenshot of a webstore displaying a graphical checkout identifier, according to some embodiments.
[033] Figure 8 is a diagram of a mobile communication device capturing a displayed graphical checkout identifier, according to some embodiments.
[034] Figure 9 is a diagram of a mobile communication device displaying a transaction confirmation, according to some embodiments.
[035] Figure 10 is a block diagram of the operation of a graphical identifier payment system, according to some embodiments .
[036] Figure 11 is a diagram of a point of sale system displaying a graphical payment identifier, according to some embodiments.
[037] Figure 12 is a diagram of a mobile communication device capturing a displayed graphical payment identifier, according to some embodiments.
37 [038] Figure 13 is a diagram of a mobile communication device displaying a transaction confirmation, according to some embodiments.
[039] Figure 14 is a block diagram of the operation of a graphical identifier payment system in which a paying mobile communication device makes a payment to a receiving mobile communication device, according to other embodiments .
[040] Figure 15 is a diagram of a payer's mobile communication device displaying an entry screen for making a payment to another user, according to some embodiments.
[041] Figure 16 is a diagram of a payer's mobile communication device displaying a graphical payment identifier, according to some embodiments.
[042] Figure 17 is a diagram of a payee's mobile communication device displaying a transaction confirmation, according to some embodiments.
[043] The Figures depict various embodiments for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles described herein.
38 Detailed Description
[044] Figure 1 is a block diagram illustrating an exemplary network architecture 100 in which a graphical identifier authentication system 101 can be implemented. A graphical identifier checkout system 600 or a graphical identifier payment system 1000 can also be implemented in such a network architecture 100, although this is not explicitly illustrated in Figure 1. The illustrated network architecture 100 comprises multiple mobile communication devices 103A, 103B and 103N, as well as multiple servers 105A and 105N. In Figure 1, the graphical identifier authentication system 101 is illustrated as residing on server 105A, with a device agent 102 thereof on each mobile communication device 103. It is to be understood that this is an example only, and in various embodiments various functionalities of this system 101 (or a graphical identifier checkout system 600 or a graphical identifier payment system 1000) can be instantiated on a mobile communication device 103, a server 105 or can be distributed between multiple computing devices as desired.
[045] It is to be understood that the mobile communication devices 103 described herein comprise portable computer systems 210 capable of connecting to a network 107 and running applications (such mobile communication devices 103 are sometimes referred to as smart-phones, but even many mobile phones not so designated have these capabilities) . Mobile communication devices 103 and servers 105 can be implemented using computer systems 210 such as the one illustrated in Figure 2 and described below. The mobile communication devices 103 and servers 105 are communicatively coupled to a network 107, for example via a network interface 248 as described below in conjunction with Figure 2. Mobile communication devices 103 are able to access applicants and/or data on servers 105 using, for example, a web browser or other client software (not shown) .
[046] Although Figure 1 illustrates three mobile communication devices 103 and two servers 105 as an example, in practice many more (or fewer) mobile communication devices 103 and/or servers 105 can be deployed. In one embodiment, the network 107 is in the form of the internet. Other networks 107 or network-based environments can be used in other embodiments.
[047] Figure 2 is a block diagram of a computer system
210 suitable for implementing a graphical identifier authentication system 101 (as illustrated) or a graphical identifier checkout system 600 or a graphical identifier payment system 1000 (not illustrated in Figure 2) . Both mobile communication devices 103 and servers 105 can be implemented in the form of such computer systems 210. As illustrated, one component of the computer system 210 is a bus 212. The bus 212 communicatively couples other components of the computer system 210, such as at least one processor 214, system memory 217 (e.g., random access memory (RAM) , read-only memory (ROM) , flash memory) , an input/output (I/O) controller 218, an audio output interface 222 communicatively coupled to an external audio device such as a speaker system 220, a display adapter 226 communicatively coupled to an external video output device such as a display screen 224, one or more interfaces such as serial ports 230, Universal Serial Bus (USB) receptacles
230, parallel ports (not illustrated), etc., a keyboard controller 233 communicatively coupled to a keyboard 232, a storage interface 234 communicatively coupled to at least one hard disk 244 (or other form(s) of magnetic media), a floppy disk drive 237 configured to receive a floppy disk
238, a host bus adapter (HBA) interface card 235A configured to connect with a Fibre Channel (FC) network
290, an HBA interface card 235B configured to connect to a
SCSI bus 239, an optical disk drive 240 configured to receive an optical disk 242, a mouse 246 (or other pointing device) coupled to the bus 212 e.g., via a USB receptacle 228, a modem 247 coupled to bus 212, e.g., via a serial port 230, and a network interface 248 coupled, e.g., directly to bus 212.
[048] Other components (not illustrated) may be connected in a similar manner (e.g., document scanners, digital cameras, printers, etc.) . Conversely, all of the components illustrated in Figure 2 need not be present. The components can be interconnected in different ways from that shown in Figure 2.
[049] The bus 212 allows data communication between the processor 214 and system memory 217, which, as noted above may include ROM and/or flash memory as well as RAM. The RAM is typically the main memory into which the operating system and application programs are loaded. The ROM and/or flash memory can contain, among other code, the Basic
Input-Output system (BIOS) which controls certain basic hardware operations. Application programs can be stored on a local computer readable medium (e.g., hard disk 244, optical disk 242) and loaded into system memory 217 and executed by the processor 214. Application programs can also be loaded into system memory 217 from a remote location (i.e., a remotely located computer system 210), for example via the network interface 248 or modem 247. In Figure 2, the graphical identifier authentication system 101 is illustrated as residing in system memory 217. The workings of the graphical identifier authentication system 101 are explained in greater detail below in conjunction with Figures 3-5.
[050] The storage interface 234 is coupled to one or more hard disks 244 (and/or other standard storage media) . The hard disk(s) 244 may be a part of computer system 210, or may be physically separate and accessed through other interface systems.
[051] The network interface 248 and or modem 247 can be directly or indirectly communicatively coupled to a network 107 such as the Internet. Such coupling can be wired or wireless .
[052] Figure 3 illustrates the operation of a device agent 102 residing in the system memory 217 of a mobile communication device 103 and a graphical identifier authentication system 101 residing in the system memory 217 of a server computer 105, according to some embodiments.
As described above, the functionalities of the device agent
102, the graphical identifier authentication system 101, the graphical identifier checkout system 600, or the graphical identifier payment system 1000 can reside on a mobile communication device 103, a server 105, or be distributed between multiple computer systems 210, including within a cloud-based computing environment in which the functionality in question is provided as a service over a network 107. It is to be understood that although the device agent 102 and the graphical identifier authentication system 101 are illustrated in Figure 3 (and the graphical identifier checkout system 600 and the graphical identifier payment system 1000 in Figures 6 and
10) as single entities, these components represent collections of functionalities, which can be instantiated as a single or multiple modules as desired. An instantiation of specific, multiple modules of the device agent 102 and the graphical identifier authentication system 101 are illustrated in Figure 3. An instantiation of specific, multiple modules of the device agent 102 and the graphical identifier checkout system 600 are illustrated in
Figure 6. An instantiation of specific, multiple modules of the device agent 102 and the graphical identifier payment system 1000 are illustrated in Figure 10.
[053] It is to be understood that the modules of the device agent 102, the graphical identifier authentication system 101, the graphical identifier checkout system 600 and the graphical identifier payment system 1000 can be instantiated (for example as object code or executable images) within the system memory 217 (e.g., RAM, ROM, flash memory) of any computer system 210, such that when the processor 214 of the computer system 210 processes a module, the computer system 210 executes the associated functionality. As used herein, the terms "computer system," "computer," "client," "client computer," "server," "server computer" "mobile communication device" and "computing device" mean one or more computers configured and/or programmed to execute the described functionality. Additionally, program code to implement the functionalities of these components can be stored on computer-readable storage media. Any form of tangible computer readable storage medium can be used in this context, such as magnetic or optical storage media. As used herein, the term "computer readable storage medium" does not mean an electrical signal separate from an underlying physical medium.
[054] As illustrated in Figure 3, the graphical identifier authentication system 101 enables an authentication methodology that frees users from having to remember and manually enter a username and password for each site 301 they visit. Instead, a user is authenticated via the use of a special graphical authentication identifier 303 that is displayed on the target site's login screen 305. As explained in greater detail below, the graphical authentication identifier 303 is captured by an image reader 307 (e.g., digital camera, digital barcode reader, etc.) on a user's personal mobile communication device 103 (e.g., smart-phone, tablet computing device, etc.) . Once the graphical authentication identifier 303 is captured, the device agent 102 running on the mobile communication device 103 interprets the graphical authentication identifier 303 as a request from the site 301 for the user to provide authentication credentials (e.g., username and password, rolling value, etc.). The device agent 102 on the mobile communication device 103 then directs the graphical identifier authentication system 101 to complete the authentication process for the user with the site 301 through back channels automatically, as described in more detail below.
[055] In Figure 3 the graphical identifier authentication system 101 is illustrated as residing on a server 105 which is separate from any site 301 to which a user is automatically authenticated via a graphical authentication identifier 303. In other embodiments, some or all of the functionality of the graphical identifier authentication system 101 can be provided directly by a computer 210 hosting an authenticating site 301. However, in embodiments in which the graphical identifier authentication system 101 runs on a separate server 105 as illustrated in Figure 3, it can be used in conjunction with multiple authenticating sites 301. The graphical identifier authentication system 101 brokers trust between mobile communication devices 103 and sites 301 being accessed, in order to complete authentication of users by the sites 301
(including two factor authentication in some embodiments) .
[056] Each user that wishes to use the graphical authentication functionality obtains a mobile communication device 103 running a device agent 102. Such a user authenticates himself or herself to the graphical identifier authentication system 101, and registers his or her mobile communication device 103. The graphical identifier authentication system 101 can use any conventional authentication method to authenticate the user
(username and password, identification check, bank transfer, credit card authentication, etc.). The graphical identifier authentication system 101 also identifies the specific mobile communication device 103 being operated by the authenticated user, for example by reading unique identifying information such as a serial number from the installed device agent 102 or the mobile communication device 103 itself. The graphical identifier authentication system 101 stores an association between that user and the specific mobile communication device 103, so that the graphical identifier authentication system 101 can later recognize the authorized user and registered mobile communication device 103.
[057] A graphical authentication identifier generating module 311 of the graphical identifier authentication system 101 generates onetime use graphical authentication identifiers 303 for use by authenticating sites 301. A graphical authentication identifier comprises an indication of a request for authentication information from a specific site 301. A graphical authentication identifier 303 can be output as a visible image that can be captured and interpreted by a mobile communication device 103 running a device agent 102. In one embodiment, graphical authentication identifiers 303 comprise renderable QR Codes that can be embedded on web pages. In addition to QR Codes, simple barcodes, 2d barcodes (3-DI, ArrayTag, Aztec Code, Codablock, Code 1, Code 16K, Code 49, ColorCode, CP Code, DataGlyphs, Data Matrix, Datastrip, Dot Code A, HCCB
(Microsoft Tag), hueCode, Intacta . Code, MaxiCode, MiniCode,
PDF 417, Snowflake code, SuperCode, Ultracode) and/or other computer identifiable data encoding mechanisms can be used in other embodiments. The amount of information encoded in graphical authentication identifiers 303 can vary between sites 301 and embodiments. A graphical authentication identifier 303 can encode the identification of the site
301 to which it is issued, and an indication of what specific authenticating information the site is requesting.
In other instances, a graphical authentication identifier
303 identifies the site 301, but the graphical identifier authentication system 101 and/or device agents 102 track what authentication information is requested by which site
301. In any case, a graphical authentication identifier encoding module 312 encodes information in a graphical authentication identifier 303 such that it can be interpreted by a device agent 102, as described below.
[058] When a site 301 that supports graphical authentication identifiers 303 wishes to authenticate a user (for example, at load time of a page containing a login screen 305) , the site 301 issues a request to the graphical identifier authentication system 101 for a graphical authentication identifier 303. A receiving module 307 of the graphical identifier authentication system 101 on the server receives the request. In response to the received request, the graphical authentication identifier generating module 311 generates a onetime use graphical authentication identifier 303 for the site 301. In some instances, the request identifies the specific requested authentication information to encode in the graphical authentication identifier 303. In other instances, the graphical identifier authentication system 101 stores this information per site 301, and encodes it in the generated graphical authentication identifier 303. In yet other instances, this information is not encoded in the graphical authentication identifier 303, as noted above. In any case, a transmitting module 317 of the graphical identifier authentication system 101 transmits the generated graphical authentication identifier 303 to the requesting site 301.
[059] The site 301 receives the graphical authentication identifier 303, and processes it so as to display the resulting image on its login screen 305. In some embodiments, the only request for authentication displayed by the site 301 is the graphical authentication identifier 303 itself. In other embodiments the graphical authentication identifier 303 is displayed in addition to a conventional prompt for at least some authentication information. For example, users can be given an option to login by manually entering information or by using the graphical authentication identifier 303. In some embodiments, some authentication information is entered conventionally (e.g., a first authentication factor) and some via the graphical authentication identifier 303 (e.g., a second authentication factor) . Figure 4 illustrates a login screen 305 of a website displaying a graphical authentication identifier 303, as well as a conventional prompt 401 for a username.
[060] When a user views a site's login screen 305 containing a graphical authentication identifier 303, the user can login automatically by using a registered mobile communication device 103. In some embodiments, the device agent 102 prompts the user to identify himself, in order to prevent unauthorized parties from using stolen mobile devices 103. This user identification can comprise entry of a four digit personal identification number (pin) , or another conventional authentication method such as a fingerprint scan, facial geometry recognition or other biometric authentication, depending on the capabilities of the mobile device 103. Once the user is identified at the mobile device level 103, the user points the image reader 307 of the mobile communication device 103 at the graphical authentication identifier 303 being displayed on the site's login screen 305, and activates the image reader 307 (e.g., takes a digital photograph of or scans the graphical authentication identifier 303) . The image reader 307
1 captures the graphical authentication identifier 303, and a graphical identifier interpreting module 313 of the device agent interprets the information encoded therein as a request by the site 301 for authentication information. Figure 5 shows a mobile communication device 103 capturing a graphical authentication identifier 303 according to some embodiments .
[061] The graphical identifier interpreting module 313 interprets the information encoded in the graphical authentication identifier 303, which, as explained above, typically identifies the site 301 that is requesting authentication information and in some cases the specific authentication information being requested. In some embodiments the graphical identifier interpreting module 313 displays a confirmation to the user that it has successfully interpreted the graphical authentication identifier 303. In any case, an automatic authentication initiating module 315 of the device agent 102 initiates the automatic authentication of the user to the site 301, by communicating with the graphical identifier authentication system 101, requesting that the graphical identifier authentication system 101 automatically complete the authentication of the user. [062] The request from the mobile device 103 to automatically complete the authentication of the user is received by the receiving module 309 of the graphical identifier authentication system 101 on the server 105. In order to automatically complete the authentication of the user to the site 301, the transmitting module 317 of the graphical identifier authentication system 101 on the server 105 transmits the requested authentication information to the site 301, responsive to the mobile device 103 associated with the user capturing the graphical authentication identifier 303. In some cases, the automatic authentication initiating module 315 of the device agent
102 provides the requested authentication information to the graphical identifier authentication system 101 on the server 105. In some of these embodiments, the identification of what authentication information the site
301 is requesting is encoded in the graphical authentication identifier 303 which, as described above, is interpreted at a mobile device 103 level. In other such embodiments, the mobile device 103 tracks which site 301 requests what authentication information. In other embodiments, the graphical identifier authentication system
101 on the server 105 stores authentication information for registered users, and need not receive the requested information from the mobile device, but instead only the request to complete the authentication. In any case, the transmitting module 317 automatically completes the authentication, by transmitting the requested authentication information to the site 301. This authentication information can be transmitted to the site 301 proactively in responsive to the mobile device 103 having captured the graphical authentication identifier 303, or in response to a specific request from the site 301 itself. Once the site 301 has received the authentication information, the site 301 uses the authentication information to authenticate the user. Note that by using a graphical authentication identifier 303, the user is spared from having to manually enter the authentication information .
[063] In some embodiments, the authentication in question is one factor authentication, in which case the transmitting module 317 typically transmits authentication information such as a username and password (or other single authentication factor) to the site 301. In other embodiments, the authentication is two factor, in which case the transmitting module 317 can instead or in addition provide the appropriate current rolling value to the site
301, thereby freeing the user from having to manually enter rolling values. This also allows for longer rolling values than conventional two factor authentication, because the rolling values do not need to be typed.
[064] More specifically, in embodiments that support two factor authentication, a rolling value generating module 319 of the device agent 102 has the capability of securely generating rolling values that are predictable by supported authenticating sites 301 (that is, a supported authenticating site 301 has a corresponding seed needed to generate matching rolling values) . In such embodiments, when a current rolling value is part or all of the requested authentication information, the rolling value generating module 319 generates a current rolling value which is transmitted to the graphical identifier authentication system 101 for use in the automatic authentication process.
[065] It is to be understood that although the capturing of the graphical authentication identifier 303 and the initiating of the automatic authentication process is described above as being performed by the mobile device
103, in some embodiments the user can be interacting with the authenticating site 301 from a computer system 210 other than the mobile device 103. For example, the user could be browsing the internet on a desktop computer 210 (not illustrated) , and reach a website requiring login that supports graphical authentication identifier 303 based authentication. The user could then use a registered mobile device 103 to capture the graphical authentication identifier 303 being displayed on the website's login screen 305, and the process described above would automatically log the user operating the desktop computer 210 into the website. In some embodiments, some or all of the functionality described as being performed by the mobile device 102 can be performed by a registered non- mobile computer 210. In some embodiments, the user interacts with the authenticating site 301 from the mobile device 103 after authentication.
[066] Note that in some embodiments, the sites 301 referenced herein are websites that require the user to login. However, in other embodiments the functionality described herein can be used to authenticate a user to any electronic entity that requires the user to enter authentication information, and that graphically prompts the user to do so. For example, software applications or hardware devices that present users with login screens 305 and require authentication information from users could display a graphical authentication identifier 303 on their login screens 305 and the above-described functionality could be used to authenticate users.
[067] The communication between the mobile device 103 and the graphical identifier authentication system 101 on the server 105, as well as between the graphical identifier authentication system 101 on the server 105 and the various authenticating sites 301 is typically encrypted for security. Additionally, because each graphical authentication identifier 303 is only usable one time, the communication cannot be successfully replayed. The communication between a mobile device 103 and the graphical identifier authentication system 101 on the server 105 can be conducted via SMS or other messaging services in instances where the mobile device 103 does not currently have access to the internet.
[068] As illustrated in Figure 6, the graphical identifier checkout system 600 enables an automatic webstore checkout procedure that frees users from having to manually login or enter payment and shipping information each time they make an online purchase from a webstore 601. Instead, a user completes the online checkout process via the use of a special graphical checkout identifier 603 that is displayed on the webstore' s checkout screen 605. As explained in greater detail below, the graphical checkout identifier 603 is captured by an image reader 307 (e.g., digital camera, digital barcode reader, etc.) on a user's personal mobile communication device 103 (e.g., smart- phone, tablet computing device, etc.) . Once the graphical checkout identifier 603 is captured, the device agent 102 running on the mobile communication device 103 interprets the graphical checkout identifier 603 as a request from the webstore 601 for checkout completion information (e.g., payment and shipping information) . The device agent 102 on the mobile communication device 103 then directs the graphical identifier checkout system 600 to complete the checkout process with the webstore 601 for the user through back channels automatically, as described in more detail below. Note that providing payment information (e.g., a credit number and expiration date, a bank account number, etc.) to a webstore 601 is not the same thing as the actual execution of a payment (e.g., transferring funds by a financial institution) . As used herein, the term "webstore 601" refers to an online site from which users can purchase goods or services.
[069] In Figure 6 the graphical identifier checkout system 600 is illustrated as residing on a server 105 which is separate from any webstore 601 with which the user completes transactions via a graphical checkout identifier 603. In other embodiments, some or all of the functionality of the graphical identifier checkout system 600 can be provided directly by a computer 210 hosting a webstore 601. However, in embodiments in which the graphical identifier checkout system 600 runs on a separate server 105 as illustrated in Figure 6, it can be used in conjunction with multiple webstores 601. The graphical identifier checkout system 600 brokers trust between mobile communication devices 103 and webstores 601 being accessed, in order to complete checkout of users on the webstores 601.
[070] Each user that wishes to use the graphical checkout functionality described herein obtains a mobile communication device 103 running a device agent 102. Such a user registers with the graphical identifier checkout system 600. To register the user, the graphical identifier checkout system 600 authenticates the user and identifies the user's mobile communication device 103. The graphical identifier checkout system 600 can use any conventional authentication method to authenticate the user (username and password, identification check, bank transfer, credit card authentication, etc.). To identify the specific mobile communication device 103 being operated by the authenticated user, the graphical identifier checkout system 600 can, for example, read unique identifying information such as a serial number from the installed device agent 102 or the mobile communication device 103 itself. A registered user can provide checkout completion information (e.g., real payment methods such as credit card information, bank account information and/or PayPal, shipping destinations, etc.) to the graphical identifier checkout system 600. The graphical identifier checkout system 600 stores an association between that user, the specific mobile communication device 103, and, where provided, the user' s checkout completion information, so that the graphical identifier checkout system 600 can later recognize the registered user and mobile communication device 103, and process the associated checkout completion information .
[071] A graphical checkout identifier generating module
311 of the graphical identifier checkout system 600 generates onetime use graphical checkout identifiers 603 for use by webstores 601. A graphical checkout identifier comprises an indication of a request for checkout completion information from a specific webstore 601. A graphical checkout identifier 603 can be output as a visible image that can be captured and interpreted by a mobile communication device 103 running a device agent 102. In one embodiment, graphical checkout identifiers 603 comprise renderable QR Codes that can be embedded on web pages. In addition to QR Codes, simple barcodes, 2d barcodes (3-DI, ArrayTag, Aztec Code, Codablock, Code 1, Code 16K, Code 49, ColorCode, CP Code, DataGlyphs, Data Matrix, Datastrip, Dot Code A, HCCB (Microsoft Tag) , hueCode, Intacta . Code, MaxiCode, MiniCode, PDF 417, Snowflake code, SuperCode, Ultracode) and/or other computer identifiable data encoding mechanisms can be used in other embodiments. The amount of information encoded in graphical checkout identifiers 603 can vary between webstores 601 and embodiments. A graphical checkout identifier 603 can encode the identification of the webstore 601 to which it is issued, and an indication of what specific checkout completion information the webstore 601 is requesting. In other instances, a graphical checkout identifier 603 identifies the webstore 601, but the graphical identifier checkout system 600 and/or device agents 102 track what checkout completion information is requested by which webstore 601. In any case, a graphical checkout identifier encoding module 312 encodes information in a graphical checkout identifier 603 such that it can be interpreted by a device agent 102, as described below. [072] When a webstore 601 that supports graphical checkout identifiers 603 wishes to checkout a user (for example, at load time of a page containing a checkout screen 605) , the webstore 601 issues a request to the graphical identifier checkout system 600 for a graphical checkout identifier 603. A receiving module 307 of the graphical identifier checkout system 600 on the server receives the request. In response to the received request, the graphical checkout identifier generating module 311 generates a onetime use graphical checkout identifier 603 for the webstore 601. In some instances, the request identifies the specific requested checkout completion information to encode in the graphical checkout identifier
603. In other instances, the graphical identifier checkout system 600 stores this information per webstore 601, and encodes it in the generated graphical checkout identifier
603. In yet other instances, this information is not encoded in the graphical checkout identifier 603, as noted above. In any case, a transmitting module 317 of the graphical identifier checkout system 600 transmits the generated graphical checkout identifier 603 to the requesting webstore 601. Additionally, in some embodiments the webstore 601 provides confirmation details to the graphical identifier checkout system 600 concerning the user's transaction (e.g., a description, line items in the user's cart, their prices, a total price, etc.). This information can be used to confirm the transaction with the user, as described below.
[073] The webstore 601 receives the graphical checkout identifier 603 from the graphical identifier checkout system 600, and processes it so as to display the resulting image on its checkout screen 605. In some embodiments, the only request for checkout completion by the webstore 601 is the graphical checkout identifier 603 itself. In other embodiments the graphical checkout identifier 603 is displayed in addition to a conventional prompt for at least some checkout completion information. For example, users can be given an option to checkout by manually entering checkout information or by using the graphical checkout identifier 603. Figure 7 illustrates a checkout screen 605 of a webstore 601 displaying a graphical checkout identifier 603.
[074] When a user views a webstore' s checkout screen
605 containing a graphical checkout identifier 603, the user can complete the checkout automatically by using a registered mobile communication device 103. In some embodiments, the device agent 102 prompts the user to identify himself, in order to prevent unauthorized parties from using stolen mobile devices 103. This user identification can comprise entry of a four digit personal identification number (PIN) , or another conventional authentication method such as a fingerprint scan, facial geometry recognition or other biometric authentication, depending on the capabilities of the mobile device 103. Once the user is identified at the mobile device level 103, the user points the image reader 307 of the mobile communication device 103 at the graphical checkout identifier 603 being displayed on the webstore' s checkout screen 605, and activates the image reader 307 (e.g., takes a digital photograph of or scans the graphical checkout identifier 603) . The image reader 307 captures the graphical checkout identifier 603, and a graphical identifier interpreting module 313 of the device agent interprets the information encoded therein as a request by the webstore 601 for checkout completion information. Figure 8 shows a mobile communication device 103 capturing a graphical checkout identifier 603 according to some embodiments .
[075] The graphical identifier interpreting module 313 interprets the information encoded in the graphical checkout identifier 603, which, as explained above, typically identifies the webstore 601 that is requesting checkout completion information and in some cases the specific checkout completion information being requested.
[076] In some embodiments, a transaction confirming module 607 of the device agent 102 displays a transaction confirmation to the user. The transaction confirmation can display as much or as little information as desired (e.g., the name of the webstore 601 and the transaction total, the complete webstore 601 invoice with the individual line items, etc.) . As noted above, this type of confirmation information can be provided from the webstore 601 to the graphical identifier checkout system 600, and in turn from the graphical identifier checkout system 600 to the device agent 102. In some embodiments, the transaction confirming module 607 gives the user an option to confirm or cancel the transaction, and/or the option to select which stored payment method and/or shipping address to use (e.g., from drop down menus) . Figure 9 shows a mobile communication device 103 displaying a transaction confirmation according to some embodiments.
[077] Once the graphical checkout identifier 603 has been interpreted (and after any optional transaction confirmation activity) , an automatic checkout initiating module 315 of the device agent 102 initiates the automatic checkout of the user by the webstore 601, by communicating with the graphical identifier checkout system 600, requesting that the graphical identifier checkout system
600 automatically complete the checkout of the user on the webstore 601. The request from the mobile device 103 to automatically complete the checkout of the user is received by the receiving module 309 of the graphical identifier checkout system 600 on the server 105. In order to automatically complete the checkout of the user on the webstore 601, the transmitting module 317 of the graphical identifier checkout system 600 on the server 105 transmits the requested checkout completion information to the webstore 601, responsive to the mobile device 103 associated with the user capturing the graphical checkout identifier 603. In some cases, the automatic checkout initiating module 315 of the device agent 102 provides the requested checkout completion information to the graphical identifier checkout system 600 on the server 105. In some of these embodiments, the identification of what checkout completion information the webstore 601 is requesting is encoded in the graphical checkout identifier 603 which, as described above, is interpreted at a mobile device 103 level. In other such embodiments, the mobile device 103 tracks which webstore 601 requests what checkout completion information. In other embodiments, the graphical identifier checkout system 600 on the server 105 stores checkout completion information for registered users, and need not receive the requested information from the mobile device, but instead only the request to complete the checkout.
[078] In any case, the transmitting module 317 automatically completes the checkout, by transmitting the requested checkout completion information to the webstore 601. This checkout completion information can be transmitted to the webstore 601 proactively in response to the mobile device 103 having captured the graphical checkout identifier 603, or in response to a specific request from the webstore 601 itself. Once the webstore 601 has received the checkout completion information, the webstore 601 uses the checkout completion information to complete the checkout of the user. Note that by using a graphical checkout identifier 603, the user is spared from having to manually login to the webstore 601 or enter the checkout completion information.
[079] It is to be understood that although the capturing of the graphical checkout identifier 603 and the initiating of the automatic checkout process is described above as being performed by the mobile device 103, in some embodiments the user can be interacting with the webstore 601 from a computer system 210 other than the mobile device 103. For example, the user could be using a desktop computer 210 (not illustrated) to shop on the internet, and reach a checkout screen 605 on a webstore 601 that supports graphical checkout identifiers 603. The user could then use a registered mobile device 103 to capture the graphical checkout identifier 603 being displayed on the webstore' s checkout screen 605, and the process described above would automatically complete the checkout process for the user. In some embodiments, some or all of the functionality described as being performed by the mobile device 102 can be performed by a registered non-mobile computer 210. In some embodiments, the user interacts with the webstore 601 from the mobile device 103 after checkout.
[080] The communication between the mobile device 103 and the graphical identifier checkout system 600 on the server 105, as well as between the graphical identifier checkout system 600 on the server 105 and the various webstores 601 is typically encrypted for security. Additionally, because each graphical checkout identifier 603 is only usable one time, the communication cannot be successfully replayed. The communication between a mobile device 103 and the graphical identifier checkout system 600 on the server 105 can be conducted via SMS or other messaging services in instances where the mobile device 103 does not currently have access to the internet.
[081] As illustrated in Figure 10, the graphical identifier payment system 1000 enables an automatic payment procedure that frees users from having to use cash, carry or swipe a credit card or manually enter payment information each time they make a payment. Instead, a user completes an electronic payment process via the use of a special graphical payment identifier 1003 that is displayed by a payment processing entity (e.g., on a payment screen 1005 or statement) . As explained in greater detail below, the graphical payment identifier 1003 is captured by an image reader 307 (e.g., digital camera, digital barcode reader, etc.) on a user's personal mobile communication device 103 (e.g., smart-phone, tablet computing device, etc.) . Once the graphical payment identifier 1003 is captured, the device agent 102 running on the mobile communication device 103 interprets the graphical payment identifier 1003 as a request from the payment processing entity 1001 for payment information. The device agent 102 on the mobile communication device 103 then directs the graphical identifier payment system 1000 to automatically process the payment through back channels, as described in more detail below. [082] In Figure 10 the graphical identifier payment system 1000 is illustrated as residing on a server 105 which is separate from any payment processing entity 1001 through which payments are made via a graphical payment identifier 1003, and separate from any vendor that receives such payments. In other embodiments, some or all of the functionality of the graphical identifier payment system 1000 can be provided directly by a computer 210 hosting a payment processing entity 1001 and/or a target vendor. However, in embodiments in which the graphical identifier payment system 1000 runs on a separate server 105 as illustrated in Figure 10, it can be used in conjunction with multiple payment processing entities 1001. The graphical identifier payment system 1000 brokers trust between mobile communication devices 103 and payment processing entities 1001, in order to process payments for users .
[083] Each user that wishes to use the graphical payment functionality described herein obtains a mobile communication device 103 running a device agent 102. Such a user registers with the graphical identifier payment system 1000. To register the user, the graphical identifier payment system 1000 authenticates the user and identifies the user's mobile communication device 103. The graphical identifier payment system 1000 can use any conventional authentication method to authenticate the user (username and password, identification check, bank transfer, credit card authentication, etc.)- To identify the specific mobile communication device 103 being operated by the authenticated user, the graphical identifier payment system 1000 can, for example, read unique identifying information such as a serial number from the installed device agent 102 or the mobile communication device 103 itself. A registered user can provide payment information such as real payment methods (e.g., credit card information, bank account information and/or PayPal account information, etc.) to the graphical identifier payment system 1000. The graphical identifier payment system 1000 stores an association between that user, the specific mobile communication device 103, and, where provided, the user's payment information, so that the graphical identifier payment system 1000 can later recognize the registered user and mobile communication device 103, and use the associated payment information to process payments.
[084] A graphical payment identifier generating module
311 of the graphical identifier payment system 1000 generates onetime use graphical payment identifiers 1003 for use by payment processing entities 1001. In this context a graphical payment identifier comprises an indication of a request for payment information from a specific payment processing entity 1001. A graphical payment identifier 1003 can be output as a visible image that can be captured and interpreted by a mobile communication device 103 running a device agent 102. In one embodiment, graphical payment identifiers 1003 comprise renderable QR Codes that can be embedded on web pages. In addition to QR Codes, simple barcodes, 2d barcodes (3-DI,
ArrayTag, Aztec Code, Codablock, Code 1, Code 16K, Code 49,
ColorCode, CP Code, DataGlyphs, Data Matrix, Datastrip, Dot
Code A, HCCB (Microsoft Tag), hueCode, Intacta . Code,
MaxiCode, MiniCode, PDF 417, Snowflake code, SuperCode,
Ultracode) and/or other computer identifiable data encoding mechanisms can be used in other embodiments. The amount of information encoded in graphical payment identifiers 1003 can vary between payment processing entities 1001 and embodiments. A graphical payment identifier 1003 can encode the identification of the payment processing entity 1001 to which it is issued, and an indication of what specific payment information the payment processing entity is requesting. In other instances, a graphical payment identifier 1003 identifies the payment processing entity
1001, but the graphical identifier payment system 1000 and/or device agents 102 track what payment information is requested by which payment processing entity 1001. In any case, a graphical payment identifier encoding module 312 encodes information in a graphical payment identifier 1003 such that it can be interpreted by a device agent 102, as described below.
[085] When a payment processing entity 1001 that supports graphical payment identifiers 1003 wishes to accept a payment from a user (for example, at load time of a page containing a payment screen 1005) , the payment processing entity 1001 issues a request to the graphical identifier payment system 1000 for a graphical payment identifier 1003. A receiving module 307 of the graphical identifier payment system 1000 on the server receives the request. In response to the received request, the graphical payment identifier generating module 311 generates a onetime use graphical payment identifier 1003 for the payment processing entity 1001. In some instances, the request identifies the specific requested payment information to encode in the graphical payment identifier
1003. In other instances, the graphical identifier payment system 1000 stores this information per payment processing entity 1001, and encodes it in the generated graphical payment identifier 1003. In yet other instances, this information is not encoded in the graphical payment identifier 1003, as noted above. In any case, a transmitting module 317 of the graphical identifier payment system 1000 transmits the generated graphical payment identifier 1003 to the requesting payment processing entity 1001. Additionally, in some embodiments the payment processing entity 1001 provides additional statement details to the graphical identifier payment system 1000 concerning the current transaction (e.g., a description, line items, their prices, a total price, etc.) . This information can be used to confirm the transaction with the user, as described below.
[086] The payment processing entity 1001 receives the graphical payment identifier 1003, and processes it so as to display the resulting image, for example on a payment screen 1005. In some embodiments, the only request for payment displayed by the payment processing entity 1001 is the graphical payment identifier 1003 itself. In other embodiments the graphical payment identifier 1003 is displayed in addition to a conventional prompt for at least some payment information. For example, users can be given an option to make a payment by conventionally entering payment information (e.g., by swiping a credit card) or by using the graphical payment identifier 1003. In some embodiments, the payment processing entity 1001 displays the graphical payment identifier 1003 not on a screen but instead on a physical medium such as a printed statement. Figure 11 illustrates a payment screen 1005 of a point of sale device 1101 displaying a graphical payment identifier 1003, along with a conventional mechanism 1103 for swiping credit cards, according to some embodiments.
[087] When a user views a payment processing entity's payment screen 1005 (or other output mechanism) containing a graphical payment identifier 1003, the user can make a payment automatically by using a registered mobile communication device 103. In some embodiments, the device agent 102 prompts the user to identify himself, in order to prevent unauthorized parties from using stolen mobile devices 103. This user identification can comprise entry of a four digit personal identification number (PIN) , or another conventional authentication method such as a fingerprint scan, facial geometry recognition or other biometric authentication, depending on the capabilities of the mobile device 103. Once the user is identified at the mobile device level 103, the user points the image reader
307 of the mobile communication device 103 at the graphical payment identifier 1003 being displayed by the payment processing entity 1001, and activates the image reader 307 (e.g., takes a digital photograph of or scans the graphical payment identifier 1003) . The image reader 307 captures the graphical payment identifier 1003, and a graphical identifier interpreting module 313 of the device agent interprets the information encoded therein as a request by the payment processing entity 1001 for payment information. Figure 12 shows a mobile communication device 103 capturing a graphical payment identifier 1003 according to some embodiments .
[088] The graphical identifier interpreting module 313 interprets the information encoded in the graphical payment identifier 1003, which, as explained above, typically identifies the payment processing entity 1001 that is requesting payment information and in some cases the specific payment information being requested.
[089] In some embodiments, a transaction confirming module 607 of the device agent 102 displays a transaction confirmation to the user. The transaction confirmation can display as much or as little information as desired (e.g., the name of the vendor being paid and the transaction total, the complete statement with the individual line items, etc.) . As noted above, this type of transaction information can be provided from the payment processing entity 1001 to the graphical identifier payment system 1000, and in turn from the graphical identifier payment system 1000 to the device agent 102. In some embodiments, the transaction confirming module 607 gives the user an option to confirm or cancel the transaction, and/or the option to select which stored payment method to use (e.g., from a drop down menu) . Figure 13 shows a mobile communication device 103 displaying a transaction confirmation 1301 according to some embodiments.
[090] Once the graphical payment identifier 1003 has been interpreted (and after any optional transaction confirmation activity) , an automatic payment initiating module 315 of the device agent 102 initiates the automatic payment from the user, by communicating with the graphical identifier payment system 1000, requesting that the graphical identifier payment system 1000 automatically process the payment from the user to the target party
(e.g., vendor) through the payment processing entity 1001.
[091] The request from the mobile device 103 to automatically process the payment for the user is received by the receiving module 309 of the graphical identifier payment system 1000 on the server 105. In order to automatically process the payment, the transmitting module
317 of the graphical identifier payment system 1000 on the server 105 transmits the requested payment information to the payment processing entity 1001, responsive to the mobile device 103 associated with the user capturing the graphical payment identifier 1003. In some cases, the automatic payment initiating module 315 of the device agent
102 provides the requested payment information to the graphical identifier payment system 1000 on the server 105.
In some of these embodiments, the identification of what payment information the payment processing entity 1001 is requesting is encoded in the graphical payment identifier
1003 which, as described above, is interpreted at a mobile device 103 level. In other such embodiments, the mobile device 103 tracks which payment processing entity 1001 requests what payment information. In other embodiments, the graphical identifier payment system 1000 on the server
105 stores payment information for registered users, and need not receive the requested information from the mobile device, but instead only the request to process the payment. In any case, the transmitting module 317 automatically processes the payment for the user, by transmitting the requested payment information to the payment processing entity 1001. This payment information can be transmitted to the payment processing entity 1001 proactively in responsive to the mobile device 103 having captured the graphical payment identifier 1003, or in response to a specific request from the payment processing entity 1001 itself. Once the payment processing entity 1001 has received the payment information, the payment processing entity 1001 uses the payment information to execute the payment from the user to the receiving party.
Note that by using a graphical payment identifier 1003, the user is spared from having to use cash, carry or swipe a credit card, or manually enter the payment information.
[092] It is to be understood that payment processing entities 1001 execute payments to receiving parties electronically (e.g., via credit card, electronic funds transfer, PayPal, etc.). A payment processing entity 1001 can comprise any entity configured to process the execution of a payment from a user to a receiving party electronically, and configured to display information to users on screen and/or by printing a statement. Examples of payment processing entities 1001 are point of sale systems and credit card terminals. Examples of payment receiving parties are vendors, physical retail stores, wholesalers, webstores, etc. Some payment processing entities 1001 can be associated with a single payment receiving party (e.g., a point of sale system at a store) , whereas others can process payments to many different receiving parties (e.g., a credit card terminal) . Note that processing the execution of an actual payment (e.g., transferring funds between financial institutions, actually executing a credit card transaction) is not the same thing as simply receiving payment information (e.g., a credit number and expiration date, a bank account number, etc.), by, e.g., a webstore, for subsequent processing by a third party.
[093] Figure 14 illustrates an embodiment in which an individual can use the graphical identifier payment system 1000 to automatically make an electronic payment to another individual, as opposed to making a payment to a commercial receiving party. In this case, the payer's mobile device 102 displays a graphical payment identifier 1003 that can be captured by the payee's mobile device 102. Once the graphical payment identifier 1003 is captured, the payee's mobile communication device 102 communicates with the graphical identifier payment system 1000 on the server 105, which processes the payment through back channels. The payer and the payee both operate mobile communication devices 103 running device agents 102. Both users register with the graphical identifier payment system 1000, as described above.
[094] When a user wishes to utilize a graphical payment identifier 1003 to make a payment to another individual, the user operates his mobile device 103, and the device agent 102 prompts the user to enter the payment amount, select a true payment method (e.g., from a drop down menu) and optionally enter a transaction description. Figure 15 illustrates a payer's mobile communication device 103 displaying an entry screen 1501 for making a payment to another individual, according to one embodiment.
[095] Once the user has entered this information, the device agent makes a request to the graphical identifier payment system 1000 for a graphical payment identifier 1003, as described above. In response, the graphical payment identifier generating module 311 generates a onetime use graphical payment identifiers 1003 as described above, but in this scenario the graphical payment identifier 1003 is to be used by the payer's mobile communication device 103, and comprises an indication of an offer to make a payment. In some instances, the graphical payment identifier generating functionality is instantiated on the server 105 as illustrated, but in other cases it is instantiated on the payer' s mobile communication device 103, as a module of the device agent 102.
[096] The graphical payment identifier 1003 is output by the payer's mobile communication device 103 as a visible image that can be captured and interpreted by the payee's mobile communication device 103. The amount of information encoded in graphical payment identifiers 1003 in this scenario can vary, but can include data such as the identification of the registered payer and/or payee, the amount of the payment, true payment information for one or both parties, and optionally additional descriptive information concerning the payment. Figure 16 illustrates a payer's mobile communication device 103 displaying a graphical payment identifier 1003, according to one embodiment .
[097] The payee can accept the payment automatically, by pointing the image reader 307 of his mobile communication device 103 at the graphical payment identifier 1003 being displayed by the payee's mobile communication device 103, and activating the image reader
307. The image reader 307 captures the graphical payment identifier 1003, and the graphical identifier interpreting module 313 of the device agent 102 on the payee's mobile device 103 interprets the information encoded therein as an offer by the payer's mobile device 103 to make a payment.
Once the graphical payment identifier 1003 has been interpreted, an automatic payment initiating module 315 of the device agent 102 on the payee's mobile device 103 initiates the automatic payment, by communicating with the graphical identifier payment system 1000, requesting that the graphical identifier payment system 1000 automatically process the payment.
[098] The request from the payee's mobile device 103 to automatically process the payment is received by the receiving module 309 of the graphical identifier payment system 1000 on the server 105. In order to automatically process the payment, the transmitting module 317 of the graphical identifier payment system 1000 on the server 105 transmits real payment information for both parties to an appropriate payment processing entity 1001, responsive to the payee's mobile device 103 associated with the user capturing the graphical payment identifier 1003. The graphical identifier payment system 1000 electronically communicates with the payment processing entity 1001 to execute the payment from the payer to the payee (e.g., by transferring funds between their respective bank accounts, or otherwise utilizing their respective real payment information) . The real payment information for each party can be tracked by the graphical identifier payment system 1000, provided by the appropriate mobile communication devices 103 and/or encoded in the graphical payment identifier 1003.
[099] Once the payment has been processed, the receiving module 307 of the graphical identifier payment system 1000 typically receives a confirmation from the payment processing entity 1001, and in response the transmitting module 317 of the graphical identifier payment system 1000 typically transmits confirmations to both mobile communication devices, which can display confirming information to the users. Figure 17 illustrates the payee's mobile communication device 103 displaying a transaction confirmation 1501, according to one embodiment. Note that by using a graphical payment identifier 1003, one individual can make a payment to another without having to carry or exchange cash, carry or swipe a credit card, accept credit card payment and/or manually enter payment information .
[0100] The communication between mobile devices 103 and the graphical identifier payment system 1000 on the server 105, as well as between the graphical identifier payment system 1000 on the server 105 and the various payment processing entities 1001 is typically encrypted for security. Additionally, because each graphical payment identifier 1003 is only usable one time, the communication cannot be successfully replayed. The communication between a mobile device 103 and the graphical identifier payment system 1000 on the server 105 can be conducted via SMS or other messaging services in instances where the mobile device 103 does not currently have access to the internet.
[0101] As will be understood by those familiar with the art, the invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Likewise, the particular naming and division of the portions, modules, agents, managers, components, functions, procedures, actions, layers, features, attributes, methodologies, data structures and other aspects are not mandatory or significant, and the mechanisms that implement the invention or its features may have different names, divisions and/or formats. The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or limiting to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain relevant principles and their practical applications, to thereby enable others skilled in the art to best utilize various embodiments with or without various modifications as may be suited to the particular use contemplated.

Claims

What is claimed is: 1. A computer implemented method for using a graphical authentication identifier to automatically authenticate a user, the method comprising the steps of:
generating a onetime use graphical authentication
identifier to be displayed by an authenticating entity, by at least one computer;
encoding a request for user authentication information by the authenticating entity in the onetime use graphical authentication identifier, by the at least one
computer; and
responsive to a registered user operated computing device capturing the onetime use graphical authentication identifier being displayed by the authenticating entity, transmitting the requested user authentication information to the authenticating entity, by the at least one computer, such that the user is
automatically authenticated to the authenticating entity, without the user manually entering the
requested user authentication information.
2. The method of claim 1 further comprising: receiving a request for a graphical authentication identifier from the authenticating entity, by the at least one computer; and
transmitting the generated graphical authentication
identifier to the authenticating entity, by the at least one computer.
3. The method of claim 1 wherein encoding the request for user authentication information in the onetime use graphical authentication identifier further comprises:
encoding an identification of specific authenticating
information being requested by the authenticating entity, by the at least one computer.
4. The method of claim 1 further comprising:
receiving, by the at least one computer from the user
operated computing device, a request to automatically complete authentication of the user to the
authenticating entity, responsive to the user operated computing device having captured the onetime use graphical authentication identifier being displayed by the authenticating entity.
5. The method of claim 1 wherein: the requested authentication information comprises at least a second factor authentication rolling value that is predictable by the authenticating entity, the method further comprising:
responsive to the user operated computing device capturing the onetime use graphical authentication identifier being displayed by the authenticating entity, generating a second factor authentication rolling value that is predictable by the authenticating entity.
6. A computer implemented method for using a graphical checkout identifier to automatically checkout a user on a webstore, the method comprising the steps of:
generating a onetime use graphical checkout identifier to be displayed by a webstore, by at least one computer; encoding a request for checkout completion information by the webstore in the onetime use graphical checkout identifier, by the at least one computer; and responsive to a registered user operated computing device capturing the onetime use graphical checkout identifier being displayed by the webstore, transmitting the requested checkout completion
information to the webstore, by the at least one computer, such that the user is automatically checked out on the webstore, without the user manually logging in to the webstore or entering the requested checkout completion information.
7. The method of claim 6 further comprising:
receiving a request for a graphical checkout identifier from the webstore, by the at least one computer; and transmitting the generated graphical checkout identifier to the webstore, by the at least one computer.
8. The method of claim 6 wherein encoding the request for checkout completion information in the onetime use graphical checkout identifier further comprises:
encoding an identification of specific checkout completion information being requested by the webstore, by the at least one computer.
9. The method of claim 6 further comprising:
receiving, by the at least one computer from the user
operated computing device, a request to automatically complete checkout of the user on the webstore, responsive to the user operated computing device having captured the onetime use graphical checkout identifier being displayed by the webstore.
10. The method of claim 1 further comprising:
receiving confirmation information from the webstore
concerning a transaction being conducted by the user, by the at least one computer; and
transmitting the received confirmation information
concerning the transaction being conducted by the user to the user operated computing device, by the at least one computer.
11. A computer implemented method for using a graphical payment identifier to automatically process an electronic payment from a user to a receiving party, the method comprising the steps of:
generating a onetime use graphical payment identifier to be displayed by a payment processing entity, by at least one computer;
encoding a request for payment information by the payment processing entity in the onetime use graphical payment identifier, by the at least one computer; and responsive to a registered user operated computing device capturing the onetime use graphical payment identifier being displayed by the payment processing entity, transmitting the requested payment information to the payment processing entity, by the at least one computer, such that the electronic payment from the user to the receiving party is executed automatically, without the user manually entering the requested payment information and without the user providing a physical credit card.
12. The method of claim 11 further comprising:
receiving a request for a graphical payment identifier from the payment processing entity, by the at least one computer; and
transmitting the generated graphical payment identifier to the payment processing entity, by the at least one computer.
13. The method of claim 11 wherein encoding the request for payment information in the onetime use graphical payment identifier further comprises:
encoding an identification of specific payment information being requested by the payment processing entity, by the at least one computer.
14. The method of claim 11 further comprising:
receiving, by the at least one computer from the user
operated computing device, a request to automatically process the electronic payment, responsive to the user operated computing device having captured the onetime use graphical payment identifier being displayed by the payment processing entity.
15. The method of claim 11 further comprising:
receiving information from the payment processing entity concerning a transaction being conducted by the user, by the at least one computer; and
transmitting the received information concerning the
transaction being conducted by the user to the user operated computing device, by the at least one
computer.
16. A computer implemented method for using a graphical payment identifier to automatically process an electronic payment from a paying user operating a first mobile device to a payment receiving user operating a second mobile device, the method comprising the steps of:
generating, by at least one computer, a onetime use
graphical payment identifier to be displayed by the first mobile device;
encoding an offer to make a payment from the paying user to the payment receiving user in the onetime use graphical payment identifier, by the at least one computer; and responsive to the second mobile device capturing the onetime use graphical payment identifier being
displayed by the first mobile device, transmitting a request to a payment processing entity to
automatically process the electronic payment, such that the electronic payment from the paying user to the payment receiving user is executed automatically, without the paying user providing a physical credit card, and without requiring the payment receiving user to accept a credit card payment.
17. The method of claim 16 further comprising:
receiving a request for a graphical payment identifier from the first mobile device, by the at least one computer; and
transmitting the generated graphical payment identifier to the first mobile device, by the at least one computer.
18. The method of claim 16 further comprising:
receiving, by the at least one computer from the second
mobile device, a request to automatically process the electronic payment, responsive to the second mobile device having captured the onetime use graphical payment identifier being displayed by the first mobile device.
19. The method of claim 16 wherein transmitting a request to a payment processing entity to automatically process the electronic payment further comprises:
transmitting real payment information concerning both the paying user and the payment receiving user to the payment processing entity, by the at least one
computer.
20. The method of claim 16 further comprising:
responsive to receiving, by the at least one computer from the payment processing entity, a confirmation that the payment has been processed, transmitting confirmations that the payment has been processed to both the first mobile device and to the second mobile device.
EP11848042.5A 2010-12-15 2011-12-15 Automatic user authentication, online checkout and electronic payments via mobile communication device with imaging system Withdrawn EP2652631A4 (en)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US12/969,471 US9076171B2 (en) 2010-12-15 2010-12-15 Automatic electronic payments via mobile communication device with imaging system
US12/969,510 US8177125B1 (en) 2010-12-15 2010-12-15 Automatic online checkout via mobile communication device with imaging system
US12/969,303 US8856902B2 (en) 2010-12-15 2010-12-15 User authentication via mobile communication device with imaging system
PCT/US2011/065300 WO2012083091A2 (en) 2010-12-15 2011-12-15 Automatic user authentication, online checkout and electronic payments via mobile communication device with imaging system

Publications (2)

Publication Number Publication Date
EP2652631A2 true EP2652631A2 (en) 2013-10-23
EP2652631A4 EP2652631A4 (en) 2016-10-19

Family

ID=46245377

Family Applications (1)

Application Number Title Priority Date Filing Date
EP11848042.5A Withdrawn EP2652631A4 (en) 2010-12-15 2011-12-15 Automatic user authentication, online checkout and electronic payments via mobile communication device with imaging system

Country Status (5)

Country Link
EP (1) EP2652631A4 (en)
JP (1) JP5921568B2 (en)
CN (1) CN103493034B (en)
CA (1) CA2820958A1 (en)
WO (1) WO2012083091A2 (en)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9508069B2 (en) 2013-03-28 2016-11-29 International Business Machines Corporation Rendering payments with mobile phone assistance
FI20145247L (en) * 2014-03-17 2015-09-18 Lvi Wabek Oy Order system and method for online shopping
CN105653963B (en) * 2014-11-20 2020-06-19 阿里巴巴集团控股有限公司 Information display method and device
US10127544B2 (en) * 2014-12-16 2018-11-13 Facebook, Inc. Sending and receiving payments using a message system
JP7035434B2 (en) * 2017-10-02 2022-03-15 株式会社デンソーウェーブ Payment system
CN111651130A (en) * 2020-05-28 2020-09-11 深圳市商汤科技有限公司 File printing method, device, system, electronic equipment and storage medium

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10205721B2 (en) * 2002-12-10 2019-02-12 Ewi Holdings, Inc. System and method for distributing personal identification numbers over a computer network
CA2552264A1 (en) * 2003-07-02 2005-01-13 Mobipay International, S.A. Digital mobile telephone transaction and payment system
JPWO2006129720A1 (en) * 2005-05-31 2009-01-08 メディアスティック株式会社 Electronic commerce method and license registration check server used therefor
JP4824986B2 (en) * 2005-10-17 2011-11-30 株式会社野村総合研究所 Authentication system, authentication method, and authentication program
JP4826251B2 (en) * 2005-12-20 2011-11-30 コニカミノルタビジネステクノロジーズ株式会社 User authentication method, computer software, and apparatus having user authentication function
JP2007193481A (en) * 2006-01-18 2007-08-02 Ntt Facilities Inc Authentication system and method
JP2008146363A (en) * 2006-12-11 2008-06-26 Nifty Corp Authentication method in computer network
GB2449510A (en) * 2007-05-24 2008-11-26 Asim Bucuk A method and system for the creation, management and authentication of links between people, entities, objects and devices
EP2040228A1 (en) 2007-09-20 2009-03-25 Tds Todos Data System Ab System, method and device for enabling secure and user-friendly interaction
DE602007007085D1 (en) * 2007-09-20 2010-07-22 Tds Todos Data System Ab A system, method and apparatus for facilitating dynamic security interactions
CN101897165B (en) * 2007-10-30 2013-06-12 意大利电信股份公司 Method of authentication of users in data processing systems

Also Published As

Publication number Publication date
WO2012083091A3 (en) 2013-06-13
JP2014508334A (en) 2014-04-03
CN103493034B (en) 2017-03-08
CN103493034A (en) 2014-01-01
WO2012083091A2 (en) 2012-06-21
EP2652631A4 (en) 2016-10-19
JP5921568B2 (en) 2016-05-24
CA2820958A1 (en) 2012-06-21

Similar Documents

Publication Publication Date Title
US9076171B2 (en) Automatic electronic payments via mobile communication device with imaging system
CN107851254B (en) Seamless transactions with minimized user input
US8177125B1 (en) Automatic online checkout via mobile communication device with imaging system
US8856902B2 (en) User authentication via mobile communication device with imaging system
US9898719B2 (en) Systems, methods, and computer program products providing push payments
CN110869961A (en) System and method for securing sensitive credentials using transaction identifiers
US11017371B2 (en) Multi-point authentication for payment transactions
CN109564659B (en) Sharing data with a card issuer via a wallet application in a payment-enabled mobile device
CN112368730A (en) Secure remote transaction framework using dynamic secure checkout elements
JP2011518377A (en) Payment account data ghosting in mobile phone payment transaction system
JP5921568B2 (en) Automatic user authentication, online checkout and electronic payment via mobile communication device with imaging system
US20210241266A1 (en) Enhancing 3d secure user authentication for online transactions
US20230410119A1 (en) System and methods for obtaining real-time cardholder authentication of a payment transaction
US9959538B2 (en) Multi-point authentication for payment transactions
US10055737B2 (en) Multi-point authentication for payment transactions
CN114207578A (en) Mobile application integration
US20230206214A1 (en) BioPurse
US20200184451A1 (en) Systems and methods for account event notification
WO2015126632A1 (en) System and method for internet consumer terminal (ict)
WO2016146071A1 (en) Multi-point authentication for payment transactions
CN117813619A (en) Device identification using identification identifier
WO2019145801A1 (en) A personal electronic card device for conducting financial transactions

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20130711

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAX Request for extension of the european patent (deleted)
A4 Supplementary search report drawn up and despatched

Effective date: 20160915

RIC1 Information provided on ipc code assigned before grant

Ipc: G06Q 20/32 20120101ALI20160909BHEP

Ipc: G06Q 20/12 20120101ALI20160909BHEP

Ipc: G06Q 20/38 20120101ALI20160909BHEP

Ipc: G06F 21/43 20130101ALI20160909BHEP

Ipc: G06Q 20/40 20120101ALI20160909BHEP

Ipc: G06F 21/35 20130101ALI20160909BHEP

Ipc: G06F 21/36 20130101AFI20160909BHEP

17Q First examination report despatched

Effective date: 20170629

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20171110