Supporting proximity based security code transfer from mobile/tablet application to access device
US-9104853-B2 · Aug 11, 2015 · US
US10949520B2 · US · B2
| Field | Value |
|---|---|
| Publication number | US-10949520-B2 |
| Application number | US-201916675172-A |
| Country | US |
| Kind code | B2 |
| Filing date | Nov 5, 2019 |
| Priority date | Oct 2, 2018 |
| Publication date | Mar 16, 2021 |
| Grant date | Mar 16, 2021 |
A practical reading order for non-experts. Skip the full description unless you need deep technical detail.
What the patent document calls the invention.
A short plain-language summary of the technical disclosure.
Who owns or filed the patent and who is credited as inventor.
Filing, priority, publication, and grant dates set the timeline.
The legal scope of protection — read this for what is actually claimed.
Technology tags used to group this patent with similar filings.
Prior art links and similar publications in this corpus.
Official abstract text for this publication.
Example embodiments provide systems and methods for validating an action using a physical token, such as a near-field-communications (NFC)-capable chip. A server may receive a request to perform the action, and may require validation from the holder of the physical token. The holder of the physical token may log into an application using their login credentials, providing a first tier of authentication. The holder may then scan the physical token with a reader on their mobile device, which provides a second tier of authentication. The scan may reveal a value for a counter on the physical token, which may be compared to a counter at the server in order to validate that the physical token has been used as expected. If the server deems it appropriate, a third (or further) tier may be required, such as scanning a photographic identification of the holder.
Opening claim text (preview).
What is claimed is: 1. A method comprising: receiving a request to confirm a transaction associated with a service; receiving a cumulative value from a physical token associated with a user representing a number of read operations performed; accessing a log, the log mapping users of the service to last-known values of respective physical tokens of the users; retrieving, from the log, the last-known value of the physical token associated with the user; identifying a window of acceptable values around the last-known value of the physical token, wherein the window is a dynamic range based on user profile information that indicates historical regular interactions for the user compared to other historical regular interactions for other users; determining that the cumulative value received from the physical token is within the window of acceptable values; and causing the transaction to be executed when the cumulative value is within the window. 2. The method of claim 1 , wherein the physical token is credit card. 3. The method of claim 1 , further comprising computing a risk value associated with the transaction. 4. The method of claim 3 , wherein a size of the window varies according to the risk value. 5. The method of claim 1 , comprising: determining that cumulative value is not within the window acceptable values; and sending a request to re-validate the physical token by the user to a device associated with the user. 6. The method of claim 1 , wherein each read operation of the read operations is performed by a near-field communication (NFC) reader. 7. The method of claim 1 , wherein at least one of the read operations is an accidental read operation performed by a near-field communication (NFC) reader. 8. A non-transitory computer-readable medium storing instructions configured to cause a processor to: receive a request to confirm a transaction associated with a service; receive a cumulative value from a physical token associated with a user representing a number of read operations performed; access a log, the log mapping users of the service to last-known values of respective physical tokens of the users; retrieve, from the log, the last-known value of the physical token associated with the user; identify a window of acceptable values around the last-known value of the physical token, wherein the window is a dynamic range based on user profile information that indicates historical regular interactions for the user compared to other historical regular interactions for other users; determine that the cumulative value received from the physical token is within the window of acceptable values; and cause the transaction to be executed when the cumulative value is within the window. 9. The medium of claim 8 , wherein the physical token is credit card. 10. The medium of claim 8 , further storing instructions for computing a risk value associated with the transaction. 11. The medium of claim 10 , wherein a size of the window varies according to the risk value. 12. The medium of claim 8 , further storing instructions for: determining that cumulative value is not within the window acceptable values; and sending a request to re-validate the physical token by the user to a device associated with the user. 13. The medium of claim 8 , wherein each read operation of the read operations is performed by a near-field communication (NFC) reader. 14. The medium of claim 8 , wherein at least one of the read operations is an accidental read operation performed by a near-field communication (NFC) reader. 15. An apparatus comprising: a hardware interface configured to receive a request to confirm a transaction associated with a service and receive a cumulative value from a physical token associated with a user representing a number of read operations performed; a non-transitory computer-readable medium storing a log mapping users of the service to last-known values of respective physical tokens of the users; and a hardware processor circuit configured to: retrieve, from the log, the last-known value of the physical token associated with the user, identify a window of acceptable values around the last-known value of the physical token, wherein the window is a dynamic range based on user profile information that indicates historical regular interactions for the user compared to other historical regular interactions for other users, determine that the cumulative value received from the physical token is within the window of acceptable values, and cause the transaction to be executed when the cumulative value is within the window. 16. The apparatus of claim 15 , wherein the physical token is credit card. 17. The apparatus of claim 15 , the hardware processor configured to compute a risk value associated with the transaction, wherein a size of the window varies according to the risk value. 18. The apparatus of claim 15 , wherein a size of the window varies according to the risk value. 19. The apparatus of claim 15 , the hardware processor configured to: determine that cumulative value is not within the window acceptable values; and send a request to re-validate the physical token by the user to a device associated with the user. 20. The apparatus of claim 15 , wherein at least one of the read operations is an accidental read operation performed by a near-field communication (NFC) reader.
applying multi-factor authentication · CPC title
Authentication · CPC title
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 · CPC title
using near field communication [NFC] or radio frequency identification [RFID] modules · CPC title
Subscriber identity · CPC title
Related publications grouped by family.
Answers are generated from the same data shown on this page.