System for handling network transactions

• US 10,565,567 B2
• Filed: 03/28/2018
• Issued: 02/18/2020
• Est. Priority Date: 05/25/1999
• Status: Expired due to Term

• Current Assignee: Safepay Australia Pty. Limited
• Original Assignee: Safepay Australia Pty. Limited
• Inventors: O'Hara, John
• Primary Examiner(s): Rudy, Andrew Joseph
• Application Number:
  US15/938,382
• Publication Number:
  US 20180218341A1
• Time in Patent Office: 692 Days
• Field of Search: 705 261, 705 51, 705 76, 705403, 709203, 709217-223, 348 E5006, 348 E5008
• CPC Class Codes: G06Q 20/02 involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
• CPC Class Codes: G06Q 20/04 Payment circuits
• CPC Class Codes: G06Q 20/12 specially adapted for electronic shopping systems
• CPC Class Codes: G06Q 20/3821 Electronic credentials
• CPC Class Codes: G06Q 20/385 using an alias or single-use codes
• CPC Class Codes: G06Q 20/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
• CPC Class Codes: G06Q 20/401 Transaction verification
• CPC Class Codes: G06Q 20/4012 Verifying personal identification numbers [PIN]
• CPC Class Codes: G06Q 30/06 Buying, selling or leasing transactions
• CPC Class Codes: G06Q 40/12 Accounting

Abstract

A method of securing a transaction that comprises a trust entity computer in communication with data storage, a first party and a second party over a network, and receiving a request from the first party to undertake a transaction with the second party. In addition, receives a first token, storing the first token in the data storage, receiving a second token from the second party, comparing the stored first token and the received second token, if the stored first token and the received second token are a match, enabling the transaction.

Claims

1. A method of securing a transaction, comprising:

by a trust entity computer in communication with a database, a first party and a second party over a network,

receiving a request from the first party to undertake a transaction with the second party;

receiving a first token;

storing the first token in the database;

receiving a second token from the second party;

assigning a time and date to the first and second token;

comparing the stored first token and the received second token, if the stored first token and the received second token are a match, enabling the transaction.

2. The method of claim 1 wherein the first and second token are each a one-time transaction identifier.

3. The method of claim 2 wherein each one time transaction identifier is a number.

4. The method of claim 1 further comprising, by the trust entity computer, disabling the first and second token from being used again.

5. The method of claim 3 wherein the number is a data string including a random number, a card type identifier and a date and time of the received request.

6. The method of claim 1 further comprising,

by the trust entity computer,

generating and storing a first buyer identification;

sending the first buyer identification to the buyer with the token;

receiving both a second buyer identification from the seller with the second token; and

comparing the second buyer identification with the stored first buyer identification.

7. The method of claim 1 further comprising,

by the trust entity computer,

comparing the time and date of the first token and the second token and if the time and date of the first token and the time and date of the second token are a match, enabling the transaction.

8. The method of claim 1 wherein the first and second token include a digital signature.

9. A non-transitory computer-readable medium having computer-executable instructions thereon for a method of securing a transaction the method comprising:

by a trust entity computer in communication with a database, a first party and a second party over a network,

receiving a request from the first party to undertake a transaction with the second party;

receiving a first token;

storing the first token in the database;

receiving a second token from the second party;

assigning a time and date to the first and second token;

comparing the stored first token and the received second token, if the stored first token and the received second token are a match, enabling the transaction.

10. The non-transitory computer-readable medium of claim 9 wherein the first and second token are each a one-time transaction identifier.

11. The non-transitory computer-readable medium of claim 10 wherein each one time transaction identifier is a number.

12. The non-transitory computer-readable medium of claim 9, the method further comprising, by the trust entity computer, disabling the first and second token from being used again.

13. The non-transitory computer-readable medium of claim 11 wherein the number is a data string including a random number, a card type identifier and a date and time of the received request.

14. The non-transitory computer-readable medium of claim 9, the method further comprising,

by the trust entity computer,

generating and storing a first buyer identification;

sending the first buyer identification to the buyer with the token;

receiving both a second buyer identification from the seller with the second token; and

comparing the second buyer identification with the stored first buyer identification.

15. The non-transitory computer-readable medium of claim 9, the method further comprising,

by the trust entity computer,

comparing the time and date of the first token and the second token and if the time and date of the first token and the time and date of the second token are a match, enabling the transaction.

16. The non-transitory computer-readable medium of claim 9 wherein the first and second token include a digital signature.

17. A means for securing a transaction, comprising:

by a trust entity computer in communication with a database, a first party and a second party over a network,

means for receiving a request from the first party to undertake a transaction with the second party;

means for receiving a first token;

means for storing the first token in the database;

means for receiving a second token from the second party;

means for assigning a time and date to the first and second token;

means for comparing the stored first token and the received second token, if the stored first token and the received second token are a match, enabling the transaction.