Reliance manager for electronic transaction system

• US 7,177,839 B1
• Filed: 01/27/2000
• Issued: 02/13/2007
• Est. Priority Date: 12/13/1996
• Status: Expired due to Fees

• Current Assignee: Certco
• Original Assignee: Certco
• Inventors: Yung, Marcel M., Ankney, Richard, Salz, Richard, Titchener, Thomas, Lieberwirth, Peter, Konstantaras, Andrew, Claxton, Allen, MONTGOMERY, CHARLES T.
• Primary Examiner(s): Kazimi, Hani M.
• Application Number:
  US09/492,459
• Time in Patent Office: 2,574 Days
• Field of Search: 705/17, 705/44, 705/76, 705/64, 705/75, 705/78, 713/156, 707/9, 235/379, 235/380
• US Class Current: 705/44
• CPC Class Codes: G06Q 20/12 specially adapted for electronic shopping systems
• CPC Class Codes: G06Q 20/38215 Use of certificates or encrypted proofs of transaction rights
• 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/4016 involving fraud or risk level assessment in transaction processing
• CPC Class Codes: G06Q 30/02 Marketing; Price estimation or determination; Fundraising

Abstract

An electronic transaction system includes an authority issuing electronic signals representing subscriber assurance of an attribute of a subscriber to the system; and a reliance server obtaining electronic signals representing information regarding the subscriber assurance issued by the issuing authority, the reliance server issuing electronic signals representing a signed warranty offer to a relying party, the signed warranty offer being based at least on the subscriber attribute assurance, wherein the reliance server only provides the signed warranty offer if the relying party is authorized to make a request for said warranty.

Claims

1. An electronic transaction system comprising:

an authority issuing electronic signals representing subscriber assurance of an attribute of a subscriber to the system; and

a reliance server obtaining electronic signals representing information regarding the subscriber assurance issued by the issuing authority, the reliance server issuing electronic signals representing a signed warranty offer to a relying party, the signed warranty offer being based at least on the subscriber attribute assurance, wherein the reliance server only provides the signed warranty offer if the relying party is authorized to make a request for said warranty.

2. A system as in claim 1 wherein the reliance server uses a secure hardware device to sign the warranty.

3. A system as in claim 2 wherein the secure hardware device contains a key certified by a certification authority.

4. A system as in claim 1 wherein the reliance server bases a decision to sign the warranty offer on criteria including

(a) attributes of an issuing authority certificate,

(b) attributes concerning the issuing authority that are not contained in an issuing authority certificate, and

(c) attributes of the request for said warranty.

5. A system as in claim 1 wherein the reliance server bases a decision to sign the warranty offer on criteria which are defined through scripts.

6. A system as in claim 1 wherein the reliance server treats each request from a particular relying party independently of all other requests from the same relying party.

7. A system as in claim 1 wherein each request from a particular relying party includes information that allows the reliance server to determine the policy regarding issuance of a signed warranty offer.

8. A system as in claim 1 wherein the reliance server produces secure logs of all transactions.

9. A system as in claim 1 wherein the warranty being offered to a relying party is conditioned to be rolled back if the relying party does not accept the offer within a set time limit.

10. A system as in claim 1 wherein the issuing authority limits a level of warranty.

11. A system as in claim 10 wherein the issuing authority limits the level of warranty by setting overall limits for any transaction.

29. A system as in claim 5, wherein the scripts are configured under a secure administration process.

30. A system as in claim 10, wherein the level of warranty is configured to be given for each transaction.

12. A method of managing reliance in an electronic transaction system, the method comprising:

an issuing bank (IB) providing a transaction bearing liability (TBL) certificate to a subscriber;

the subscriber forming and signing a transaction, the signed transaction including information contained in the TBL certificate, and forwarding the signed transaction to a relying party;

the relying party forwarding an assurance request based on the transaction to a relying party bank;

the relying party bank issuing a signed warranty offer to the relying party, the signed warranty offer being based at least on information in the TBL certificate, wherein the relying party bank only provides the signed warranty offer if the relying party is authorized to make a request for said warranty.

13. A method as in claim 12 wherein the relying party bank uses a secure hardware device to sign the warranty.

14. A method as in claim 13 wherein the secure hardware device contains a key certified by a certification authority.

15. A method as in claim 12 wherein the relying party bank bases a decision to sign the warranty offer on criteria including

(a) attributes of the TBL certificate,

(b) attributes concerning the issuing bank that are not contained in a certificate, and

(c) attributes of the request for said warranty.

16. A method as in claim 12 wherein the relying party bank bases a decision to sign the warranty offer on criteria which are defined through scripts.

17. A method as in claim 12 wherein the relying party bank treats each request from a particular relying party independently of all other requests from the same relying party.

18. A method as in claim 12 wherein a request from a particular relying party includes information that allows the relying party bank to determine the policy regarding issuance of a signed warranty offer.

19. A method as in claim 12 further comprising:

the relying party bank producing secure logs of all functions.

20. A method as in claim 12 further comprising:

rolling back the warranty being offered to the relying party if the relying party does not accept the offer within a set time limit.

21. A method as in claim 12 further comprising:

the issuing bank limiting a level of warranty.

22. A method as in claim 21 wherein the issuing bank limits the level of warranty by setting overall limits for any transaction.

23. A method as in claim 12 wherein the relying party forwards the assurance request using an open network protocol.

24. A method as in claim 12 further comprising:

the relying parry bank verifying that the relying party is authorized to make the request, the verification being based on a relying party'"'"'s identity certificate and on attributes determined by the relying party bank.

25. A method as in claim 12 further comprising:

by the relying party bank, maintaining a warranty account to track warranties that have been issued for each relying party.

26. A method as in claim 12 further comprising:

by the relying party bank, maintaining a record of outstanding warranties that have been issued for a group of relying party accounts.

27. A method as in claim 12 further comprising:

by the relying party bank, providing alert messages when certain warranty thresholds have been reached.

28. A method as in claim 12 further comprising:

by the relying party bank, making requests for information from other systems to determine whether or not to issue the warranty offer.

31. A method as in claim 16, wherein the scripts are configured under a secure administration process.

32. A method as in claim 21, wherein the level of warranty is configured to be given for each transaction.

33. A method as in claim 24, wherein the verification based on attributes determined by the relying party bank is based on information requested by the relying party bank from other systems.