WO2014160582A1 - System and method for transaction authentication - Google Patents
System and method for transaction authentication Download PDFInfo
- Publication number
- WO2014160582A1 WO2014160582A1 PCT/US2014/031306 US2014031306W WO2014160582A1 WO 2014160582 A1 WO2014160582 A1 WO 2014160582A1 US 2014031306 W US2014031306 W US 2014031306W WO 2014160582 A1 WO2014160582 A1 WO 2014160582A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- government
- user
- payment
- mobile device
- account
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 58
- 230000004044 response Effects 0.000 claims abstract description 10
- 238000010200 validation analysis Methods 0.000 claims description 25
- 230000002596 correlated effect Effects 0.000 claims description 19
- 238000009877 rendering Methods 0.000 claims description 13
- 238000004590 computer program Methods 0.000 description 7
- 230000008569 process Effects 0.000 description 7
- 238000005516 engineering process Methods 0.000 description 6
- 230000007246 mechanism Effects 0.000 description 6
- 238000012546 transfer Methods 0.000 description 6
- LFQSCWFLJHTTHZ-UHFFFAOYSA-N Ethanol Chemical compound CCO LFQSCWFLJHTTHZ-UHFFFAOYSA-N 0.000 description 5
- 239000000599 controlled substance Substances 0.000 description 5
- 230000015654 memory Effects 0.000 description 5
- 238000012545 processing Methods 0.000 description 5
- 230000008901 benefit Effects 0.000 description 4
- 238000004891 communication Methods 0.000 description 4
- 238000012015 optical character recognition Methods 0.000 description 4
- 230000035622 drinking Effects 0.000 description 3
- 230000037308 hair color Effects 0.000 description 3
- 230000036541 health Effects 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 3
- 230000009471 action Effects 0.000 description 2
- 238000013475 authorization Methods 0.000 description 2
- 238000000151 deposition Methods 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 239000004065 semiconductor Substances 0.000 description 2
- 238000012795 verification Methods 0.000 description 2
- 108020004414 DNA Proteins 0.000 description 1
- 102000053602 DNA Human genes 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 239000008280 blood Substances 0.000 description 1
- 210000004369 blood Anatomy 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 230000000875 corresponding effect Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 239000003814 drug Substances 0.000 description 1
- 229940079593 drug Drugs 0.000 description 1
- 230000001815 facial effect Effects 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 239000000047 product Substances 0.000 description 1
- 230000008439 repair process Effects 0.000 description 1
- 230000001953 sensory effect Effects 0.000 description 1
- 238000001228 spectrum Methods 0.000 description 1
- 239000000126 substance Substances 0.000 description 1
- 239000000758 substrate Substances 0.000 description 1
- 239000013589 supplement Substances 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
- 238000011179 visual inspection Methods 0.000 description 1
Classifications
-
- 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
- G06Q20/401—Transaction verification
- G06Q20/4014—Identity check for transactions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/322—Aspects of commerce using mobile devices [M-devices]
- G06Q20/3226—Use of secure elements separate from M-devices
Definitions
- This document generally relates to mobile transactions on mobile devices.
- Mobile computing devices may engage in mobile transactions such as on-line credit/debit card payment. These mobile transactions may be authenticated to combat on-line fraud and identity theft.
- some implementations provide a method that includes: generating an association, at a mobile device, between a government-issued identification document of a user and a mode of payment; receiving, at the mobile device, a presentation of the government- issued identification document of the user to support a request for payment; validating whether the presented government-issued identification document is a valid identification of the user; and in response to validating the presented government-issued identification document, rendering with payment by using the mode of payment.
- Implementations may include one or more of the following features.
- the method may further include registering an account of the user on the mobile device to support the mode of payment; and authenticating that the user owns the account.
- the association may additionally include associating, on the mobile device, the authenticated account with the government-issued identification document.
- the association may further include linking the authenticated account owned by a first user to the government-issued identification documents held by a second user, different from the first user.
- Registering the account further comprises: registering a bank account, an intermediary account, or a credit card account.
- the receiving may include: reading personal identification information (PII) from multiple machine-readable zones (MRZs) on the government-issued identification document.
- PII personal identification information
- MMRZs machine-readable zones
- the receiving may further include: correlating, at the mobile device, personal identification information (PII) read from multiple machine-readable zones (MRZs).
- the validating may include: checking personal identification information (PII) read from multiple machine-readable zones against a system of record.
- the validating may further include: transmitting personal identification information (PII) read from multiple machine-readable zones (MRZs) to a server hosting the system of record; receiving, from the server, validation results of checking personal identification information against the system of record.
- the rendering payment may include drawing funds from the registered account to fulfill the request for payment without additional authentication that the user owns the registered account.
- the rendering payment may include drawing funds from the registered account of a first user to fulfill the request for payment from a second user, different from the first user.
- the rendering payment may also include paying through a debit card without presenting the debit card, paying through an intermediary account without authentication for the intermediary account, or paying through a credit card without presenting the credit card.
- some implementations provide a mobile device that includes at least one processor configured to: generate an association between a government-issued identification document of a user and a mode of payment; receive a presentation of the government-issued identification document of the user to support a request for payment; validate whether the presented government-issued identification document is a valid identification of the user; and in response to validating the presented government-issued identification document, render payment by using the mode of payment.
- Implementations may include one or more of the following features, the at least one processor may be further configured to: register an account of the user on the mobile device to support the mode of payment; and authenticate that the user owns the account.
- the at least one processor may be further configured to: associate the authenticated account with the government-issued identification document.
- the at least one processor may be further configured to associate the authenticated account with the government-issued identification document by linking the authenticated account owned by a first user to the government-issued identification documents held by a second user, different from the first user.
- the at least one processor may be further configured to register the account by registering a bank account, an intermediary account, or a credit card account.
- the at least one processor may be further configured to: read personal identification information (PII) from multiple machine-readable zones (MRZs) on the government-issued identification document.
- the at least one processor is further configured to: correlate personal identification information (PII) read from multiple machine-readable zones (MRZs).
- the at least one processor is further configured to: check personal identification information (PII) read from multiple machine-readable zones against a system of record.
- the at least one processor is further configured to transmit personal identification information (PII) read from multiple machine-readable zones (MRZs) to a server hosting the system of record; and receive, from the server, validation results of checking personal identification information against the system of record.
- the at least one processor may be further configured to render payment by drawing funds from the registered account to fulfill the request for payment without additional authentication that the user owns the registered account.
- the at least one processor may be further configured to render payment by drawing funds from the registered account of a first user to fulfill the request for payment from a second user, different from the first user.
- the at least one processor may be further configured to render payment by paying through a debit card without presenting the debit card, paying through an intermediary account without authentication for the intermediary account, or paying through a credit card without presenting the credit card.
- Implementations of the above techniques include a method, computer program product and a system.
- the computer program product is suitably embodied in a non-transitory machine-readable medium and includes instructions executable by one or more processors. The instructions are configured to cause the one or more processors to perform the above described actions.
- the system includes one or more processors and instructions embedded in a non- transitory machine-readable medium that are executable by the one or more processors.
- the instructions when executed, are configured to cause the one or more processors to perform the above described actions.
- the default position is not to use any external databases, but the system could be configured to perform a database check if needed.
- FIG. 1 illustrates an example of a mobile device that authenticates a user requesting a mobile transaction according to some implementations.
- FIG. 2 is a flow chart showing an example of a method for authenticating a user requesting the mobile transaction according to some implementations.
- FIG. 3 is a flow chart showing an example of a validation method according to some implementations.
- Fig. 4 A is a flow chart showing an example of an authentication method according to some implementations.
- Fig. 4B is a flow chart showing another example of an authentication method according to some implementations.
- Fig. 5A illustrates an example of a mobile device authenticating a request by using a government-issued identification document.
- Figs. 5B-D illustrate various examples in which a mobile device validates a government-issued identification document.
- Fig. 6 illustrates an example of a mobile device configured to associate government-issued identification card with a mode of payment.
- Fig. 7 is a flow chart showing an example of a method of using a government- issued identification document to support an on-line payment in response to a request for payment.
- Fig. 8A is a flow chart showing an example of associating an account of a user with a government-issued identification document on a mobile device.
- Fig. 8B illustrates a government-issued identification document associated with example accounts, as configured on a mobile device.
- Fig. 9A is a flow chart showing an example of extracting correlated personal identification information from a government-issued identification document.
- Fig. 9B illustrates extracting correlated personal identification information by reading from multiple zones on the government-issued identification document.
- Fig. 10 is a flow chart showing an example of using a mode of on-line payment to server a request for payment upon validating correlated personal identification information obtained from the government-issued identification document,
- Mobile devices such as smart phones, tablets, laptops, special purpose readers or even home desktops, are increasingly used for mobile transactions.
- Example mobile transactions may include, for example, payment using a credit/debit card, on-line purchase of merchandise, on-line request for medicare reimbursement, on-line booking of airline ticket or train ticket.
- Companies such as Square and Intuit, have offered payment processing devices that attach to smart phones, such as, for example, an iPhone, a Samsung phone, a HTC phone, etc.
- mobile payments may be processed by these payment processing devices, security concerns surrounding such mobile payments remain. For example, stolen or lost credit/debit cards may be abused rather easily within such context of mobile payment.
- a government-issued identification document may include a driver license, a passport, a permanent resident card, a social security card, a Medicare card, a Medicaid card, etc.
- the use of these government- issued identification documents is becoming increasingly common in our society.
- a valid government-issued identification document may be trusted and relied upon for a variety of applications because the holder of this identification document generally has been authenticated or background-checked by the government during the application process.
- Authenticating a user requesting a mobile transaction by using a validated government-issued identification document may provide a high probability of authenticity with no significant comprise in speed and convenience.
- systems and methods as disclosed herein may be well-suited for use by an average and unsophisticated computer user in authenticating herself/himself during a particular mobile transaction.
- Fig. 1 illustrates an example of a mobile device authenticating a user requesting a mobile transaction according to some implementations.
- Mobile device 101 may include an iPhone, as shown in Fig. 1.
- Mobile device 101 may also include other smart phones, such as, for example, a Samsung smart phone, a HTC smart phone, an Android smart phone, a Windows smart phone, etc.
- mobile device 101 may include a tablet device, for example, an iPad, a Samsung Note device, a Microsoft touch device, etc.
- mobile device 101 may also include a laptop device, or even a desktop computer at home.
- Mobile device 101 may receive a request for a mobile transaction, as discussed below.
- Fig. 1 shows an Intuit payment processing device for illustration purpose only.
- Payment processing device 102 may process swipes of credit/debit card 103 by reading the magnetic stripes on credit/debit card 103. Once the credit/debit card has been swiped or read, the information encoded on the magnetic medium of credit/debit card may become available to mobile device 101. The information may include, for example, credit/debit card number, expiration date, holder's name, holder's birth date, holder's residential address, etc.
- mobile device 101 is poised to finish off the requested mobile transaction of making the credit/debit card payment.
- the haunting concern of a stolen or lost credit may hinder wider adoption.
- a stolen or lost credit/debit card may be easily abused. Examples of spoofing may include reading by unauthorized reader, recording magstripe from an unauthorized source, duplicating the magstripe since it can be easily reproduced Such abuse increases fees due to fraud and theft. Meanwhile, an overly restrictive credit/debit card use policy may lead to improper denials and render the credit/debit card useless.
- the user may present a government-issued identification document to back up the requested mobile transaction.
- a government-issued identification document to back up the requested mobile transaction.
- the user proceeds by showing her government-issued identification document 104 at detector 105.
- government-issued identification document 104 may include a state- issued driver license.
- the identification document 104 is not yet authenticated and the holder of the identification document 104 may not be the rightful owner documented by the identification document 104.
- Detector 105 may be a digital camera mounted on mobile device 101 (or an integral part of the mobile device 101).
- detector 104 may be any sensor device based on existing technology or technology being developed, including, for example, an infrared sensor, a photo scanner, a charge-coupled device (CCD) camera, a complementary metal- oxide-semiconductor (CMOS) active pixel sensor, etc.
- CCD charge-coupled device
- CMOS complementary metal- oxide-semiconductor
- the user may present government-issued identification document 104 for inspection by placing government-issued identification document 104 immediately to detector 105 for a close-up view. From the close-up view obtained from detector 104, mobile device 101 may obtain, for example, a digital watermark embedded in the government-issued identification document 104. Upon detecting the integrity of the embedded watermark, government-issued identification document 104 may be deemed genuine and thus validated.
- the watermark in this case is a like a DNA strand which includes a code linking securely and uniquely the
- mobile device 101 may extract payload data from mobile device 101.
- Payload data may include, for example, name of the holder, birth date of the holder, residential address of the holder, etc. This payload data may provide personally identifiable information of the user requesting the mobile transaction, for example, the payee of the requested credit/debit card payment, as illustrated in Fig. 1. If the payload data is not available from government- issued identification document 104, then some information, such as name of the holder, birth date of the holder, or residential address of the holder, etc. may be obtained by using optical scanner recognition (OCR) techniques based on a scan of the government-issued identification document 104.
- OCR optical scanner recognition
- the name of the holder of government- issued identification document 104 can be compared with the name of the holder of credit/debit card 103. If the names match, mobile device 101 may proceed with the requested mobile transaction of payment using credit/debit card 103.
- the requested mobile transaction may take place using a video camera on mobile device 101.
- the store keeper may visually inspect, through a video link provided by the video camera on mobile device 101, the person requesting the mobile transaction who has presented the validated government-issued identification document 104. If the visual inspection confirms that the person requesting the mobile transaction is the person depicted in his/her government-issued identification document, the store keeper may permit the mobile transaction to proceed. For example, the store keeper may honor the mobile payment as a legitimate purchase payment, mark the merchandize as paid, and allow the person to take possession of the merchandize by arranging shipment or authorizing the release.
- the person requesting mobile transaction may be different from the person has presented the validated government-issued identification card. For example, in some
- a spouse may be the credit/debit card holder while the other spouse may have presented his/her government-issued identification document. As long as the other spouse is an authorized user of the credit/debit card, the mobile transaction may proceed and her/his documents are respectively authenticated. Additionally and if desired, the mobile device 101 may alert the registered owner of the credit/debit card about the mobile transaction. The alert may be sent through email, automatic voicemail, short message service (SMS) message, etc.
- SMS short message service
- the authorization may be implied, for example, based on a pre-existing legal relationship between the person requesting the mobile transaction and the person identified government-issued identification document.
- the pre-existing legal relationship may be indicated on the government-issued identification document.
- Information of the pre-existing legal relationship may be encoded in the media, for example, a magnetic strip, a smart card media, etc., of the government-issued identification document.
- the pre-existing legal relationship may be documented on a database maintained by a government entity.
- the legal relationship may include, for example, a spousal relationship, a guardian-dependent relationship, a trust-beneficiary relationship, etc.
- the authorization may also be express.
- the credit/debit card may encode a list of authorized users. If the user authenticated based on the government-issued identification card is on the list of authorized users, then mobile device 101 may submit the mobile transaction. If the user authenticated based on the government-issued identification card is not on the list of authorized users (or the encoded list has not been updated for a period of time, for example, more than three months), then mobile device 101 may submit the mobile transaction that includes information identifying the authenticated user making the request.
- the credit/debit card company may maintain an up-to-date list of authorized users and may allow the transaction only if the authenticated user is on the up-to-date list of authorized users. Thereafter, mobile device 101 may alert the registered owner of the credit/debit card about the mobile transaction.
- the credit/debit card company may deny the mobile transaction and send an alert to the registered owner regarding the denied mobile transaction.
- the alert may be sent through, for example, an email, an automatic voicemail, or a simple message service (SMS) message, etc.
- SMS simple message service
- FIG. 2 is a flow chart showing an example of a method for authenticating a user requesting the mobile transaction according to some implementations.
- a user request for a mobile transaction may be received (202).
- the mobile transaction may be received at mobile device 101 as illustrated in Fig. 1.
- applicable mobile transactions are not limited to a credit/debit card payment as illustrated in Fig. 1.
- Mobile transactions may also include, for example, a wire transfer of funds, an on-line purchase request, an on-line request for distribution, an on-line request for reimbursement, an on-line request for account access, etc., as will be discussed in association with Fig. 5A.
- mobile device 101 may inspect a government-issued identification document 104 to obtain a digital watermark (204).
- Government-issued identification document 104 may include a state-issued driver license as illustrated in Fig. 1.
- Government-issued identification document 104 may not be limited to a state-issued driver license, as will be discussed in association with Fig. 5A.
- Government-issued identification document may include an embedded digital watermark to identify, for example, the legitimate source of the
- the digital watermark may be, for example, embedded in the background image of a state-issued driver license or in the portrait of the document holder.
- the digital watermark may include digital codes embedded into the media of government-issued identification document.
- the media may include paper, plastic, magnetic media, etc.
- the government-issued identification document may be validated (206).
- the digital watermark may be generally imperceptible to naked eyes.
- the digital watermark may generally appear as noise, for example, added to a background noise.
- the digital watermark can uniquely validate and authenticate the government-issued identification document and carry information about the identity of the holder. Altering a digital watermark may be virtually impossible, and the mere lack of presence of a digital watermark can immediately indicate tampering and likely counterfeiting.
- digital watermarks used in a government-issued identification document may provide strong and effective deterrence to counterfeit.
- Digital watermarking is secure, covert and machine-readable.
- the digital watermark may be analyzed according to an example method as illustrated in Fig. 3. Specifically, steganography may analyze the digital watermark and reveal the information identifying the holder.
- data contents encoded by the digital watermarks may be encrypted so that the encoded data contents may remain secure, as an additional security mechanism.
- the digital watermark may be initially analyzed to extract frequency domain information (302).
- the frequency domain information may include spectrum information manifested by, for example, the digital cosine transform (DCT) coefficients in a particular spatial frequency range. In contrast to spatial domain information, such frequency domain information may be robust to cropping or translation of the original document.
- DCT digital cosine transform
- the frequency domain information may be more tamper-proof and more resilient to artifacts during field use.
- mixed-domain information i.e., information from both spatial domain and frequency domain may provide similar degree of robustness against tampering and artifacts.
- the implementations disclosed herein are not limited to the use of frequency domain information alone or the use of mixed-domain information. Spatial domain information may be used according to the same scheme as disclosed herein.
- the frequency domain information may encode a pattern for validation purposes.
- the pattern may be chosen by the issuing authority and remain secretive to the outside world, and only.
- the frequency domain information may be compared with the known pattern (304). In some implementations, the comparison may be performed locally at mobile device 101. In some implementations, mobile device 101 may send the extracted frequency domain information to a central server for the comparison. Details of the different architectures are provided in association with Fig. 5B.
- the comparison may determine whether there is a substantial match between the extracted frequency domain information and the known pattern (306).
- the extracted frequency domain information does not have to perfectly match the known pattern.
- the frequency domain information may be incomplete due to losses in the scanning process.
- the degree of match may depend on the context of the application. For example, for applications involving mobile transactions with a financial sum of under $500, a lower degree of match authentication level may be sufficient. While for applications involving mobile transactions regarding, for example, any purchase of controlled substances, a higher degree of match may be adopted.
- the matching process may depend on jurisdiction. For example, in some states which adopted a less sophisticated digital watermark, a more primitive match procedure may be performed. Even in states that have adopted a more sophisticated digital watermark, legacy identification cards may still use the old and less sophisticated digital watermarking. These legacy identification cards may still be honored by a more primitive matching procedure.
- ascertaining whether there is a substantial match may further factor in prior dealings between the person requesting the mobile transaction and the holder of the government-issued identification document. For example, if the person requesting the mobile transaction has been paying for the holder of the government-issued identification document frequently in the past, then the degree of match may be lessened to simplify the process.
- a trusted consumer database can be set up if needed.
- mobile device 101 may authenticate the government-issued identification document (310). Conversely, if substantial match has not been found between the extracted frequency domain information and the pattern, mobile device 101 may reject the validity of the government-issued identification document. In some implementations, the mobile device may alert the holder of the government-issued identification document of the rejection. The mobile device could also ask for another valid form of identification and, an alert may be sent through email, automatic voicemail, short message service (SMS) message, etc.
- SMS short message service
- mobile device 101 may read information of the holder encoded in the document.
- the information may include, for example, name, gender, age, birth date, residential address, telephone number, or physical characteristics of the holder, etc.
- Example physical characteristics may include height, weight, hair color, eye color, etc.
- Such information may be encoded in a magnetic stripe or barcode.
- mobile device may simply scan the document and extract such information by, for example, OCR techniques.
- the information of the holder may be used to authenticate that the user requesting the mobile transaction is the person authorized to request the mobile transaction (208).
- the authentication may compare the information of the holder with data associated with the person requesting the mobile transaction.
- the data of the user requesting the mobile transaction may include, for example, the name, age, gender, or residential address of the requester. Such data may be obtained, for example, from the mobile transaction request itself.
- the data may be read from credit/debit card 103 by card reader 102.
- an example authentication method may initiate by comparing the identity of the user requesting the mobile transaction and the identity of the subject issued by the government according to the identification document (402).
- the identity may include at least one of: a name, an age, a birth date, a residential address, or a sequence number.
- the sequence number may include, for example, a social security number, a driver license number, a veteran number, a passport number, an alien registration number, etc.
- Mobile device 101 may ascertain whether there is a match between the identity of the user making the request for the mobile transaction and the identity of the subject issued by the government as documented by the identification document (404). At no time is the personally identifiable information of the user stored or held for future use. In the context of matching one identity to another identity, the match may be exact when comparing two numeric values while the match may be case insensitive when comparing two character strings (such as names) or alpha-numeric strings (such as addresses). The degree of match may also depend on the underlying mobile transaction. If the underlying mobile transaction involves a financial sum of over $500 or a purchase of any controlled substances, the degree of match may be high.
- the degree of match may be lessened.
- mobile device 101 may determine that the user is authorized to request the mobile transaction (406). However, if mobile device 101 fails to identify a match between the identity of the user making the request for the mobile transaction and the identity of the subjected recorded by the government-issued identification document, mobile device 101 may determine that the user is not authorized to request the mobile transaction (408). If it is a legitimate error the user will be prompted to present another valid proof of ID.
- mobile device may still authorize the requested mobile transaction to proceed, if, for example, the user requesting the mobile transaction has been authorized by the holder of the government-issued identification document.
- another example authentication method may initiate by comparing the identity of the subject issued by the government as documented by identification document with a requirement for the mobile transaction (412).
- the identity of the subject issued by the government may be checked for the age, the residential address, etc. to comply with legal requirements for engaging in the requested mobile transaction.
- the legal drinlcing age may be the requirement for the requested mobile transaction of purchasing liquor, alcohol, or wine products.
- the legal drinking age in the jurisdiction where the mobile transaction is placed and the legal drinking age in the jurisdiction where the on-line vendor is located may be different. Both legal requirements may be included.
- the legal age for requesting social security distribution may be another example requirement.
- different jurisdiction may impose varying restrictions on on-line purchase requests and therefore the residential address or residential history may be yet another example requirement.
- Mobile device 101 may ascertain whether the identity of the subject issued by the government satisfies the requirement for the mobile transaction (414). In the case of multiple legal requirements, mobile device 101 may ascertain whether all such legal requirements are satisfied.
- mobile device 101 may determine that the user is authorized to request the mobile transaction (406). However, if the identity of the subject issued by the government as documented by the identification document does not satisfy the requirement for the mobile transaction, mobile device 101 may determine that the user is not authorized to request the mobile transaction (408). As discussed above, in some implementations, depending on the legal relationship between the user making the request for the mobile transaction and the person presenting the government-issued identification document, mobile device may still authorize the requested mobile transaction to proceed, if, for example, the user requesting the mobile transaction is the beneficiary of the holder of the government-issued identification document.
- Fig. 5A illustrates an example of a mobile device authenticating a request by using a government-issued identification document.
- mobile device 101 may expect a credential to back up the request.
- the credential may come in the form of a government-issued identification card 504.
- mobile device 101 may prompt the user of mobile device 101 to present his or her government-issued identification card 504.
- the user of mobile device 101 may present his or her government-issued identification card 504 without being prompted by mobile device 101.
- the request for mobile transaction 502 may include a request for a credit/debit card payment, a request for a wire transfer of funds, an on-line purchase request, an on-line request for distribution, an on-line request for reimbursement, an on-line request for account access, etc.
- a wire transfer may allow the requester to transfer funds in one account to another account, for example, in a different bank in a different locale or country.
- the wire transfer request may also include requests to fund an on-line stock or stock option purchase through a checking account, a savings account, etc.
- An on-line purchase request may include a purchase request for a special item
- the purchase request may be at a point of service when a customer comes in person to collect a controlled item for which the customer needs to be vetted before collecting the controlled items.
- the special item or controlled item may include, for example, alcohol, liquor, wine, small arms, ammunitions, over-the-counter (OTC) drugs that may contain controlled substances etc.
- Controlled substances may include any substances that falls under the Controlled Substances Act. Additionally, the special item may also include certain electronics equipment and accessories that may be used for surveillance or eavesdropping.
- An on-line request for distribution may include a request for a distribution of social security benefits, a retirement plan distribution, a pension plan distribution etc.
- An on-line request for reimbursement may ' include a request for reimbursement of medicare benefits, Medicaid benefits, or a state-sponsored health care plan such as, for example, MediCal in the state of California.
- the on-line request for reimbursement may additionally include a request for private insurance reimbursement for health care expenses, property repair expenses for auto or home, etc.
- An on-line request for account access may include a request to change any information in an on-line account, such as, for example, an on-line EZ-pass account, an on-line individual Department of Motor Vehicle (DMV) account, an on-line bank account, an on-line credit/debit card account, etc.
- the on-line request for account access may also include a request for payment through an intermediary, such as a PayPal account, a BillMeLater account, a GoolgleWallet account, etc.
- Government-issued identification card 504 may include a state-issued driver license, a passport issued by the State Department, a permanent resident card issued by the Unites States Citizenship and Naturalization Service (USCIS), a naturalization certificate issued by the USCIS, a social security card issued by the social security service, a Medicare card issued by the Department of Human and Health Services (DHHS), a Medicaid card issued by the DHHS.
- Government-issued identification document may additionally include a national identification card, as used in countries in Europe, Asia, and Latin America. Government-issued identification document may also include a state-issued Medicare card, such as the Medical card issued by the state of California, etc.
- Figs. 5B-D illustrate various examples in which a mobile device validates a government-issued identification document.
- mobile device 101 may validate the identification card locally on-site, as shown in Fig. 5B.
- the on-site validation may be based on the digital watermark as discussed above.
- mobile device 101 may transmit information encoding the digital watermark to commercial central server 506.
- the information encoding the digital watermark may be transmitted along with a validation request 501 to commercial central server 506.
- Commercial central server 506 may house a database for validating digital watermark.
- the validation may be based a comparison of frequency-domain information or mixed-domain information, as outlined above. Frequency domain information may be more robust than spatial domain information for being more tamper-proof and resilient to errors (for example, due to cropping or zooming). However, the implementations disclosed herein are not limited to frequency-domain information or mixed-domain information and can be applied to spatial-domain information.
- commercial central server 506 finishes the validation, commercial central server 506 may transmit validation request 512 back to mobile device 101. Thereafter, mobile device 101 may act accordingly based on the contents of validation result 512, as discussed above.
- mobile device 101 may transmit information encoding the digital watermark to government central server 508.
- the information encoding the digital watermark may be transmitted along with a validation request 501 to government central server 508.
- Digital watermarking may also work across jurisdictions, from federal to state or from state to state.
- government central server 508 may house a database of raw information for validating digital watermark.
- Government central server 508 may be administered by the issuing agency directly, or through a proxy, including, for example, a third-party independent contractor.
- commercial central server may transmit additional validation request to government central server 508 for final resolution of a valdation request originally sent from mobile device 101.
- the paradigm of authentication can be used without a tie to a database.
- the authentication can also be used in relation to a database if so desired.
- Authentication solutions to address on-line fraud or identity theft may incorporate sophisticated software mechanisms. Such authentication solutions may be cumbersome and less user-friendly, especially an average and unsophisticated user.
- government-issued identification documents are becoming more acceptable in that they are used by people from all walks of life.
- government-issued identification document carries the authentication digital watermark issued by the government and tend to be self-authenticating.
- a government-issued identification document Before a government-issued identification document is issued, an elaborate verification process has been performed by the government to confirm that the applicant is who he or she purports to be and that the information provided by the applicant is accurate and complete, as of the application date. As disclosed herein, these features of a government-issued identification document may be incorporated by a mobile device to authenticate that a user requesting a mobile transaction is authorized to request the mobile transaction.
- the resulting authentication method addresses on-line fraud and identity theft issues with no significant compromise in convenience and ease of use.
- the resulting authentication method may be readily implemented on a variety of mobile devices, such as, for example, a smart phone, a tablet device, a laptop device, or even a home desktop computer.
- Various implementations of systems and techniques described here can be realized in digital electronic circuitry, integrated circuitry, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and/or combinations thereof.
- ASICs application specific integrated circuits
- These various implementations can include implementation in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.
- Fig. 6 illustrates an example of a mobile device 101 configured to associate government-issued identification card with a mode of payment.
- a government-issued identification card 504 may be associated with payment mode 602 on mobile device 101.
- the government-issued identification card may be registered at the mobile device 101 as a credential for accessing payment mode 602 on mobile device 101.
- the government-issued identification card of user 604 may be registered at the mobile device by virtue that user 604 is the registered owner of the mobile device.
- the government-issued identification card of user 604 may also be registered by configuring user 604 as an authorized user for accessing payment mode 602.
- Payment mode 604 may be any mode of on-line payment, including, for example, a credit card payment, a debit card payment, a payment through an intermediary account.
- Example intermediary accounts may include: a pay-pal account, a BillMeLater account, a Google wallet account, etc.
- funds from an account may be drawn to render payment on-line.
- the account may be owned by the same user as identified by the government-issued identification card.
- the account may also be owned by a user different from the subject identified by the government-issued identification card.
- the subject may be an authorized user of the account.
- the authorized user may be, for example, a relative, a employee, an agent, or a friend of the owner of the account.
- Government-issued identification card 504 and payment mode 502 may be linked at the mobile device 101.
- the linking may enable the use of government-issued identification card 504 to support payment under payment mode 602 on mobile device 101.
- Fig. 7 is a flow chart showing an example of a method of using a government- issued identification document to support an on-line payment in response to a request for payment.
- the method may initiate by generating an association between a government-issued identification document with a mode of payment (702).
- the government-issued identification document may be an identification card, a driver's license, a passport, etc.
- a payment mode may be any on-line payment mode.
- the association may be an indirect association through a mobile device 101.
- the association may enable using government-issued identification document as a credential to render payment.
- the association may enable the use of government- issued identification document to support rendering the payment without additional credentials
- the method may proceed by generating receiving a presentation of the government-issued identification document at the mobile device to support a request for payment (704).
- the mobile device may capture an image of the presented government- issued identification document.
- the image may be analyzed to extract frequency domain information encoding a digital watermark.
- the digital watermark may be used as a basis to validate the presented government-issued identification document, as discussed above.
- the method may proceed by rendering payment using the mode of payment associated with the government-issued identification document (706).
- the government-issued identification document may be used as a credential to respond to a payment request on mobile device.
- government-issued identification document may be used to support rendering the payment without additional credentials from the user making the request for payment.
- Example additional credentials may include: presentation of the credit card or debit card such as swiping the credit card or the debit card; providing personal identification number (PIN) associated with the credit card account or the debit card account; providing a security code associated with the credit card or the debit card; providing the password associated with the credit card account, the debit card account, or the intermediary account; answering security questions associated with the credit card account, the debit card account, or the intermediary account, etc.
- the security code associated with the credit card or the debit card may also be known as the card verification value code.
- Fig. 8A is a flow chart showing an example of associating an account of a user with a government-issued identification document on a mobile device.
- An example method may initiate by registering an account of the user (802).
- the account may be an on-line account including, for example, a credit card account, a debit card account, an intermediary account.
- the credit card may be associated with any vendors including, for example, Visa, MasterCard, American Express, Discover, etc.
- the debit card account may be associated with any financial institutions, such as banks, credit unions, etc.
- the intermediary account may be an account to transfer funds from a credit card account or a debit card account to a different credit card account or different debit account.
- Example intermediary accounts may include: a PayPal account.
- Registration may include signing up the account to be used for rending payment on a mobile device.
- the registration may enable using a government-issued identification document as a credential document on the mobile device to render payment from the account.
- the method may then proceed by authenticating the account (804).
- the authenticating may include requesting password or security code for accessing the account online.
- the authenticating may include depositing a small sum of money in the account and requesting the user the confirm the sum of money that has been deposited. Because the small sum may be a random number, confirming the small sum deposited may indicate that the correct account has been accessed.
- the authenticating may include a subsequent withdrawing the small sum of money.
- the authenticating may include withdrawing a small sum of money in the account and requesting the user the confirm the sum of money that has been withdrawn.
- the authenticating may include a subsequent depositing of the withdrawn sum.
- the method may then check the success status of the authentication (806). If the authentication is not successful, the account may be rejected on the mobile device as an account to be associated with the government-issued identification card (808).
- the method may proceed by associating the account with the government-issued identification card on the mobile device to support a mode of on-line payment.
- the association may enable the government-issued identification card to be used as a credential for rendering payment on-line.
- the government-issued identification card of a user may be registered at the mobile device by virtue that the user is the registered owner of the mobile device.
- the government-issued identification card of user 604 may also be registered by configuring user 604 as an authorized user for the on-line account.
- Fig. 8B illustrates a government-issued identification document being associated with example accounts, as configured on a mobile device.
- government-issued identification card 504 may be associated with a bank account 812, an intermediary account 814, and a credit card 816.
- the association may allow government-issued identification card 504 to be used as a credential to satisfy an authentication factor before access to bank account 812, intermediary account 814, and credit card 816 can be granted.
- Bank account 812, intermediary account 814, and credit card 816 may then provide funds meet an on-line payment request that is backed by the government-issued identification document.
- Fig. 9A is a flow chart showing an example of extracting correlated personal identification information from a government-issued identification document.
- personal identification information may be read from multiple machine-readable zones (MRZs) of the government-issued identification document (902).
- MMRZs machine-readable zones
- PII personal identification information
- personal identification information may be any information about an individual maintained by an agency, including (1) any information that can be used to distinguish or trace an individual's identity, such as name, social security number, date and place of birth, mother's maiden name, or biometric records; and (2) any other information that is linked or linkable to an individual, such as medical, educational, financial, and employment informationmay include name, address, date of birth, residential address, occupation, marital status, eye color, hair color, height, weight, blood type, etc.
- Machine readable zones may refer to an area on the identity page of a government-issued identification document.
- the MRZ may be at the bottom of the identity page and may span two lines and each line may be 44 characters long.
- Example information provided in the MRZ of a passport may include name, document number, nationality, date of birth, sex, document expiration date and personal identity number.
- Multiple MRZs may be present on the government-issued identification document. Each MRZ may encode complimentary or redundant information using various underlying materials or technologies.
- technologies may including embedding digital watermark in frequency domain information on the printed media, laser irradiation on the substrate material to encode information, etc.
- the personal identification information (PII) obtained from readings from multiple MRZs may be correlated (904).
- the correlation may be performed by comparing the PII from each MRZ.
- the correlation may depend on the quality of the readout, which in turn may hinge on the wear-and-tear of the government-issued identification document.
- the correlation may also depend on the level of embedding of the PII in each MRZ by the jurisdictional authority issuing the identification document. Some jurisdictions may implement more sophisticated identification document with improved complimentary readout from the MRZs. Within the same jurisdiction, however, more recently issued identification document may have more sophisticated MRZ implementations. Correlation result may be the correlated PII (906).
- Fig. 9B illustrates reading from multiple readable zones (MRZs) of the government-issued identification document.
- the identification document 104 may include a MRZ with a printed bar code, a QR code, or other symbology code.
- the MRZ may also include printed microtext, digital watermark embedded as frequency domain information associated with Moire's patterns, etc.
- the MRZ may be scanned optically (908) by infrared-laser (e.g., at 1060 nm wavelength), by visible light, etc.
- the identification document 104 may also include a MRZ corresponding to a magnetic stripe.
- PII in this MRZ may be encoded on the magnetic stripe.
- the encoded PII may be readable by a swiping the identification document on a magnetic reader (910).
- the encoded PII may not be visible and may stay hidden from plain view. In other words, this encoded PII may be covert.
- the identification document 104 may additionally include a MRZ with a portrait of the holder to whom the identification document has been issued by government authority.
- the MRZ may also include printed text indicating license number, date of birth, expiration date of the identification document, full name of the holder, residential address of the holder, gender, height, weight, hair color, eye color, race, etc.
- PII in this MRZ may be read by facial recognition technology in combination with optical character recognition (OCR) technology (912).
- the information read from multiple MRZs may be compared against each other.
- the name on the identification document may be compared against the PII encoded on the magnetic stripe or in the digital watermark. The comparison may indicate whether the identification document has been tampered after issuance. Additionally, the information read from multiple MRZs may also supplement each other to build a more comprehensive listing of correlated information.
- Fig. 10 is a flow chart showing an example of using a mode of on-line payment to server a request for payment upon validating correlated personal identification information obtained from the government-issued identification document.
- the correlated PII 906 may be validated against an authoritative system of record (1002). As described above, the validation may be performed locally by comparing the correlated PII 906 with a local copy of the authoritative system of record (SoR). The validation may also be performed by transmitting the correlated PII 906 to a remote server hosting a central copy of the authoritative SoR. The comparison may be performed on the remote server and the comparison results may be relayed back to the mobile device.
- SoR authoritative system of record
- the remote server may be located at and administered by a government agency, such as, for example, the DMV, the USCIS, the TSA, etc.
- the remote server may be managed by a commercial entity, such as a subcontracting entity of the government agency.
- the subcontracting entity may be entrusted by the government agency.
- the payload of the correlated PII may be as low as a few bits.
- the status of the validation may be determined (1004). If the validation is not successful, the request for payment 1010 may be rejected (1006). If the validation is successful, payment may be rendered using the mode of on-line payment associated with the government- issued identification document (1008).
- Validation result 512 may depend on request for payment 1010. For example, if the request involves payment under $100, then the validation may be cursory and may not be as thorough as a request for payment of $1000. For example, if the request is for purchasing alcohol at the point of sale, the validation may focus on the holder's age and driving history. This validation may also depend on when the request is submitted. For example, in the case of purchasing alcohol at the point of sale, if the request is submitted after 9pm, the validation may be conducted more strictly than during day time. For example, in jurisdictions that outlaw drinking or sale of alcohol after 9pm, the request may be denied. In some implementations, the validation may additionally factor in the authorized user's behavior history.
- the request may be blocked.
- the areas where the authorized user is believed to be present may be configured in accordance with the travel schedule of the authorized user.
- the areas outside the areas of presence may be the areas of absence.
- the transaction may be rolled back if identity theft has been confirmed to have tainted the transaction.
- the ID theft may be confirmed by the bank, credit card company, intermediary account hosting company.
- rendering payment may be made by presenting the government-issued identification document as the authenticating credential. Payment may be rendered without presentations of further credentials associated with the payment mode.
- Computer programs include machine instructions for a programmable processor, and can be implemented in a high-level procedural and/or object-oriented programming language, and/or in assembly/machine language.
- machine-readable medium “computer-readable medium” refers to any computer program product, apparatus and/or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal.
- machine-readable signal refers to any signal used to provide machine instructions and/or data to a programmable processor.
- Suitable processors for the execution of a program of instructions include, by way of example, both general and special purpose microprocessors, and the sole processor or one of multiple processors of any kind of computer.
- a processor will receive instructions and data from a read-only memory or a random access memory or both.
- the elements of a computer may include a processor for executing instructions and one or more memories for storing instructions and data.
- a computer will also include, or be operatively coupled to communicate with, one or more mass storage devices for storing data files; such devices include magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and optical disks.
- Storage devices suitable for tangibly embodying computer program instructions and data include all forms of non- olatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.
- semiconductor memory devices such as EPROM, EEPROM, and flash memory devices
- magnetic disks such as internal hard disks and removable disks
- magneto-optical disks and CD-ROM and DVD-ROM disks.
- the processor and the memory can be supplemented by, or incorporated in, ASICs (application-specific integrated circuits).
- ASICs application-specific integrated circuits
- the systems and techniques described here can be implemented on a computer having a display device (e.g., a CRT (cathode ray tube), LCD (liquid crystal display) monitor, LED (light-emitting diode) or OLED (organic light-emitting diode) monitors) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the computer.
- a display device e.g., a CRT (cathode ray tube), LCD (liquid crystal display) monitor, LED (light-emitting diode) or OLED (organic light-emitting diode) monitors
- a keyboard and a pointing device e.g., a mouse or a trackball
- feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form, including acoustic, speech, or tactile input.
- feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form, including acoustic, speech, or tactile input.
- the systems and techniques described here can be implemented in a computing system that includes a back end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front end component (e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back end, middleware, or front end components.
- the components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network ("LAN”), a wide area network (“WAN”), and the Internet.
- LAN local area network
- WAN wide area network
- the Internet the global information network
- the computing system can include clients and servers.
- a client and server are generally remote from each other and typically interact through a communication network.
- the relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Finance (AREA)
- Computer Networks & Wireless Communication (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
Some implementations provide a method that includes: generating an association, at a mobile device, between a government-issued identification document of a user and a mode of payment; receiving, at the mobile device, a presentation of the government-issued identification document of the user to support a request for payment; validating whether the presented government-issued identification document is a valid identification of the user; and in response to validating the presented government-issued identification document, proceeding with payment by using the mode of payment.
Description
System and Method for Transaction Authentication
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims priority to U.S. Provisional Application No. 61/806,156, filed March 28, 2013, the contents of which are incorporated herein by reference.
TECHNICAL FIELD
[0002] This document generally relates to mobile transactions on mobile devices.
BACKGROUND
[0003] Mobile computing devices may engage in mobile transactions such as on-line credit/debit card payment. These mobile transactions may be authenticated to combat on-line fraud and identity theft.
SUMMARY
[0004] In one aspect, some implementations provide a method that includes: generating an association, at a mobile device, between a government-issued identification document of a user and a mode of payment; receiving, at the mobile device, a presentation of the government- issued identification document of the user to support a request for payment; validating whether the presented government-issued identification document is a valid identification of the user; and in response to validating the presented government-issued identification document, rendering with payment by using the mode of payment.
[0005] Implementations may include one or more of the following features. The method may further include registering an account of the user on the mobile device to support the mode of payment; and authenticating that the user owns the account. The association may additionally include associating, on the mobile device, the authenticated account with the government-issued identification document. The association may further include linking the authenticated account owned by a first user to the government-issued identification documents held by a second user, different from the first user. Registering the account further comprises: registering a bank account, an intermediary account, or a credit card account.
[0006] The receiving may include: reading personal identification information (PII) from multiple machine-readable zones (MRZs) on the government-issued identification document. The receiving may further include: correlating, at the mobile device, personal identification information (PII) read from multiple machine-readable zones (MRZs). The validating may include: checking personal identification information (PII) read from multiple machine-readable zones against a system of record. The validating may further include: transmitting personal identification information (PII) read from multiple machine-readable zones (MRZs) to a server hosting the system of record; receiving, from the server, validation results of checking personal identification information against the system of record.
[0007] The rendering payment may include drawing funds from the registered account to fulfill the request for payment without additional authentication that the user owns the registered account. The rendering payment may include drawing funds from the registered account of a first user to fulfill the request for payment from a second user, different from the first user. The rendering payment may also include paying through a debit card without presenting the debit card, paying through an intermediary account without authentication for the intermediary account, or paying through a credit card without presenting the credit card.
[0008] In another aspect, some implementations provide a mobile device that includes at least one processor configured to: generate an association between a government-issued identification document of a user and a mode of payment; receive a presentation of the government-issued identification document of the user to support a request for payment; validate whether the presented government-issued identification document is a valid identification of the user; and in response to validating the presented government-issued identification document, render payment by using the mode of payment.
[0009] Implementations may include one or more of the following features, the at least one processor may be further configured to: register an account of the user on the mobile device to support the mode of payment; and authenticate that the user owns the account. The at least one processor may be further configured to: associate the authenticated account with the government-issued identification document. The at least one processor may be further configured to associate the authenticated account with the government-issued identification document by linking the authenticated account owned by a first user to the government-issued identification documents held by a second user, different from the first user. The at least one
processor may be further configured to register the account by registering a bank account, an intermediary account, or a credit card account.
[0010] The at least one processor may be further configured to: read personal identification information (PII) from multiple machine-readable zones (MRZs) on the government-issued identification document. The at least one processor is further configured to: correlate personal identification information (PII) read from multiple machine-readable zones (MRZs). The at least one processor is further configured to: check personal identification information (PII) read from multiple machine-readable zones against a system of record. The at least one processor is further configured to transmit personal identification information (PII) read from multiple machine-readable zones (MRZs) to a server hosting the system of record; and receive, from the server, validation results of checking personal identification information against the system of record.
[0011] The at least one processor may be further configured to render payment by drawing funds from the registered account to fulfill the request for payment without additional authentication that the user owns the registered account. The at least one processor may be further configured to render payment by drawing funds from the registered account of a first user to fulfill the request for payment from a second user, different from the first user. The at least one processor may be further configured to render payment by paying through a debit card without presenting the debit card, paying through an intermediary account without authentication for the intermediary account, or paying through a credit card without presenting the credit card.
[0012] Implementations of the above techniques include a method, computer program product and a system. The computer program product is suitably embodied in a non-transitory machine-readable medium and includes instructions executable by one or more processors. The instructions are configured to cause the one or more processors to perform the above described actions.
[0013] The system includes one or more processors and instructions embedded in a non- transitory machine-readable medium that are executable by the one or more processors. The instructions, when executed, are configured to cause the one or more processors to perform the above described actions. The default position is not to use any external databases, but the system could be configured to perform a database check if needed.
[0014] The details of one or more aspects of the subject matter described in this specification are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages of the subject matter will become apparent from the description, the drawings, and the claims.
DESCRIPTION OF DRAWINGS
[0015] Fig. 1 illustrates an example of a mobile device that authenticates a user requesting a mobile transaction according to some implementations.
[0016] Fig. 2 is a flow chart showing an example of a method for authenticating a user requesting the mobile transaction according to some implementations.
[0017] Fig. 3 is a flow chart showing an example of a validation method according to some implementations.
[0018] Fig. 4 A is a flow chart showing an example of an authentication method according to some implementations.
[0019] Fig. 4B is a flow chart showing another example of an authentication method according to some implementations.
[0020] Fig. 5A illustrates an example of a mobile device authenticating a request by using a government-issued identification document.
[0021] Figs. 5B-D illustrate various examples in which a mobile device validates a government-issued identification document.
[0022] Fig. 6 illustrates an example of a mobile device configured to associate government-issued identification card with a mode of payment.
[0023] Fig. 7 is a flow chart showing an example of a method of using a government- issued identification document to support an on-line payment in response to a request for payment.
[0024] Fig. 8A is a flow chart showing an example of associating an account of a user with a government-issued identification document on a mobile device.
[0025] Fig. 8B illustrates a government-issued identification document associated with example accounts, as configured on a mobile device.
[0026] Fig. 9A is a flow chart showing an example of extracting correlated personal identification information from a government-issued identification document.
[0027] Fig. 9B illustrates extracting correlated personal identification information by reading from multiple zones on the government-issued identification document.
[0028] Fig. 10 is a flow chart showing an example of using a mode of on-line payment to server a request for payment upon validating correlated personal identification information obtained from the government-issued identification document,
[0029] Like reference symbols in the various drawings indicate like elements.
DETAILED DESCRIPTION
[0030] Mobile devices, such as smart phones, tablets, laptops, special purpose readers or even home desktops, are increasingly used for mobile transactions. Example mobile transactions may include, for example, payment using a credit/debit card, on-line purchase of merchandise, on-line request for medicare reimbursement, on-line booking of airline ticket or train ticket. Companies, such as Square and Intuit, have offered payment processing devices that attach to smart phones, such as, for example, an iPhone, a Samsung phone, a HTC phone, etc. Although mobile payments may be processed by these payment processing devices, security concerns surrounding such mobile payments remain. For example, stolen or lost credit/debit cards may be abused rather easily within such context of mobile payment.
[0031] Existing mechanisms to authenticate the mobile payments are unable to tie the identity of a person to the mode of payment. To address this problem current solutions employ massive registries of good and fraudulent data. The other problem associated with existing mechanisms is that "local" authentication mechanisms based on barcode and magstripe are known to be highly vulnerable. As these existing mechanisms to authenticate the mobile payments tend to render such mobile payments more cumbersome and less convenient, especially for unsophisticated average users. In contrast, system and methods, such as those disclosed in this application, can authenticate mobile payments based on a physical copy of a government-issued identification document. A government-issued identification document, as discussed in this application, may include a driver license, a passport, a permanent resident card, a social security card, a Medicare card, a Medicaid card, etc. The use of these government- issued identification documents is becoming increasingly common in our society. A valid
government-issued identification document may be trusted and relied upon for a variety of applications because the holder of this identification document generally has been authenticated or background-checked by the government during the application process. Authenticating a user requesting a mobile transaction by using a validated government-issued identification document may provide a high probability of authenticity with no significant comprise in speed and convenience. As a result, systems and methods as disclosed herein may be well-suited for use by an average and unsophisticated computer user in authenticating herself/himself during a particular mobile transaction.
[0032] Fig. 1 illustrates an example of a mobile device authenticating a user requesting a mobile transaction according to some implementations. Mobile device 101 may include an iPhone, as shown in Fig. 1. Mobile device 101 may also include other smart phones, such as, for example, a Samsung smart phone, a HTC smart phone, an Android smart phone, a Windows smart phone, etc. In addition, mobile device 101 may include a tablet device, for example, an iPad, a Samsung Note device, a Microsoft touch device, etc. Further, mobile device 101 may also include a laptop device, or even a desktop computer at home. Mobile device 101 may receive a request for a mobile transaction, as discussed below.
[0033] As illustrated in Fig. 1, the user on mobile device 101 intends to engage in a mobile transaction of making a credit/debit card payment. To this end, payment processing device 102 is mounted on mobile device 101. Fig. 1 shows an Intuit payment processing device for illustration purpose only. Payment processing device 102 may process swipes of credit/debit card 103 by reading the magnetic stripes on credit/debit card 103. Once the credit/debit card has been swiped or read, the information encoded on the magnetic medium of credit/debit card may become available to mobile device 101. The information may include, for example, credit/debit card number, expiration date, holder's name, holder's birth date, holder's residential address, etc. Armed with such information, mobile device 101 is poised to finish off the requested mobile transaction of making the credit/debit card payment. However, the haunting concern of a stolen or lost credit may hinder wider adoption. Without further authentication that the purported user requesting the mobile transaction is the holder of the credit/debit card, a stolen or lost credit/debit card may be easily abused. Examples of spoofing may include reading by unauthorized reader, recording magstripe from an unauthorized source, duplicating the magstripe since it can be easily
reproduced Such abuse increases fees due to fraud and theft. Meanwhile, an overly restrictive credit/debit card use policy may lead to improper denials and render the credit/debit card useless.
[0034] According to some implementations, the user may present a government-issued identification document to back up the requested mobile transaction. For example, in Fig. 1, the user proceeds by showing her government-issued identification document 104 at detector 105. As illustrated in Fig. 1, government-issued identification document 104 may include a state- issued driver license. Yet, the identification document 104 is not yet authenticated and the holder of the identification document 104 may not be the rightful owner documented by the identification document 104.
[0035] Detector 105 may be a digital camera mounted on mobile device 101 (or an integral part of the mobile device 101). In particular, detector 104 may be any sensor device based on existing technology or technology being developed, including, for example, an infrared sensor, a photo scanner, a charge-coupled device (CCD) camera, a complementary metal- oxide-semiconductor (CMOS) active pixel sensor, etc.
[0036] The user may present government-issued identification document 104 for inspection by placing government-issued identification document 104 immediately to detector 105 for a close-up view. From the close-up view obtained from detector 104, mobile device 101 may obtain, for example, a digital watermark embedded in the government-issued identification document 104. Upon detecting the integrity of the embedded watermark, government-issued identification document 104 may be deemed genuine and thus validated. The watermark in this case is a like a DNA strand which includes a code linking securely and uniquely the
identification document, the issuing agency, and the user.
[0037] In addition, mobile device 101 may extract payload data from mobile device 101.
Payload data may include, for example, name of the holder, birth date of the holder, residential address of the holder, etc. This payload data may provide personally identifiable information of the user requesting the mobile transaction, for example, the payee of the requested credit/debit card payment, as illustrated in Fig. 1. If the payload data is not available from government- issued identification document 104, then some information, such as name of the holder, birth date of the holder, or residential address of the holder, etc. may be obtained by using optical scanner recognition (OCR) techniques based on a scan of the government-issued identification document 104.
[0038] In some implementations, for example, the name of the holder of government- issued identification document 104 can be compared with the name of the holder of credit/debit card 103. If the names match, mobile device 101 may proceed with the requested mobile transaction of payment using credit/debit card 103.
[0039] The requested mobile transaction may take place using a video camera on mobile device 101. For example, in some implementations, once government-issued identification document 104 has been validated, the store keeper may visually inspect, through a video link provided by the video camera on mobile device 101, the person requesting the mobile transaction who has presented the validated government-issued identification document 104. If the visual inspection confirms that the person requesting the mobile transaction is the person depicted in his/her government-issued identification document, the store keeper may permit the mobile transaction to proceed. For example, the store keeper may honor the mobile payment as a legitimate purchase payment, mark the merchandize as paid, and allow the person to take possession of the merchandize by arranging shipment or authorizing the release.
[0040] The person requesting mobile transaction may be different from the person has presented the validated government-issued identification card. For example, in some
implementations, a spouse may be the credit/debit card holder while the other spouse may have presented his/her government-issued identification document. As long as the other spouse is an authorized user of the credit/debit card, the mobile transaction may proceed and her/his documents are respectively authenticated. Additionally and if desired, the mobile device 101 may alert the registered owner of the credit/debit card about the mobile transaction. The alert may be sent through email, automatic voicemail, short message service (SMS) message, etc.
[0041] The authorization may be implied, for example, based on a pre-existing legal relationship between the person requesting the mobile transaction and the person identified government-issued identification document. The pre-existing legal relationship may be indicated on the government-issued identification document. Information of the pre-existing legal relationship may be encoded in the media, for example, a magnetic strip, a smart card media, etc., of the government-issued identification document. In addition, the pre-existing legal relationship may be documented on a database maintained by a government entity. The legal relationship may include, for example, a spousal relationship, a guardian-dependent relationship, a trust-beneficiary relationship, etc.
[0042] The authorization may also be express. For example, the credit/debit card may encode a list of authorized users. If the user authenticated based on the government-issued identification card is on the list of authorized users, then mobile device 101 may submit the mobile transaction. If the user authenticated based on the government-issued identification card is not on the list of authorized users (or the encoded list has not been updated for a period of time, for example, more than three months), then mobile device 101 may submit the mobile transaction that includes information identifying the authenticated user making the request. The credit/debit card company may maintain an up-to-date list of authorized users and may allow the transaction only if the authenticated user is on the up-to-date list of authorized users. Thereafter, mobile device 101 may alert the registered owner of the credit/debit card about the mobile transaction. However, if the authenticated user is not on the up-to-date list of authorized users, the credit/debit card company may deny the mobile transaction and send an alert to the registered owner regarding the denied mobile transaction. The alert may be sent through, for example, an email, an automatic voicemail, or a simple message service (SMS) message, etc.
[0043] Figure 2 is a flow chart showing an example of a method for authenticating a user requesting the mobile transaction according to some implementations. First, a user request for a mobile transaction may be received (202). The mobile transaction may be received at mobile device 101 as illustrated in Fig. 1. However, applicable mobile transactions are not limited to a credit/debit card payment as illustrated in Fig. 1. Mobile transactions may also include, for example, a wire transfer of funds, an on-line purchase request, an on-line request for distribution, an on-line request for reimbursement, an on-line request for account access, etc., as will be discussed in association with Fig. 5A.
[0044] Second, mobile device 101 may inspect a government-issued identification document 104 to obtain a digital watermark (204). Government-issued identification document 104 may include a state-issued driver license as illustrated in Fig. 1. Government-issued identification document 104 may not be limited to a state-issued driver license, as will be discussed in association with Fig. 5A. Government-issued identification document may include an embedded digital watermark to identify, for example, the legitimate source of the
identification document. The digital watermark may be, for example, embedded in the background image of a state-issued driver license or in the portrait of the document holder. The
digital watermark may include digital codes embedded into the media of government-issued identification document. The media may include paper, plastic, magnetic media, etc.
[0045] Third, based on the digital watermark, the government-issued identification document may be validated (206). The digital watermark may be generally imperceptible to naked eyes. In fact, the digital watermark may generally appear as noise, for example, added to a background noise. However, the digital watermark can uniquely validate and authenticate the government-issued identification document and carry information about the identity of the holder. Altering a digital watermark may be virtually impossible, and the mere lack of presence of a digital watermark can immediately indicate tampering and likely counterfeiting. Hence, digital watermarks used in a government-issued identification document may provide strong and effective deterrence to counterfeit. In addition, in granting a government-issued identification document, the government generally has conducted a background check of the applicant and verified the applicant's identity according to an established and elaborate protocol. Because of the inherent government authority in granting and issuing the government-issued identification document, possession of a valid government-issued identification document may establish strong proof of the identity of the document holder.
[0046] Digital watermarking is secure, covert and machine-readable. To validate the government-issued identification document, the digital watermark may be analyzed according to an example method as illustrated in Fig. 3. Specifically, steganography may analyze the digital watermark and reveal the information identifying the holder. In addition, data contents encoded by the digital watermarks may be encrypted so that the encoded data contents may remain secure, as an additional security mechanism. In some implementations, the digital watermark may be initially analyzed to extract frequency domain information (302). The frequency domain information may include spectrum information manifested by, for example, the digital cosine transform (DCT) coefficients in a particular spatial frequency range. In contrast to spatial domain information, such frequency domain information may be robust to cropping or translation of the original document. Hence, the frequency domain information may be more tamper-proof and more resilient to artifacts during field use. Likewise, mixed-domain information, i.e., information from both spatial domain and frequency domain may provide similar degree of robustness against tampering and artifacts. However, the implementations disclosed herein are not limited to the use of frequency domain information alone or the use of
mixed-domain information. Spatial domain information may be used according to the same scheme as disclosed herein.
[0047] The frequency domain information may encode a pattern for validation purposes.
The pattern may be chosen by the issuing authority and remain secretive to the outside world, and only. To validate the government-issued identification document, the frequency domain information may be compared with the known pattern (304). In some implementations, the comparison may be performed locally at mobile device 101. In some implementations, mobile device 101 may send the extracted frequency domain information to a central server for the comparison. Details of the different architectures are provided in association with Fig. 5B.
[0048] The comparison may determine whether there is a substantial match between the extracted frequency domain information and the known pattern (306). The extracted frequency domain information does not have to perfectly match the known pattern. In some
implementations, for example, the frequency domain information may be incomplete due to losses in the scanning process. In some implementations, the degree of match may depend on the context of the application. For example, for applications involving mobile transactions with a financial sum of under $500, a lower degree of match authentication level may be sufficient. While for applications involving mobile transactions regarding, for example, any purchase of controlled substances, a higher degree of match may be adopted. In some implementations, the matching process may depend on jurisdiction. For example, in some states which adopted a less sophisticated digital watermark, a more primitive match procedure may be performed. Even in states that have adopted a more sophisticated digital watermark, legacy identification cards may still use the old and less sophisticated digital watermarking. These legacy identification cards may still be honored by a more primitive matching procedure. In some implementations, ascertaining whether there is a substantial match may further factor in prior dealings between the person requesting the mobile transaction and the holder of the government-issued identification document. For example, if the person requesting the mobile transaction has been paying for the holder of the government-issued identification document frequently in the past, then the degree of match may be lessened to simplify the process. A trusted consumer database can be set up if needed.
[0049] If substantial match has been found between the extracted frequency domain information and the pattern, mobile device 101 may authenticate the government-issued
identification document (310). Conversely, if substantial match has not been found between the extracted frequency domain information and the pattern, mobile device 101 may reject the validity of the government-issued identification document. In some implementations, the mobile device may alert the holder of the government-issued identification document of the rejection. The mobile device could also ask for another valid form of identification and, an alert may be sent through email, automatic voicemail, short message service (SMS) message, etc.
[0050] When government-issued identification document has been validated, mobile device 101 may read information of the holder encoded in the document. The information may include, for example, name, gender, age, birth date, residential address, telephone number, or physical characteristics of the holder, etc. Example physical characteristics may include height, weight, hair color, eye color, etc. Such information may be encoded in a magnetic stripe or barcode. In some implementations, mobile device may simply scan the document and extract such information by, for example, OCR techniques.
[0051] Returning to Fig. 2, the information of the holder may be used to authenticate that the user requesting the mobile transaction is the person authorized to request the mobile transaction (208). The authentication may compare the information of the holder with data associated with the person requesting the mobile transaction. The data of the user requesting the mobile transaction may include, for example, the name, age, gender, or residential address of the requester. Such data may be obtained, for example, from the mobile transaction request itself. In the example of credit/debit card payment as illustrated in Fig. 1, the data may be read from credit/debit card 103 by card reader 102.
[0052] Example authentication processes according to some implementations are illustrated in Figs. 4A and 4B. Referring to Fig. 4A, an example authentication method may initiate by comparing the identity of the user requesting the mobile transaction and the identity of the subject issued by the government according to the identification document (402). The identity may include at least one of: a name, an age, a birth date, a residential address, or a sequence number. The sequence number may include, for example, a social security number, a driver license number, a veteran number, a passport number, an alien registration number, etc.
[0053] Mobile device 101 may ascertain whether there is a match between the identity of the user making the request for the mobile transaction and the identity of the subject issued by the government as documented by the identification document (404). At no time is the
personally identifiable information of the user stored or held for future use. In the context of matching one identity to another identity, the match may be exact when comparing two numeric values while the match may be case insensitive when comparing two character strings (such as names) or alpha-numeric strings (such as addresses). The degree of match may also depend on the underlying mobile transaction. If the underlying mobile transaction involves a financial sum of over $500 or a purchase of any controlled substances, the degree of match may be high.
Conversely, if the underlying mobile transaction involves a petite sum (for example, a financial sum of under $50), the degree of match may be lessened.
[0054] If mobile device 101 identifies a match between the identity of the user making the request for the mobile transaction and the identity of the subjected issued by the government as documented by identification document, mobile device 101 may determine that the user is authorized to request the mobile transaction (406). However, if mobile device 101 fails to identify a match between the identity of the user making the request for the mobile transaction and the identity of the subjected recorded by the government-issued identification document, mobile device 101 may determine that the user is not authorized to request the mobile transaction (408). If it is a legitimate error the user will be prompted to present another valid proof of ID. As discussed above, in some implementations, depending on the legal relationship between the user making the request for the mobile transaction and the person presenting the government- issued identification document, mobile device may still authorize the requested mobile transaction to proceed, if, for example, the user requesting the mobile transaction has been authorized by the holder of the government-issued identification document.
[0055] Referring to Fig. 4B, another example authentication method may initiate by comparing the identity of the subject issued by the government as documented by identification document with a requirement for the mobile transaction (412). In some implementations, the identity of the subject issued by the government may be checked for the age, the residential address, etc. to comply with legal requirements for engaging in the requested mobile transaction. For example, the legal drinlcing age may be the requirement for the requested mobile transaction of purchasing liquor, alcohol, or wine products. Based on the context, the legal drinking age in the jurisdiction where the mobile transaction is placed and the legal drinking age in the jurisdiction where the on-line vendor is located may be different. Both legal requirements may be included. The legal age for requesting social security distribution may be another example
requirement. For example, different jurisdiction may impose varying restrictions on on-line purchase requests and therefore the residential address or residential history may be yet another example requirement.
[0056] Mobile device 101 may ascertain whether the identity of the subject issued by the government satisfies the requirement for the mobile transaction (414). In the case of multiple legal requirements, mobile device 101 may ascertain whether all such legal requirements are satisfied.
[0057] If the identity of the subject issued by the government as documented by identification document satisfies the requirement for the mobile transaction, mobile device 101 may determine that the user is authorized to request the mobile transaction (406). However, if the identity of the subject issued by the government as documented by the identification document does not satisfy the requirement for the mobile transaction, mobile device 101 may determine that the user is not authorized to request the mobile transaction (408). As discussed above, in some implementations, depending on the legal relationship between the user making the request for the mobile transaction and the person presenting the government-issued identification document, mobile device may still authorize the requested mobile transaction to proceed, if, for example, the user requesting the mobile transaction is the beneficiary of the holder of the government-issued identification document.
[0058] Fig. 5A illustrates an example of a mobile device authenticating a request by using a government-issued identification document. Upon receiving a request for a mobile transaction (502), mobile device 101 may expect a credential to back up the request. The credential may come in the form of a government-issued identification card 504. In some implementations, mobile device 101 may prompt the user of mobile device 101 to present his or her government-issued identification card 504. In some implementations, the user of mobile device 101 may present his or her government-issued identification card 504 without being prompted by mobile device 101.
[0059] The request for mobile transaction 502 may include a request for a credit/debit card payment, a request for a wire transfer of funds, an on-line purchase request, an on-line request for distribution, an on-line request for reimbursement, an on-line request for account access, etc.
[0060] A wire transfer may allow the requester to transfer funds in one account to another account, for example, in a different bank in a different locale or country. The wire transfer request may also include requests to fund an on-line stock or stock option purchase through a checking account, a savings account, etc.
[0061] An on-line purchase request may include a purchase request for a special item
The purchase request may be at a point of service when a customer comes in person to collect a controlled item for which the customer needs to be vetted before collecting the controlled items. The special item or controlled item may include, for example, alcohol, liquor, wine, small arms, ammunitions, over-the-counter (OTC) drugs that may contain controlled substances etc.
Controlled substances may include any substances that falls under the Controlled Substances Act. Additionally, the special item may also include certain electronics equipment and accessories that may be used for surveillance or eavesdropping.
[0062] An on-line request for distribution may include a request for a distribution of social security benefits, a retirement plan distribution, a pension plan distribution etc.
[0063] An on-line request for reimbursement may 'include a request for reimbursement of medicare benefits, Medicaid benefits, or a state-sponsored health care plan such as, for example, MediCal in the state of California. The on-line request for reimbursement may additionally include a request for private insurance reimbursement for health care expenses, property repair expenses for auto or home, etc.
[0064] An on-line request for account access may include a request to change any information in an on-line account, such as, for example, an on-line EZ-pass account, an on-line individual Department of Motor Vehicle (DMV) account, an on-line bank account, an on-line credit/debit card account, etc. The on-line request for account access may also include a request for payment through an intermediary, such as a PayPal account, a BillMeLater account, a GoolgleWallet account, etc.
[0065] Government-issued identification card 504 may include a state-issued driver license, a passport issued by the State Department, a permanent resident card issued by the Unites States Citizenship and Naturalization Service (USCIS), a naturalization certificate issued by the USCIS, a social security card issued by the social security service, a Medicare card issued by the Department of Human and Health Services (DHHS), a Medicaid card issued by the DHHS. Government-issued identification document may additionally include a national
identification card, as used in countries in Europe, Asia, and Latin America. Government-issued identification document may also include a state-issued Medicare card, such as the Medical card issued by the state of California, etc.
[0066] Figs. 5B-D illustrate various examples in which a mobile device validates a government-issued identification document. Once presented with the government-issued identification document, mobile device 101 may validate the identification card locally on-site, as shown in Fig. 5B. The on-site validation may be based on the digital watermark as discussed above.
[0067] Referring to Fig. 5C, in some implementations, mobile device 101 may transmit information encoding the digital watermark to commercial central server 506. The information encoding the digital watermark may be transmitted along with a validation request 501 to commercial central server 506. Commercial central server 506 may house a database for validating digital watermark. The validation may be based a comparison of frequency-domain information or mixed-domain information, as outlined above. Frequency domain information may be more robust than spatial domain information for being more tamper-proof and resilient to errors (for example, due to cropping or zooming). However, the implementations disclosed herein are not limited to frequency-domain information or mixed-domain information and can be applied to spatial-domain information. When commercial central server 506 finishes the validation, commercial central server 506 may transmit validation request 512 back to mobile device 101. Thereafter, mobile device 101 may act accordingly based on the contents of validation result 512, as discussed above.
[0068] Referring to Fig. 5D, in some implementations, mobile device 101 may transmit information encoding the digital watermark to government central server 508. The information encoding the digital watermark may be transmitted along with a validation request 501 to government central server 508. Digital watermarking may also work across jurisdictions, from federal to state or from state to state. As the issuer of government-issued identification document 504, government central server 508 may house a database of raw information for validating digital watermark. Government central server 508 may be administered by the issuing agency directly, or through a proxy, including, for example, a third-party independent contractor. In some implementations, commercial central server may transmit additional validation request to
government central server 508 for final resolution of a valdation request originally sent from mobile device 101.
[0069] In some implementations, the paradigm of authentication can be used without a tie to a database. In some implementations, the authentication can also be used in relation to a database if so desired. Authentication solutions to address on-line fraud or identity theft may incorporate sophisticated software mechanisms. Such authentication solutions may be cumbersome and less user-friendly, especially an average and unsophisticated user. In contrast, government-issued identification documents are becoming more acceptable in that they are used by people from all walks of life. In addition, government-issued identification document carries the authentication digital watermark issued by the government and tend to be self-authenticating. Moreover, before a government-issued identification document is issued, an elaborate verification process has been performed by the government to confirm that the applicant is who he or she purports to be and that the information provided by the applicant is accurate and complete, as of the application date. As disclosed herein, these features of a government-issued identification document may be incorporated by a mobile device to authenticate that a user requesting a mobile transaction is authorized to request the mobile transaction. The resulting authentication method addresses on-line fraud and identity theft issues with no significant compromise in convenience and ease of use. The resulting authentication method may be readily implemented on a variety of mobile devices, such as, for example, a smart phone, a tablet device, a laptop device, or even a home desktop computer.
[0070] Various implementations of systems and techniques described here can be realized in digital electronic circuitry, integrated circuitry, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and/or combinations thereof. These various implementations can include implementation in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.
[0071] The use of the digital watermark is stateless. During an implemented method, the personally identifiable information of the user stored or held is not stored for future use.
[0072] Fig. 6 illustrates an example of a mobile device 101 configured to associate government-issued identification card with a mode of payment. A government-issued identification card 504 may be associated with payment mode 602 on mobile device 101. The government-issued identification card may be registered at the mobile device 101 as a credential for accessing payment mode 602 on mobile device 101. For example, the government-issued identification card of user 604 may be registered at the mobile device by virtue that user 604 is the registered owner of the mobile device. The government-issued identification card of user 604 may also be registered by configuring user 604 as an authorized user for accessing payment mode 602.
[0073] Payment mode 604 may be any mode of on-line payment, including, for example, a credit card payment, a debit card payment, a payment through an intermediary account.
Example intermediary accounts may include: a pay-pal account, a BillMeLater account, a Google wallet account, etc. Under payment mode 604, funds from an account may be drawn to render payment on-line. The account may be owned by the same user as identified by the government-issued identification card. The account may also be owned by a user different from the subject identified by the government-issued identification card. When the user who owns the account is different from the subject identified by the government-issued identification card, the subject may be an authorized user of the account. The authorized user may be, for example, a relative, a employee, an agent, or a friend of the owner of the account.
[0074] Government-issued identification card 504 and payment mode 502 may be linked at the mobile device 101. The linking may enable the use of government-issued identification card 504 to support payment under payment mode 602 on mobile device 101.
[0075] Fig. 7 is a flow chart showing an example of a method of using a government- issued identification document to support an on-line payment in response to a request for payment. The method may initiate by generating an association between a government-issued identification document with a mode of payment (702). The government-issued identification document may be an identification card, a driver's license, a passport, etc. A payment mode may be any on-line payment mode. The association may be an indirect association through a mobile device 101. The association may enable using government-issued identification document as a credential to render payment. Moreover, the association may enable the use of government- issued identification document to support rendering the payment without additional credentials
[0076] Then, the method may proceed by generating receiving a presentation of the government-issued identification document at the mobile device to support a request for payment (704). For example, the mobile device may capture an image of the presented government- issued identification document. Thereafter, the image may be analyzed to extract frequency domain information encoding a digital watermark. The digital watermark may be used as a basis to validate the presented government-issued identification document, as discussed above.
[0077] Thereafter, in response to validating the government-issued identification document, the method may proceed by rendering payment using the mode of payment associated with the government-issued identification document (706). Thus, the government-issued identification document may be used as a credential to respond to a payment request on mobile device. In particular, government-issued identification document may be used to support rendering the payment without additional credentials from the user making the request for payment. Example additional credentials may include: presentation of the credit card or debit card such as swiping the credit card or the debit card; providing personal identification number (PIN) associated with the credit card account or the debit card account; providing a security code associated with the credit card or the debit card; providing the password associated with the credit card account, the debit card account, or the intermediary account; answering security questions associated with the credit card account, the debit card account, or the intermediary account, etc. The security code associated with the credit card or the debit card may also be known as the card verification value code.
[0078] Fig. 8A is a flow chart showing an example of associating an account of a user with a government-issued identification document on a mobile device. An example method may initiate by registering an account of the user (802). The account may be an on-line account including, for example, a credit card account, a debit card account, an intermediary account. The credit card may be associated with any vendors including, for example, Visa, MasterCard, American Express, Discover, etc. The debit card account may be associated with any financial institutions, such as banks, credit unions, etc. The intermediary account may be an account to transfer funds from a credit card account or a debit card account to a different credit card account or different debit account. Example intermediary accounts may include: a PayPal account.
BillMeLater account, or a GoogelWallet account, etc. Registration may include signing up the account to be used for rending payment on a mobile device. The registration may enable using a
government-issued identification document as a credential document on the mobile device to render payment from the account.
[0079] The method may then proceed by authenticating the account (804). The authenticating may include requesting password or security code for accessing the account online. The authenticating may include depositing a small sum of money in the account and requesting the user the confirm the sum of money that has been deposited. Because the small sum may be a random number, confirming the small sum deposited may indicate that the correct account has been accessed. The authenticating may include a subsequent withdrawing the small sum of money. Similarly, the authenticating may include withdrawing a small sum of money in the account and requesting the user the confirm the sum of money that has been withdrawn. The authenticating may include a subsequent depositing of the withdrawn sum.
[0080] The method may then check the success status of the authentication (806). If the authentication is not successful, the account may be rejected on the mobile device as an account to be associated with the government-issued identification card (808).
[0081] If the authentication is successful, the method may proceed by associating the account with the government-issued identification card on the mobile device to support a mode of on-line payment. The association may enable the government-issued identification card to be used as a credential for rendering payment on-line. The government-issued identification card of a user may be registered at the mobile device by virtue that the user is the registered owner of the mobile device. The government-issued identification card of user 604 may also be registered by configuring user 604 as an authorized user for the on-line account.
[0082] Fig. 8B illustrates a government-issued identification document being associated with example accounts, as configured on a mobile device. In particular, government-issued identification card 504 may be associated with a bank account 812, an intermediary account 814, and a credit card 816. The association may allow government-issued identification card 504 to be used as a credential to satisfy an authentication factor before access to bank account 812, intermediary account 814, and credit card 816 can be granted. Bank account 812, intermediary account 814, and credit card 816 may then provide funds meet an on-line payment request that is backed by the government-issued identification document.
[0083] Fig. 9A is a flow chart showing an example of extracting correlated personal identification information from a government-issued identification document. First, personal
identification information may be read from multiple machine-readable zones (MRZs) of the government-issued identification document (902). Personal identification information (PII) may be any information about an individual maintained by an agency, including (1) any information that can be used to distinguish or trace an individual's identity, such as name, social security number, date and place of birth, mother's maiden name, or biometric records; and (2) any other information that is linked or linkable to an individual, such as medical, educational, financial, and employment informationmay include name, address, date of birth, residential address, occupation, marital status, eye color, hair color, height, weight, blood type, etc. Machine readable zones may refer to an area on the identity page of a government-issued identification document. For example, on a passport, the MRZ may be at the bottom of the identity page and may span two lines and each line may be 44 characters long. Example information provided in the MRZ of a passport may include name, document number, nationality, date of birth, sex, document expiration date and personal identity number. Multiple MRZs may be present on the government-issued identification document. Each MRZ may encode complimentary or redundant information using various underlying materials or technologies. Example
technologies may including embedding digital watermark in frequency domain information on the printed media, laser irradiation on the substrate material to encode information, etc.
[0084] The personal identification information (PII) obtained from readings from multiple MRZs may be correlated (904). The correlation may be performed by comparing the PII from each MRZ. The correlation may depend on the quality of the readout, which in turn may hinge on the wear-and-tear of the government-issued identification document. The correlation may also depend on the level of embedding of the PII in each MRZ by the jurisdictional authority issuing the identification document. Some jurisdictions may implement more sophisticated identification document with improved complimentary readout from the MRZs. Within the same jurisdiction, however, more recently issued identification document may have more sophisticated MRZ implementations. Correlation result may be the correlated PII (906).
[0085] Fig. 9B illustrates reading from multiple readable zones (MRZs) of the government-issued identification document. The identification document 104 may include a MRZ with a printed bar code, a QR code, or other symbology code. The MRZ may also include printed microtext, digital watermark embedded as frequency domain information associated with
Moire's patterns, etc. The MRZ may be scanned optically (908) by infrared-laser (e.g., at 1060 nm wavelength), by visible light, etc.
[0086] The identification document 104 may also include a MRZ corresponding to a magnetic stripe. PII in this MRZ may be encoded on the magnetic stripe. The encoded PII may be readable by a swiping the identification document on a magnetic reader (910). The encoded PII may not be visible and may stay hidden from plain view. In other words, this encoded PII may be covert.
[0087] The identification document 104 may additionally include a MRZ with a portrait of the holder to whom the identification document has been issued by government authority. The MRZ may also include printed text indicating license number, date of birth, expiration date of the identification document, full name of the holder, residential address of the holder, gender, height, weight, hair color, eye color, race, etc. PII in this MRZ may be read by facial recognition technology in combination with optical character recognition (OCR) technology (912).
[0088] The information read from multiple MRZs may be compared against each other.
For example, the name on the identification document may be compared against the PII encoded on the magnetic stripe or in the digital watermark. The comparison may indicate whether the identification document has been tampered after issuance. Additionally, the information read from multiple MRZs may also supplement each other to build a more comprehensive listing of correlated information.
[0089] Fig. 10 is a flow chart showing an example of using a mode of on-line payment to server a request for payment upon validating correlated personal identification information obtained from the government-issued identification document. The correlated PII 906 may be validated against an authoritative system of record (1002). As described above, the validation may be performed locally by comparing the correlated PII 906 with a local copy of the authoritative system of record (SoR). The validation may also be performed by transmitting the correlated PII 906 to a remote server hosting a central copy of the authoritative SoR. The comparison may be performed on the remote server and the comparison results may be relayed back to the mobile device. In some implementations, the remote server may be located at and administered by a government agency, such as, for example, the DMV, the USCIS, the TSA, etc. In other implementations, the remote server may be managed by a commercial entity, such as a subcontracting entity of the government agency. The subcontracting entity may be entrusted by
the government agency. In some implementations, the payload of the correlated PII may be as low as a few bits. Thus, scaling up of the implementations disclosed herein may be feasible and extensive deployment of the implementations may not be prone to denial of service (DoS) attacks.
[0090] The status of the validation may be determined (1004). If the validation is not successful, the request for payment 1010 may be rejected (1006). If the validation is successful, payment may be rendered using the mode of on-line payment associated with the government- issued identification document (1008).
[0091] Validation result 512 may depend on request for payment 1010. For example, if the request involves payment under $100, then the validation may be cursory and may not be as thorough as a request for payment of $1000. For example, if the request is for purchasing alcohol at the point of sale, the validation may focus on the holder's age and driving history. This validation may also depend on when the request is submitted. For example, in the case of purchasing alcohol at the point of sale, if the request is submitted after 9pm, the validation may be conducted more strictly than during day time. For example, in jurisdictions that outlaw drinking or sale of alcohol after 9pm, the request may be denied. In some implementations, the validation may additionally factor in the authorized user's behavior history. For example, if the request is submitted from an area where the authorized user is believed to be absent, then the request may be blocked. The areas where the authorized user is believed to be present may be configured in accordance with the travel schedule of the authorized user. The areas outside the areas of presence may be the areas of absence.
[0092] In some implementations, after payment has been rendered using the mode of online payment, the transaction may be rolled back if identity theft has been confirmed to have tainted the transaction. The ID theft may be confirmed by the bank, credit card company, intermediary account hosting company.
[0093] By associating a government-issued identification document with a payment mode, rendering payment may be made by presenting the government-issued identification document as the authenticating credential. Payment may be rendered without presentations of further credentials associated with the payment mode.
[0094] Computer programs (also known as programs, software, software applications or code) include machine instructions for a programmable processor, and can be implemented in a
high-level procedural and/or object-oriented programming language, and/or in assembly/machine language. As used herein, the terms "machine-readable medium" "computer-readable medium" refers to any computer program product, apparatus and/or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal used to provide machine instructions and/or data to a programmable processor.
[0095] Suitable processors for the execution of a program of instructions include, by way of example, both general and special purpose microprocessors, and the sole processor or one of multiple processors of any kind of computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The elements of a computer may include a processor for executing instructions and one or more memories for storing instructions and data. Generally, a computer will also include, or be operatively coupled to communicate with, one or more mass storage devices for storing data files; such devices include magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and optical disks. Storage devices suitable for tangibly embodying computer program instructions and data include all forms of non- olatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, ASICs (application-specific integrated circuits).
[0096] To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having a display device (e.g., a CRT (cathode ray tube), LCD (liquid crystal display) monitor, LED (light-emitting diode) or OLED (organic light-emitting diode) monitors) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form, including acoustic, speech, or tactile input.
[0097] The systems and techniques described here can be implemented in a computing system that includes a back end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front end component (e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network ("LAN"), a wide area network ("WAN"), and the Internet.
[0098] The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
[0099] A number of implementations have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the invention. For example, much of this document has been described with respect to messaging and mapping applications, but other forms of graphical applications may also be addressed, such as interactive program guides, web page navigation and zooming, and other such applications.
[00100] In addition, the logic flows depicted in the figures do not require the particular order shown, or sequential order, to achieve desirable results. In addition, other steps may be provided, or steps may be eliminated, from the described flows, and other components may be added to, or removed from, the described systems. Accordingly, other embodiments are within the scope of the following claims.
Claims
1. A method, comprising:
generating an association, at a mobile device, between a government-issued identification document of a user and a mode of payment;
receiving, at the mobile device, a presentation of the government-issued identification document of the user to support a request for payment;
validating whether the presented government-issued identification document is a valid identification of the user; and
in response to validating the presented government-issued identification document, rendering payment by using the mode of payment.
2. The method of claim 1, wherein generating the association further comprises:
registering, on the mobile device, an account of the user to support the mode of payment; and
authenticating that the user owns the account.
3. The method of claim 2, wherein generating the association further comprises:
associating, on the mobile device, the authenticated account with the government-issued identification document.
4. The method of claim 3, wherein the associating further comprises:
linking the authenticated account owned by a first user to the government-issued identification documents held by a second user, the second user being different from the first user.
5. The method of claim 2, wherein registering the account further comprises: registering a bank account, an intermediary account, or a credit card account.
6. The method of claim 1, wherein receiving comprises:
reading personal identification information (PII) from multiple machine-readable zones (MRZs) on the government-issued identification document.
7. The method of claim 6, wherein receiving further comprises:
correlating, at the mobile device, the personal identification information (PII) read from multiple machine-readable zones (MRZs).
8. The method of claim 7, wherein validating comprises:
checking the personal identification information (PII) read from multiple machine-readable zones against a system of record.
9. The method of claim 8, wherein validating further comprises:
transmitting the personal identification information (PII) read from multiple machine-readable zones (MRZs) to a server hosting the system of record; and
receiving, from the server, validation results' of checking the personal
identification information against the system of record.
10. The method of claim 2, wherein rendering payment comprises drawing funds from the registered account to fulfill the request for payment without additional authentication that the user owns the registered account.
11. The method of claim 10, wherein rendering payment comprises drawing funds from the registered account of a first user to fulfill the request for payment from a second user, different from the first user.
12. The method of claim 1, wherein rendering payment comprises paying through a debit card without presenting the debit card, paying through an intermediary account without authentication for the intermediary account, or paying through a credit card without presenting the credit card.
13. A mobile device, comprising at least one processor configured to:
generate an association between a government-issued identification document of a user and a mode of payment;
receive a presentation of the government-issued identification document of the user to support a request for payment;
validate whether the presented government-issued identification document is a valid identification of the user; and
in response to validating the presented government-issued identification document, render payment by using the mode of payment.
14. The mobile device of claim 13, wherein the at least one processor is further configured to:
register an account of the user on the mobile device to support the mode of payment; and
authenticate that the user owns the account.
15. The mobile device of claim 14, wherein the at least one processor is further configured to: associate the authenticated account with the government-issued identification document.
16. The mobile device of claim 15, wherein the at least one processor is further configured to associate the authenticated account with the government-issued identification document by linking the authenticated account owned by a first user to the government-issued identification documents held by a second user, different from the first user.
17. The mobile device of claim 14, wherein the at least one processor is further configured to register the account by registering a bank account, an intermediary account, or a credit card account.
18. The mobile device of claim 13, wherein the at least one processor is further configured to: read personal identification information (PII) from multiple machine-readable zones (MRZs) on the government-issued identification document.
19. The mobile device of claim 18, wherein the at least one processor is further configured to:
correlate personal identification information (PII) read from multiple machine- readable zones (MRZs).
20 The mobile device of claim 19, wherein the at least one processor is further configured to:
check personal identification information (PII) read from multiple machine- readable zones against a system of record.
21. The mobile device of claim 20, wherein the at least one processor is further configured to:
transmit personal identification information (PII) read from multiple machine- readable zones (MRZs) to a server hosting the system of record; and
receive, from the server, validation results of checking personal identification information against the system of record.
22. The mobile device of claim 14, wherein the at least one processor is further configured to render payment by drawing funds from the registered accoiint to fulfill the request for payment without additional authentication that the user owns the registered account.
23. The mobile device of claim 22, wherein the at least one processor is further configured to render payment by drawing funds from the registered account of a first user to fulfill the request for payment from a second user, different from the first user.
24. The mobile device of claim 13, wherein the at least one processor is further configured to render payment by paying through a debit card without presenting the debit card, paying tlirough an intermediary account without authentication for the intermediary account, or paying through a credit card without presenting the credit card.
25. A computer-implemented method, comprising:
receiving, at a server and from a mobile device, correlated personal identification information obtained from multiple machine-readable zones (MRZs) of a government-issued identification document, the government-issued identification document being presented at the mobile device to support a request of payment;
checking the correlated personal identification information against a system of record; transmitting, by the server and to the mobile device, results of checking to the mobile device based on which the mobile device renders payment in response to the request of payment and with no additional checking.
26. The computer implemented method of claim 25, wherein checking the correlated personal identification information comprises checking the correlated personal identification information against the system of record administered by a government entity.
27. The computer implemented method of claim 26, wherein checking the correlated personal identification information comprises:
transmitting, by the server and to the government entity, the correlated personal identification; and
receiving, by the server and from the government entity, results of checking the correlated personal identification against the system of record.
28. A computer-readable medium comprising software instructions that when executed by one or more processors, cause the one or more processors to:
receive, from a user on the mobile device, a request for a mobile transaction;
inspect a government-issued identification document presented by the user to obtain a digital watermark, the government-issued identification document documenting an identity of a subject;
validate the government-issued identification document based on the digital watermark; and
in response to validating the government-issued identification document as valid, authenticate the user as authorized to request the mobile transaction being requested.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201361806156P | 2013-03-28 | 2013-03-28 | |
US61/806,156 | 2013-03-28 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2014160582A1 true WO2014160582A1 (en) | 2014-10-02 |
Family
ID=51621822
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2014/031306 WO2014160582A1 (en) | 2013-03-28 | 2014-03-20 | System and method for transaction authentication |
Country Status (2)
Country | Link |
---|---|
US (3) | US10311435B2 (en) |
WO (1) | WO2014160582A1 (en) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2017063531A1 (en) * | 2015-10-14 | 2017-04-20 | 阿里巴巴集团控股有限公司 | Account mapping method and device based on address information |
WO2020173696A1 (en) | 2019-02-28 | 2020-09-03 | Sicpa Holding Sa | Verifiable access credential |
WO2022049025A1 (en) | 2020-09-02 | 2022-03-10 | Sicpa Holding Sa | Security marking, method and device for reading the security marking, security document marked with the security marking, and method and system for verifying said security document |
RU2803761C2 (en) * | 2019-02-28 | 2023-09-19 | Сикпа Холдинг Са | Verifiable user access credentials |
Families Citing this family (29)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9824198B2 (en) | 2011-07-14 | 2017-11-21 | Docusign, Inc. | System and method for identity and reputation score based on transaction history |
WO2014160582A1 (en) | 2013-03-28 | 2014-10-02 | Robert Andrew Eckel | System and method for transaction authentication |
US9481197B2 (en) | 2013-06-05 | 2016-11-01 | Morphotrust Usa, Llc | System and method for credential authentication |
US10282802B2 (en) * | 2013-08-27 | 2019-05-07 | Morphotrust Usa, Llc | Digital identification document |
US9147152B2 (en) | 2013-10-18 | 2015-09-29 | Comenity Llc | Displaying an animated digital watermark |
US9438597B1 (en) * | 2013-10-22 | 2016-09-06 | Microstrategy Incorporated | Regulating credential information dissemination |
FR3023640B1 (en) * | 2014-07-10 | 2016-08-12 | Roam Data Inc | METHOD FOR MANAGING TRANSACTION, SERVER, COMPUTER PROGRAM PRODUCT AND CORRESPONDING STORAGE MEDIUM |
US10826900B1 (en) * | 2014-12-31 | 2020-11-03 | Morphotrust Usa, Llc | Machine-readable verification of digital identifications |
US9641752B2 (en) * | 2015-02-03 | 2017-05-02 | Jumio Corporation | Systems and methods for imaging identification information |
CN107251042A (en) * | 2015-02-19 | 2017-10-13 | 维萨国际服务协会 | Hidden image on mancarried device |
JP2018533142A (en) * | 2015-07-20 | 2018-11-08 | ノタライゼ, インク.Notarize, Inc. | System and method for authenticating authorship of an electronic signature session |
US10248940B1 (en) | 2015-09-24 | 2019-04-02 | Square, Inc. | Modular firmware for transaction system |
WO2017082716A1 (en) * | 2015-11-09 | 2017-05-18 | Three Logic Concepts Sdn. Bhd. | System and method of wireless membership registration and mobile phone number verification |
US11734678B2 (en) * | 2016-01-25 | 2023-08-22 | Apple Inc. | Document importation into secure element |
US10108412B2 (en) | 2016-03-30 | 2018-10-23 | Square, Inc. | Blocking and non-blocking firmware update |
US10417628B2 (en) * | 2016-06-29 | 2019-09-17 | Square, Inc. | Multi-interface processing of electronic payment transactions |
US10817869B2 (en) | 2016-06-29 | 2020-10-27 | Square, Inc. | Preliminary enablement of transaction processing circuitry |
US11010765B2 (en) | 2016-06-29 | 2021-05-18 | Square, Inc. | Preliminary acquisition of payment information |
WO2018045326A1 (en) * | 2016-09-01 | 2018-03-08 | Kelts A David | Bi-directional trust indicator |
US10891617B2 (en) | 2016-09-30 | 2021-01-12 | Mastercard International Incorporated | Systems and methods for biometric identity authentication |
US10296998B2 (en) * | 2016-11-10 | 2019-05-21 | Mcafee, Llc | Optical feedback for visual recognition authentication |
WO2018136537A1 (en) * | 2017-01-17 | 2018-07-26 | Fair Ip, Llc | System and method for low friction operator interface on a mobile device |
US10726478B2 (en) | 2017-01-17 | 2020-07-28 | Fair Ip, Llc | Data processing system and method for facilitating transactions with user-centric document access |
FR3083356B1 (en) * | 2018-06-29 | 2020-09-11 | Ingenico Group | PROCESS FOR CARRYING OUT A TRANSACTION, TERMINAL, SERVER AND CORRESPONDING COMPUTER PROGRAM |
US10990969B2 (en) | 2018-12-21 | 2021-04-27 | Square, Inc. | Point of sale (POS) systems and methods for dynamically processing payment data based on payment reader capability |
US10762196B2 (en) | 2018-12-21 | 2020-09-01 | Square, Inc. | Point of sale (POS) systems and methods with dynamic kernel selection |
US11049095B2 (en) | 2018-12-21 | 2021-06-29 | Square, Inc. | Point of sale (POS) systems and methods with dynamic kernel selection |
US11188913B2 (en) * | 2019-01-11 | 2021-11-30 | Capital One Services, Llc | Systems and methods for securely verifying a subset of personally identifiable information |
US11632367B2 (en) | 2020-05-28 | 2023-04-18 | Capital One Services, Llc | System and method for agnostic authentication of a client device |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5984366A (en) * | 1994-07-26 | 1999-11-16 | International Data Matrix, Inc. | Unalterable self-verifying articles |
US7363505B2 (en) * | 2003-12-03 | 2008-04-22 | Pen-One Inc | Security authentication method and system |
US8028896B2 (en) * | 2007-12-14 | 2011-10-04 | Bank Of America Corporation | Authentication methods for use in financial transactions and information banking |
US8083130B1 (en) * | 2002-05-17 | 2011-12-27 | Cipriano Joseph J | Identification verification system and method |
US8087583B2 (en) * | 2002-02-12 | 2012-01-03 | Digimarc Corporation | Associating media through encoding |
US20120114192A1 (en) * | 2010-11-04 | 2012-05-10 | The Go Daddy Group, Inc. | Systems and Methods for Person's Verification Using Scans of Identification Documents Produced by a Verifier-Controlled Scanning Device |
US8234172B2 (en) * | 2005-05-03 | 2012-07-31 | International Business Machines Corporation | System for securing card payment transactions using a mobile communication device |
US20120330769A1 (en) * | 2010-03-09 | 2012-12-27 | Kodeid, Inc. | Electronic transaction techniques implemented over a computer network |
Family Cites Families (46)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6985600B2 (en) * | 1994-03-17 | 2006-01-10 | Digimarc Corporation | Printing media and methods employing digital watermarking |
US5469506A (en) | 1994-06-27 | 1995-11-21 | Pitney Bowes Inc. | Apparatus for verifying an identification card and identifying a person by means of a biometric characteristic |
US6269169B1 (en) | 1998-07-17 | 2001-07-31 | Imaging Automation, Inc. | Secure document reader and method therefor |
US6978036B2 (en) | 1998-07-31 | 2005-12-20 | Digimarc Corporation | Tamper-resistant authentication techniques for identification documents |
JP3563270B2 (en) * | 1998-08-28 | 2004-09-08 | 株式会社日立製作所 | Authentication method of digital watermark image |
WO2001043026A1 (en) | 1999-12-07 | 2001-06-14 | Blue Spike, Inc. | Systems, methods and devices for trusted transactions |
US7836494B2 (en) * | 1999-12-29 | 2010-11-16 | Intel Corporation | System and method for regulating the flow of information to or from an application |
FI116086B (en) * | 2000-06-08 | 2005-09-15 | Avantone Oy | Check-marked paper or cardboard product and check-marked packaging |
US8543823B2 (en) | 2001-04-30 | 2013-09-24 | Digimarc Corporation | Digital watermarking for identification documents |
US7958359B2 (en) * | 2001-04-30 | 2011-06-07 | Digimarc Corporation | Access control systems |
US20020169962A1 (en) * | 2001-05-10 | 2002-11-14 | Brundage Trent J. | Digital watermarks used in automation equipment |
US20020169963A1 (en) | 2001-05-10 | 2002-11-14 | Seder Phillip Andrew | Digital watermarking apparatus, systems and methods |
US6854642B2 (en) * | 2001-10-19 | 2005-02-15 | Chesterfield Holdings, L.L.C. | System for vending products and services using an identification card and associated methods |
US20030086591A1 (en) | 2001-11-07 | 2003-05-08 | Rudy Simon | Identity card and tracking system |
US6766045B2 (en) * | 2002-03-11 | 2004-07-20 | Digital Verification Ltd. | Currency verification |
US20040104268A1 (en) | 2002-07-30 | 2004-06-03 | Bailey Kenneth Stephen | Plug in credit card reader module for wireless cellular phone verifications |
AU2003285891A1 (en) * | 2002-10-15 | 2004-05-04 | Digimarc Corporation | Identification document and related methods |
US6785405B2 (en) | 2002-10-23 | 2004-08-31 | Assuretec Systems, Inc. | Apparatus and method for document reading and authentication |
GB2402249A (en) | 2003-03-28 | 2004-12-01 | Qinetiq Ltd | Integrated passenger management system using biometric sensors and a mm wave camera |
US20040250142A1 (en) * | 2003-03-28 | 2004-12-09 | Feyler David M. | UV2D reader, age verification and license validation system |
US7561716B2 (en) | 2003-04-04 | 2009-07-14 | Datamark Technologies Pte Ltd | Watermarking method and apparatus |
US7844545B2 (en) * | 2003-04-25 | 2010-11-30 | The Western Union Company | Systems and methods for validating identifications in financial transactions |
US7706565B2 (en) * | 2003-09-30 | 2010-04-27 | Digimarc Corporation | Multi-channel digital watermarking |
WO2005038583A2 (en) | 2003-10-10 | 2005-04-28 | Kycos Holding Limited | Examiner |
US20050125360A1 (en) | 2003-12-09 | 2005-06-09 | Tidwell Lisa C. | Systems and methods for obtaining authentication marks at a point of sale |
US20060157559A1 (en) | 2004-07-07 | 2006-07-20 | Levy Kenneth L | Systems and methods for document verification |
US20060197337A1 (en) * | 2005-03-04 | 2006-09-07 | Canadian Bank Note Company, Limited | Identification document with lenticular watermark |
US8205791B2 (en) * | 2005-10-11 | 2012-06-26 | National Payment Card Association | Payment system and methods |
US20070255620A1 (en) * | 2006-03-30 | 2007-11-01 | Obopay Inc. | Transacting Mobile Person-to-Person Payments |
US20070294296A1 (en) * | 2006-06-08 | 2007-12-20 | Silver David S | Constituent data and transaction system |
US7512567B2 (en) * | 2006-06-29 | 2009-03-31 | Yt Acquisition Corporation | Method and system for providing biometric authentication at a point-of-sale via a mobile device |
US20080174100A1 (en) | 2007-01-22 | 2008-07-24 | Assuretec Systems, Inc. | Real time privilege management |
WO2009009788A1 (en) | 2007-07-12 | 2009-01-15 | Jobmann Brian C | Identity authentication and secured access systems, components, and methods |
DE102007050024A1 (en) | 2007-10-17 | 2009-04-23 | Bundesdruckerei Gmbh | Person control system and method for performing a person control |
US7689508B2 (en) * | 2007-11-20 | 2010-03-30 | Wells Fargo Bank N.A. | Mobile device credit account |
US8567578B2 (en) * | 2008-03-13 | 2013-10-29 | Targus Group International, Inc. | Portable computer case |
US20110022531A1 (en) | 2009-01-15 | 2011-01-27 | Jordan Robert L | Electronic Verification Software |
US20100250290A1 (en) * | 2009-03-27 | 2010-09-30 | Vegas.Com | System and method for token-based transactions |
DE102010016098A1 (en) | 2010-03-23 | 2011-09-29 | Kaba Gallenschütz GmbH | Access device |
US8666111B2 (en) * | 2011-05-24 | 2014-03-04 | Tata Consultancy Services Limited | System and method for detecting the watermark using decision fusion |
JP5656763B2 (en) | 2011-07-08 | 2015-01-21 | 株式会社日立製作所 | Immigration system |
CN104769622A (en) * | 2011-12-21 | 2015-07-08 | 英特尔公司 | Method for authentication using biometric data for mobile device e-commerce transactions |
US20130275303A1 (en) * | 2012-04-11 | 2013-10-17 | Mastercard International Incorporated | Method and system for two stage authentication with geolocation |
US8738527B2 (en) * | 2012-05-09 | 2014-05-27 | Fmr Llc | Establishing a financial account using a mobile computing device |
WO2014160582A1 (en) | 2013-03-28 | 2014-10-02 | Robert Andrew Eckel | System and method for transaction authentication |
US9481197B2 (en) | 2013-06-05 | 2016-11-01 | Morphotrust Usa, Llc | System and method for credential authentication |
-
2014
- 2014-03-20 WO PCT/US2014/031306 patent/WO2014160582A1/en active Application Filing
- 2014-03-20 US US14/220,547 patent/US10311435B2/en active Active
-
2019
- 2019-05-31 US US16/428,498 patent/US10943233B2/en active Active
-
2021
- 2021-03-08 US US17/195,379 patent/US11625721B2/en active Active
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5984366A (en) * | 1994-07-26 | 1999-11-16 | International Data Matrix, Inc. | Unalterable self-verifying articles |
US8087583B2 (en) * | 2002-02-12 | 2012-01-03 | Digimarc Corporation | Associating media through encoding |
US8083130B1 (en) * | 2002-05-17 | 2011-12-27 | Cipriano Joseph J | Identification verification system and method |
US7363505B2 (en) * | 2003-12-03 | 2008-04-22 | Pen-One Inc | Security authentication method and system |
US8234172B2 (en) * | 2005-05-03 | 2012-07-31 | International Business Machines Corporation | System for securing card payment transactions using a mobile communication device |
US8028896B2 (en) * | 2007-12-14 | 2011-10-04 | Bank Of America Corporation | Authentication methods for use in financial transactions and information banking |
US20120330769A1 (en) * | 2010-03-09 | 2012-12-27 | Kodeid, Inc. | Electronic transaction techniques implemented over a computer network |
US20120114192A1 (en) * | 2010-11-04 | 2012-05-10 | The Go Daddy Group, Inc. | Systems and Methods for Person's Verification Using Scans of Identification Documents Produced by a Verifier-Controlled Scanning Device |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2017063531A1 (en) * | 2015-10-14 | 2017-04-20 | 阿里巴巴集团控股有限公司 | Account mapping method and device based on address information |
US10725737B2 (en) | 2015-10-14 | 2020-07-28 | Alibaba Group Holding Limited | Address information-based account mapping method and apparatus |
US10990353B2 (en) | 2015-10-14 | 2021-04-27 | Advanced New Technologies Co., Ltd. | Address information-based account mapping method and apparatus |
WO2020173696A1 (en) | 2019-02-28 | 2020-09-03 | Sicpa Holding Sa | Verifiable access credential |
RU2803761C2 (en) * | 2019-02-28 | 2023-09-19 | Сикпа Холдинг Са | Verifiable user access credentials |
US11847527B2 (en) | 2019-02-28 | 2023-12-19 | Sicpa Holding Sa | Verifiable access credential |
KR102706997B1 (en) | 2019-02-28 | 2024-09-19 | 시크파 홀딩 에스에이 | Verifiable Access Credentials |
WO2022049025A1 (en) | 2020-09-02 | 2022-03-10 | Sicpa Holding Sa | Security marking, method and device for reading the security marking, security document marked with the security marking, and method and system for verifying said security document |
Also Published As
Publication number | Publication date |
---|---|
US10943233B2 (en) | 2021-03-09 |
US20200126082A1 (en) | 2020-04-23 |
US20210264427A1 (en) | 2021-08-26 |
US20140297530A1 (en) | 2014-10-02 |
US10311435B2 (en) | 2019-06-04 |
US11625721B2 (en) | 2023-04-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11625721B2 (en) | System and method for transaction authentication | |
US10521798B2 (en) | Digital financial transaction system | |
US11908030B2 (en) | Secure transaction system | |
US11210667B2 (en) | Customer identity verification system | |
US20140270336A1 (en) | System and Method for Transaction Authentication | |
US11379816B2 (en) | Secure electronic payment system | |
KR101203828B1 (en) | Electronic transaction verification system | |
US20160217356A1 (en) | System and Method for Encoding and Controlled Authentication | |
US20100123003A1 (en) | Method for verifying instant card issuance | |
US20100123002A1 (en) | Card printing verification system | |
US20110302089A1 (en) | Electronic credit card with fraud protection | |
US7980463B2 (en) | Cashiers check verification system | |
US20120032782A1 (en) | System for restricted biometric access for a secure global online and electronic environment | |
JP6703724B2 (en) | Financial transactions, security and management methods with biometric characteristic combination identification system | |
US20110145147A1 (en) | System and method for authorizing transactions | |
US20230177508A1 (en) | Contactless Biometric Authentication Systems and Methods Thereof | |
JP2006252110A (en) | Financial transaction system | |
US20110225045A1 (en) | Paperless Coupon Transactions System | |
US11823200B2 (en) | Smart physical payment cards | |
JP7495973B2 (en) | Secure payment method and system | |
US20100038418A1 (en) | Method for biometric authorization for financial transactions | |
KR20160148910A (en) | Real Time Internet Certificating Method using User Biometric Information | |
JP2005301400A (en) | Method for confirming validity of recipient |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 14773351 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 14773351 Country of ref document: EP Kind code of ref document: A1 |