Functional data for use in one or more digital transactions are secured by using an encapsulated security token (EST). In certain embodiments, the EST is created by encapsulating digital data including the functional data using at least two cryptographic systems of two parties. The encapsulation and subsequent de-encapsulation can utilize cryptographic systems of the parties that involve a private key for signing and decryption and a public key for encryption and signature verification. If constructed carefully over a series of rigorous events, the resulting EST can be practically impossible to counterfeit. In addition, a propagation of rights can be tracked for auditing and rights can be easily terminated or modified.
Legal claims defining the scope of protection, as filed with the USPTO.
1. A method of authenticating electronic credentials using an encapsulated cryptographic token associated with multiple digital signatures, the method comprising the steps of: (a) generating, with a cryptographic computer system, an encapsulated cryptographic token associated with multiple digital signatures by: providing a private key and a public key of an originator, wherein the private key and the public key of the originator are cryptographically associated such that data encrypted with the public key of the originator can be decrypted with the private key of the originator and data signed with the private key of the originator can be validated with the public key of the originator; providing a private key and a public key of a first propagatee, wherein the private key and the public key of the first propagatee are cryptographically associated such that data encrypted with the public key of the first propagatee can be decrypted with the private key of the first propagatee and data signed with the private key of the first propagatee can be validated with the public key of the first propagatee; generating a first cryptographic token by digitally signing the combination of: (1) credential data of the originator and (2) identity data of the first propagatee with the cryptographic computer system using the private key of the originator, wherein the first cryptographic token is tagged with the public key of the originator; generating a second cryptographic token that encapsulates the first cryptographic token by digitally signing the combination of: (1) the first cryptographic token and (2) identity data of a second propagatee with the cryptographic computer system using the private key of the first propagatee, wherein the second cryptographic token is tagged with the public key of the first propagatee; (b) validating authenticity of an entity attempting to use the credential data of the originator with the second cryptographic token by: receiving identity data of the entity attempting to use the second cryptographic token; validating, with the cryptographic computer system, whether the first propagatee signed the second cryptographic token using the public key of the first propagatee; validating, with the cryptographic computer system, the identity data of the entity attempting to use the second cryptographic token by comparing the identity data of the entity attempting to use the second cryptographic token with the identity of the second propagatee in the second cryptographic token to determine whether there is a match; validating, with the cryptographic computer system, whether the originator signed the first cryptographic token encapsulated in the second cryptographic token using the public key of the originator; validating, with the cryptographic computer system, the identity data of the first propagatee by comparing the public key of the first propagatee with the identity of the first propagatee in the first cryptographic token to determine whether there is a match; responsive to validating authenticity of the entity attempting to use the credentials of the originator with the second cryptographic token, allowing usage of credential data of the originator; and responsive to determining the entity attempting to use the credentials of the originator with the second cryptographic token is not authentic, denying usage of the credential data of the originator.
2. The method of claim 1 , wherein the originator comprises an application executing on a computing device that requires a cryptographic token for one or more functions of the application, wherein the application generates a first level cryptographic token when establishing a new user by signing the combination of: (1) login credentials of the new user; and (2) identity data of the new user using a private key associated with the application, wherein the first level cryptographic token is tagged with a public key associated with the application.
3. The method of claim 2 , further comprising the step of generating a second level cryptographic token that encapsulates the first level cryptographic token generated by the application by digitally signing the combination of: (1) the first level cryptographic token generated by the application and (2) identity data of a second user with the cryptographic computer system using a private key of the new user, wherein the second level cryptographic token is tagged with a public key of the new user.
4. The method of claim 3 , wherein the application validates use of the new user's login credentials by an entity attempting to use the second level cryptographic token by: receiving identity data of the entity attempting to use the second level cryptographic token; validating, with the cryptographic computer system, whether the new user signed the second level cryptographic token using the public key of the new user; validating, with the cryptographic computer system, the identity data of the entity attempting to use new user's login credentials by comparing the identity data of the entity attempting to use the second level cryptographic token with the identity of the second user in the second level cryptographic token to determine whether there is a match; validating, with the cryptographic computer system, whether the application signed the first level cryptographic token encapsulated in the second level cryptographic token using the public key of the application; validating, with the cryptographic computer system, the identity data of the new user by comparing the public key of the new user with the identity of the new user in the first level cryptographic token to determine whether there is a match; responsive to validating authenticity of the entity attempting to use the login credentials of the new user with the second level cryptographic token, allowing usage of new user's credentials; and responsive to determining the second user attempting to use the login credentials of the new user with the second level cryptographic token is not authentic, denying use of the new user's login credentials.
5. The method of claim 4 , further comprising generating a third level cryptographic token that encapsulates the first level cryptographic token and the second level cryptographic token by digitally signing the combination of: (1) the second level cryptographic token and (2) identity data of a third user with the cryptographic computer system using a private key of the second user, wherein the third level cryptographic token is tagged with a public key of the second user.
6. The method of claim 5 , wherein the application validates use of the new user's login credentials by an entity attempting to use the third level cryptographic token by: receiving identity data of the third user attempting to use the third level cryptographic token; validating, with the cryptographic computer system, whether the second user signed the third level cryptographic token using the public key of the second user; validating, with the cryptographic computer system, the identity data of the entity attempting to use the new user's login credentials by comparing the identity data of the entity attempting to use the third level cryptographic token with the identity data of the third user in the third level cryptographic token to determine whether there is a match; validating, with the cryptographic computer system, whether the new user signed the second level cryptographic token encapsulated in the third level cryptographic token using the public key of the new user; validating, with the cryptographic computer system, whether the application signed the first level cryptographic token encapsulated in the second level cryptographic token using the public key of the application; validating, with the cryptographic computer system, the identity data of the new user by comparing the public key of the new user with the identity data of the new user in the first level cryptographic token to determine whether there is a match; responsive to validating authenticity of the entity attempting to use the login credentials of the new user with the third level cryptographic token, allowing usage of new user's login credentials; and responsive to determining the entity attempting to use the credentials of the new user with the third level cryptographic token is not authentic, denying access to use the new user's login credentials.
7. The method of claim 6 , wherein creation of the second level cryptographic token and/or the third level cryptographic token includes propagation credentials encapsulated therein that is representative of whether the second user and/or the third user is allowed to propagate the new user's login credentials.
8. The method of claim 7 , wherein the application is configured to evaluate propagation credentials encapsulated in the second level cryptographic token and/or the third level cryptographic token.
9. The method of claim 8 , wherein the application is configured to deny access to the third user based on the propagation credentials indicating the second user is prohibited from propagating the new user's login credentials even where the application validates authentication of the third level cryptographic token using the public key of the second user.
10. The method of claim 9 , wherein the application is configured to deny access to the second user and the third user using the login credentials of the new user responsive to the new user invalidating the second level cryptographic token.
11. The method of claim 1 , wherein the originator comprises a mail server configured to send and receive email messages, wherein the mail server is configured to require the combination of (1) an email address and (2) a cryptographic token corresponding to the email address to send an email to the email address, wherein the mail server creates a first level cryptographic token when creating a new email address of a first user by signing the combination of: (1) the first user's email address; and (2) identity data of the first user with a private key associated with the mail server, wherein the first level cryptographic token is tagged with a public key associated with the mail server.
12. The method of claim 11 , further comprising generating a second level cryptographic token that encapsulates the first level cryptographic token created by the mail server by digitally signing the combination of: (1) the first level cryptographic token created by the mail server and (2) identification data of the second user, including an email address of the second user, with the cryptographic computer system using a private key of the first user, wherein the second level cryptographic token is tagged with a public key of the first user.
13. The method of claim 12 , wherein the mail server is configured to determine whether to deliver an email sent to the first user's email address by: receiving an email addressed to the first user that does not include a cryptographic token; evaluating whether the email includes a cryptographic token; denying delivery of the email responsive to determining that the email does not include a cryptographic token.
14. The method of claim 12 , wherein the mail server is configured to determine whether to deliver an email sent to the first user's email address by: receiving an email addressed to the first user that includes a cryptographic token; validating, with the cryptographic computer system, whether the first user signed the cryptographic token included with the email using the public key of the first user; validating, with the cryptographic computer system, whether sender data in the email matches the email address of the second user in the second level cryptographic token; validating, with the cryptographic computer system, the mail server signed the first level cryptographic token encapsulated in the second level cryptographic token using the public key of the mail server; validating, with the cryptographic computer system, the identity data of the first user by comparing the public key of the first user with the identity data of the first user in the first level cryptographic token to determine whether there is a match; responsive to validating authenticity of the cryptographic token included with the email, delivering the email to the first user's email address; and responsive to determining the cryptographic token included with the email is not authentic, reject delivery of the email.
15. The method of claim 14 , wherein creation of the second level cryptographic token includes propagation credentials encapsulated therein that is representative of whether the second user is allowed to propagate the first user's email address.
16. The method of claim 15 , wherein the application is configured to evaluate propagation credentials encapsulated in the second level cryptographic token to deny delivery of email from a user to whom the second user propagated the first user's email address.
17. The method of claim 1 , wherein the originator comprises a computerized telephone service configured to route telephone calls over a network, wherein the telephone service is configured to require the combination of (1) a telephone number and (2) a cryptographic token corresponding to the telephone number to connect a call with the telephone number, wherein the telephone service creates a first level cryptographic token when creating a new telephone number of a first user by signing the combination of (1) the first user's telephone number; and (2) identity data of the first user with a private key associated with the telephone service, wherein the first level cryptographic token is tagged with a public key associated with the telephone service.
18. The method of claim 17 , wherein the first user propagates the first user's telephone number to a second user by creating a second level cryptographic token that encapsulates the first level cryptographic token created by the telephone service by digitally signing the combination of: (1) the first level cryptographic token created by the telephone service and (2) a telephone number of the second user with the cryptographic computer system using a private key of the first user, wherein the second level cryptographic token is tagged with a public key of the first user.
19. The method of claim 18 , wherein the telephone service is configured to determine whether to connect a call with the first user's telephone number by: receiving a call request to the first user's telephone number that does not include a cryptographic token; evaluating whether the call request includes a cryptographic token; denying connection responsive to determining that the call request does not include a cryptographic token.
20. The method of claim 19 , wherein the telephone service is configured to determine whether to connect a call to the first user's telephone number by: receiving a call request to the first user's telephone number that includes a cryptographic token; validating, with the cryptographic computer system, whether the first user signed the cryptographic token included with the call request using the public key of the first user; validating, with the cryptographic computer system, whether sender data in the call request matches the telephone number of the second user in the second level cryptographic token; validating, with the cryptographic computer system, the telephone service signed the first level cryptographic token encapsulated in the second level cryptographic token using the public key of the telephone service; validating, with the cryptographic computer system, the identity data of the first user by comparing the public key of the first user with the identity data of the first user in the first level cryptographic token to determine whether there is a match; responsive to validating authenticity of cryptographic token included with the call request, connecting the call request with the first user's telephone number; and responsive to determining the cryptographic token included with the call request is not authentic, reject connection to the first user's telephone number.
21. The method of claim 1 , wherein the originator comprises an owner of a financial account seeking to initiate one or more financial transactions regarding the financial account, wherein the owner creates a first level cryptographic token by signing the combination of: (1) credentials of the financial account and (2) identity of a financial institution to initiate the one or more financial transactions with a private key associated with the owner, wherein the first level cryptographic token is tagged with a public key associated with the owner.
22. The method of claim 21 , further comprising creating a second level cryptographic token that encapsulates the first level cryptographic token created by the owner by digitally signing the combination of: (1) the first level cryptographic token created by the owner and (2) identity data of a wire settlement system with the cryptographic computer system using a private key of the financial institution authorized to initiate one or more transactions on the financial account, wherein the second level cryptographic token is tagged with a public key of the financial institution authorized to initiate one or more transactions on the financial account.
23. The method of claim 22 , wherein the wire settlement system validates use of the credentials of the financial account using the second level cryptographic token prior to sending a message with settlement instructions by: receiving identity data of an entity attempting to use the second level cryptographic token; validating, with the cryptographic computer system, whether the financial institution authorized to initiate one or more transactions on the financial account signed the second level cryptographic token using the public key of the financial institution authorized to initiate one or more transactions on the financial account; validating, with the cryptographic computer system, the identity data of the entity attempting to use the account credentials by comparing the identity data of the entity attempting to use the second level cryptographic token with the identity data of the wire settlement system in the second level cryptographic token to determine whether there is a match; validating, with the cryptographic computer system, whether the owner of the financial account signed the first level cryptographic token encapsulated in the second level cryptographic token using the public key of the owner; validating, with the cryptographic computer system, the identity data of the financial institution by comparing the public key of the financial institution with the identity data of the financial institution in the first level cryptographic token to determine whether there is a match; responsive to validating authenticity of the entity attempting to use the account credentials with the second level cryptographic token, sending a message with settlement instructions to perform one or more financial transactions on the financial account; and responsive to determining the entity attempting to use the account credentials with the second level cryptographic token is not authentic, denying sending settlement instructions on the financial account.
24. The method of claim 23 , wherein creation of the second level cryptographic token includes propagation credentials encapsulated therein that is representative of whether the wire settlement system is allowed to propagate the account credentials.
25. The method of claim 24 , wherein creation of the first level cryptographic token and/or the second level cryptographic token includes a wire instruction restriction encapsulated therein that is representative of one or more restrictions in wire instructions regarding the financial account, wherein the wire settlement system is configured to evaluate a proposed settlement instruction to determine whether the proposed settlement instruction includes the restriction, and if so, deny sending a message with the proposed settlement instructions.
26. The method of claim 25 , wherein the restriction is a maximum monetary value for the wire instructions and wherein the wire settlement system is configured to evaluate the proposed settlement instructions to determine whether the proposed settlement instructions exceed the maximum monetary value, and if so, deny sending a message with the proposed settlement instructions.
27. The method of claim 25 , wherein the restriction is a destination bank account for the wire instructions and wherein the wire settlement system is configured to evaluate the proposed settlement instructions to determine whether the proposed settlement instructions include a proposed destination bank account that does not match the destination bank account, and if so, deny sending a message with the proposed settlement instructions.
28. The method of claim 27 , wherein the first level cryptographic token includes a first restriction on wire instructions and the second level cryptographic token includes a second restriction on wire instructions, wherein the wire settlement system is configured to evaluate a proposed settlement instruction to determine whether the proposed settlement instruction includes either the first restriction or the second restriction, and if so, deny sending a message with the proposed settlement instructions.
29. The method of claim 28 , wherein the first restriction limits the destination bank account.
30. The method of claim 29 , wherein the second restriction limits the proposed settlement instruction to the benefit of a specific trading account.
31. A method of automating electronic fund transfer using an encapsulated cryptographic token associated with multiple digital signatures, the method comprising the steps of: (a) receiving, at a computer system on a network, a fund transfer request from an entity attempting to transfer funds, the fund transfer request comprising: (1) identity data of the entity attempting to transfer funds; (2) an encapsulated cryptographic token; (3) a proposed source account from which funds are to be removed; and (4) a proposed destination account to which funds are to be transferred, wherein the encapsulated cryptographic token comprises: (1) a first level cryptographic token comprising the combination of: (a) identifying data of an authorized source financial account of a first entity; (b) identity data of the first entity; and (c) identity data of a financial institution that administers the first entity's authorized source financial account digitally signed with a private key associated with the financial institution, wherein the first level cryptographic token is tagged with a public key associated with the financial institution; (2) a second level cryptographic token comprising the combination of: (a) the first level cryptographic token; (b) identity data of a second entity; (c) identity data of an authorized destination financial account digitally signed with a private key associated with the first entity, wherein the second level cryptographic token is tagged with a public key associated with the first entity; and (b) validating, by the computer system, authenticity of the fund transfer request by: (1) validating whether the first entity signed the second level cryptographic token using the public key of the first entity; (2) validating the identity data of the entity attempting to transfer funds by comparing the identity data of the entity attempting to transfer funds with the identity data of the second entity in the second level cryptographic token to verify there is a match; (3) validating the proposed destination account by comparing the identity data of the authorized destination account in the second level cryptographic token with the proposed destination account to verify there is a match; (4) validating whether the financial institution signed the first level cryptographic token using the public key of the financial institution; (5) validating the identity data of the first entity by comparing the public key of the first entity with the identity data of the first entity in the first level cryptographic token to verify there is a match; and (6) validating the proposed source account by comparing the identity data of the authorized source account in the first level cryptographic token with the proposed source account to verify there is a match; (c) responsive to validating authenticity of the fund transfer request in each of the validating steps (1)-(6), forwarding the electronic fund transfer request to the financial institution to transfer funds from the authorized source account to the authorized destination account; and (d) responsive to failing one or more of the validating steps (1)-(6), denying the fund transfer request.
32. The method of claim 31 , wherein the funds transfer request includes a proposed trading account for which the funds will settle a purchase transaction, and wherein the encapsulated cryptographic token includes a third level cryptographic token comprising the combination of: (a) the second level cryptographic token; (b) identity data of a third entity; (c) identity data of an authorized trading account digitally signed with a private key associated with the second entity, wherein the third level cryptographic token is tagged with a public key associated with the second entity.
33. The method of claim 32 , wherein the step of the authenticity of the funds transfer request includes: (1) validating whether the second entity signed the third level cryptographic token using the public key of the second entity; (2) validating the identity data of the entity attempting to transfer funds by comparing the identity data of the entity attempting to transfer funds with the identity data of the third entity in the third level cryptographic token to verify there is a match; and (3) validating the proposed trading account by comparing the identity data of the authorized trading account in the third level cryptographic token with the proposed trading account to verify there is a match.
34. The method of claim 33 , wherein the fund transfer request is denied if any of the validating steps regarding the third level cryptographic token fail.
Cooperative Patent Classification codes for this invention. Click any code to explore related patents in that topic.
March 5, 2018
July 7, 2020
Browse 5M+ US patents with plain-English claim translations and AI-generated analysis.