DETAILED ACTION
Acknowledgements
Claims 1-20 are pending.
Claims 1-20 have been examined.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 11,893,553 and 12,481,967. Although the claims at issue are not identical, they are not patentably distinct from each other because all the claims at issue are recited in claims 1-20 of U.S. Patent No. 11,938,553 and 12,481,967. See the claim comparison table below for detail.
19/393,820
US Patent No. 11,893,553
1. A method comprising:
storing, by one or more processing circuits, an encrypted digital asset on a first ledger;
receiving, by the one or more processing circuits, a signed exchange request signed by a first key corresponding with the encrypted digital asset on the first ledger;
determining, by the one or more processing circuits, the signed exchange request is verified, wherein the signed exchange request is verified using one or more cryptographic functions on a second ledger;
transferring, by the one or more processing circuits, the encrypted digital asset to the second ledger; and
updating, by the one or more processing circuits, a third ledger by interfacing with of the third ledger via an application programming interface (API) based on establishing a data feed;
wherein at least one of a plurality of fields of the encrypted digital asset is a universal field across the first, second, and third ledgers.
1. A computer-implemented method of exchanging digital assets using a public key cryptography (PKC) framework, the method comprising:
encrypting, by one or more processing circuits, a plurality of digital assets on an internal ledger using a public key of a public and private key pair;
storing, by the one or more processing circuits, the encrypted plurality of digital assets on the internal ledger;
receiving, by the one or more processing circuits, a signed exchange request signed by a private key of the public and private key pair associated with an encrypted digital asset on the internal ledger, wherein the signed exchange request comprises a destination address of an inter-provider ledger;
providing, by the one or more processing circuits to the inter-provider ledger, the public key of the public and private key pair based on interfacing with the destination address of the inter-provider ledger via a first application programming interface (API) based on establishing a first data feed;
determining, by the one or more processing circuits from the inter-provider ledger, the signed exchange request was verified, wherein the signed exchange request is verified using one or more cryptographic functions on the inter-provider ledger;
transferring, by the one or more processing circuits, the encrypted digital asset to the inter-provider ledger:
in response to determining that the signed exchange request was verified, updating, by the one or more processing circuits, the internal ledger by removing the public and private key pair; and
in response to determining that the signed exchange request was verified, updating, by the one or more processing circuits, a central ledger by interfacing with a central address of the central ledger via a second API based on establishing a second data feed;
wherein the encrypted digital asset comprises a plurality of fields that are ledger dependent,
wherein at least one of the plurality of fields is a universal field across the internal ledger, the inter-provider ledger, and the central ledger, and wherein at least one of the fields of the plurality fields is a unique field to the internal ledger.
2. The method of claim 1, wherein the plurality of fields comprises at least an assignee field.
2. The computer-implemented method of claim 1, wherein each encrypted digital asset of the encrypted plurality of digital assets comprises the plurality of fields, and wherein the plurality of fields comprises at least an assignee field.
3. The method of claim 2, wherein the assignee field comprises a read/write access level, and wherein the plurality of fields further comprises a trace field associated with a unique identifier and assigned a read access level.
3. The computer-implemented method of claim 2, wherein the assignee field has a read/write access level, and wherein the encrypted digital asset further comprises a trace field associated with a unique identifier .and assigned a read access level.
4. The method of claim 1, wherein the encrypted digital asset comprises a central bank digital currency (CBDC) issued by a central ledger, and wherein the CBDC is a digital form of a fiat currency of one or more nations, one or more countries, or one or more regions.
4. The computer-implemented method of claim 1, wherein the encrypted digital asset is a central bank digital currency (CBDC) issued by the central ledger, and wherein the CBDC is a digital form of a fiat currency of one or more nations, one or more countries, or one or more regions.
5. The method of claim 4, wherein the central ledger comprises a plurality of nodes each associated with one or more providers, and wherein a central address is unique to the one or more processing circuits, and wherein the one or more processing circuits comprises a read/write access level for updating the central ledger.
5. The computer-implemented method of claim 4, wherein the central ledger comprises a plurality of nodes each associated with one or more providers, and wherein the central address is unique to the one or more processing circuits, and wherein the one or more processing circuits comprises a read/write access level for updating the central ledger.
6. The method of claim 1, further comprising:
establishing, by the one or more processing circuits utilizing a different API, a first data feed associated with the signed exchange request; and
monitoring, by the one or more processing circuits, the first data feed comprising executing API calls with the different API, wherein the API calls return a verification status of the signed exchange request.
7. The computer-implemented method of claim 1, further comprising:
establishing, by the one or more processing circuits utilizing the first API, the first data feed associated with the signed exchange request; and
monitoring, by the one or more processing circuits, the first data feed comprising executing API calls with the API, wherein the API calls return a verification status of the signed exchange request.
7. The method of claim 1, wherein the internal ledger is operated by the one or more processing circuits, and wherein an inter-provider ledger comprises a plurality of nodes each associated with one or more providers.
8. The computer-implemented method of claim 1, wherein the internal ledger is operated by the one or more processing circuits, and wherein the inter-provider ledger comprises a plurality of nodes each associated with one or more providers.
8. The method of claim 7, wherein a source address associated with the one or more processing circuits is a first node of the plurality of nodes on the inter-provider ledger, and wherein a destination address is a second node of the plurality of nodes on the inter-provider ledger.
9. The computer-implemented method of claim 8, wherein a source address associated with the one or more processing circuits is a first node of the plurality of nodes on the inter-provider ledger, and wherein the destination address is a second node of the plurality of nodes on the inter-provider ledger.
9. A provider system comprising:
at least one processing circuit having at least one processor coupled to at least one memory, the at least one processing circuit configured to:
store an encrypted digital asset on a first ledger;
receive a signed exchange request signed by a first key corresponding with the encrypted digital asset on the first ledger;
determine the signed exchange request is verified, wherein the signed exchange request is verified using one or more cryptographic functions on a second ledger;
transfer the encrypted digital asset to the second ledger; and
update a third ledger by interfacing with of the third ledger via an application programming interface (API) based on establishing a data feed;
wherein at least one of a plurality of fields of the encrypted digital asset is a universal field across the first, second, and third ledgers.
10. A provider system comprising:
at least one processing circuit having at least one processor coupled to at least one memory, the at least one processing circuit configured to:
encrypt a plurality of digital assets on an internal ledger using a public key of a public and private key pair;
store the encrypted plurality of digital assets on the internal ledger;
receive a signed exchange request signed by a private key of the public and private key pair associated with an encrypted digital asset on the internal ledger, wherein the signed exchange request comprises a destination address of an inter-provider ledger;
provide, to the inter-provider ledger, the public key of the public and private key pair based on interfacing with the destination address of the inter-provider ledger via a first application programming interface (API) based on establishing a first data feed;
determine, from the inter-provider ledger, the signed exchange request was verified, wherein the signed exchange request is verified using one or more cryptographic functions on the inter-provider ledger;
transfer the encrypted digital asset to the inter-provider ledger;
in response to determining that the signed exchange request was verified, update the internal ledger by removing the public and private key pair; and
in response to determining that the signed exchange request was verified, update a central ledger by interfacing with a central address of the central ledger via a second API based on establishing a second data feed;
wherein the encrypted digital asset comprises a plurality of fields that are ledger dependent, wherein at least one of the plurality of fields is a universal field across the internal ledger, the inter-provider ledger, and the central ledger, and wherein at least one of the fields of the plurality fields is a unique field to the internal ledger.
10. The system of claim 9, wherein the plurality of fields comprises at least an assignee field.
11. The provider system of claim 10, wherein each encrypted digital asset of the encrypted plurality of digital assets comprises the plurality of fields, and wherein the plurality of fields comprises at least an assignee field.
11. The system of claim 10, wherein the assignee field comprises a read/write access level, and wherein the plurality of fields further comprises a trace field associated with a unique identifier and assigned a read access level.
12. The provider system of claim 11, wherein the assignee field has a read/write access level, and wherein the encrypted digital asset further comprises a trace field associated with a unique identifier and assigned a read access level.
12. The system of claim 9, wherein the encrypted digital asset comprises a central bank digital currency (CBDC) issued by a central ledger, and wherein the CBDC is a digital form of a fiat currency of one or more nations, one or more countries, or one or more regions.
13. The provider system of claim 10, wherein the encrypted digital asset is a central bank digital currency (CBDC) issued by the central ledger, and wherein the CBDC is a digital form of a fiat currency of one or more nations, one or more countries, or one or more regions.
13. The system of claim 12, wherein the central ledger comprises a plurality of nodes each associated with one or more providers, and wherein a central address is unique to the one or more processing circuits, and wherein the one or more processing circuits comprises a read/write access level for updating the central ledger.
14. The provider system of claim 13, wherein the central ledger comprises a plurality of nodes each associated with one or more providers, and wherein the central address is unique to the at least one processing circuit, and wherein the at least one processing circuit comprises a read/write access level for updating the central ledger.
14. The system of claim 1, the at least one processing circuit configured to:
establish, utilizing a different API, a first data feed associated with the signed exchange request; and
monitor the first data feed comprising executing API calls with the different API, wherein the API calls return a verification status of the signed exchange request.
16. The provider system of claim 10, wherein the at least one processing circuit is further configured to:
establish, utilizing the first API, the first data feed associated with the signed exchange request; and
monitor the first data feed comprising executing API calls with the API, wherein the API calls return a verification status of the signed exchange request.
15. The system of claim 1, wherein the internal ledger is operated by the one or more processing circuits, and wherein an inter-provider ledger comprises a plurality of nodes each associated with one or more providers.
17. The provider system of claim 10, wherein the internal ledger is operated by the at least one processing circuit, and wherein the inter-provider ledger comprises a plurality of nodes each associated with one or more providers.
16. The system of claim 15, wherein a source address associated with the one or more processing circuits is a first node of the plurality of nodes on the inter-provider ledger, and wherein a destination address is a second node of the plurality of nodes on the inter-provider ledger
18. The provider system of claim 17, wherein a source address associated with the at least one processing circuit is a first node of the plurality of nodes on the inter-provider ledger, and wherein the destination address is a second node of the plurality of nodes on the inter-provider ledger.
17. One or more non-transitory computer-readable storage media having instructions stored thereon that, when executed by at least one processing circuit, cause the at least one processing circuit to:
store an encrypted digital asset on a first ledger;
receive a signed exchange request signed by a first key corresponding with the encrypted digital asset on the first ledger;
determine the signed exchange request is verified, wherein the signed exchange request is verified using one or more cryptographic functions on a second ledger;
transfer the encrypted digital asset to the second ledger; and
update a third ledger by interfacing with of the third ledger via an application programming interface (API) based on establishing a data feed;
wherein at least one of a plurality of fields of the encrypted digital asset is a universal field across the first, second, and third ledgers.
19. One or more non-transitory computer-readable storage media having instructions stored thereon that, when executed by at least one processing circuit, cause the at least one processing circuit to:
encrypt a plurality of digital assets on an internal ledger using a public key of a public and private key pair;
store the encrypted plurality of digital assets on the internal ledger;
receive a signed exchange request signed by a private key of the public and private key pair associated with an encrypted digital asset on the internal ledger, wherein the signed exchange request comprises a destination address of an inter-provider ledger;
provide, to the inter-provider ledger, the public key of the public and private key pair based on interfacing with the destination address of the inter-provider ledger via a first application programming interface (API) based on establishing a first data feed;
determine, from the inter-provider ledger, the signed exchange request was verified, wherein the signed exchange request is verified using one or more cryptographic functions on the inter-provider ledger;
transfer the encrypted digital asset to the inter-provider ledger;
in response to determining that the signed exchange request was verified, update the internal ledger by removing the public and private key pair; and
in response to determining that the signed exchange request was verified, update a central ledger by interfacing with a central address of the central ledger via a second API based on establishing a second data feed;
wherein the encrypted digital asset comprises a plurality of fields that are ledger dependent,
wherein at least one of the plurality of fields is a universal field across the internal ledger, the inter-provider ledger, and the central ledger, and wherein at least one of the fields of the plurality fields is a unique field to the internal ledger.
18. The non-transitory computer-readable storage media of claim 17, wherein the plurality of fields comprises at least an assignee field; and
the assignee field comprises a read/write access level, and wherein the plurality of fields further comprises a trace field associated with a unique identifier and assigned a read access level
11. The provider system of claim 10, wherein each encrypted digital asset of the encrypted plurality of digital assets comprises the plurality of fields, and wherein the plurality of fields comprises at least an assignee field.
12. The provider system of claim 11, wherein the assignee field has a read/write access level, and wherein the encrypted digital asset further comprises a trace field associated with a unique identifier and assigned a read access level.
19. The non-transitory computer-readable storage media of claim 17, wherein the encrypted digital asset comprises a central bank digital currency (CBDC) issued by a central ledger, and wherein the CBDC is a digital form of a fiat currency of one or more nations, one or more countries, or one or more regions.
15. The provider system of claim 10, wherein the encrypted digital asset is a token derived from a central bank digital currency (CBDC) issued by the central ledger, and wherein the token is a digital form of a fiat currency of one or more nations, one or more countries, or one or more regions.
20. The non-transitory computer-readable storage media of claim 19, wherein the central ledger comprises a plurality of nodes each associated with one or more providers, and wherein a central address is unique to the one or more processing circuits, and wherein the one or more processing circuits comprises a read/write access level for updating the central ledger.
14. The provider system of claim 13, wherein the central ledger comprises a plurality of nodes each associated with one or more providers, and wherein the central address is unique to the at least one processing circuit, and wherein the at least one processing circuit comprises a read/write access level for updating the central ledger.
19/393,820
US Patent No. 12,481,967
1. A method comprising:
storing, by one or more processing circuits, an encrypted digital asset on a first ledger;
receiving, by the one or more processing circuits, a signed exchange request signed by a first key corresponding with the encrypted digital asset on the first ledger;
determining, by the one or more processing circuits, the signed exchange request is verified, wherein the signed exchange request is verified using one or more cryptographic functions on a second ledger;
transferring, by the one or more processing circuits, the encrypted digital asset to the second ledger; and
updating, by the one or more processing circuits, a third ledger by interfacing with of the third ledger via an application programming interface (API) based on establishing a data feed;
wherein at least one of a plurality of fields of the encrypted digital asset is a universal field across the first, second, and third ledgers.
1. A computer-implemented method of exchanging digital assets using a public key cryptography (PKC) framework, the computer-implemented method comprising:
encrypting, by one or more processing circuits, at least one digital asset on an internal ledger;
storing, by the one or more processing circuits, the encrypted at least one digital asset on the internal ledger;
receiving, by the one or more processing circuits, a signed exchange request signed by a first key corresponding with an encrypted digital asset on the internal ledger;
providing, by the one or more processing circuits to an inter-provider ledger, a second key based on interfacing with the inter-provider ledger based on establishing a first data feed;
determining, by the one or more processing circuits, the signed exchange request was verified, wherein the signed exchange request is verified using one or more cryptographic functions on the inter-provider ledger;
transferring, by the one or more processing circuits, the encrypted digital asset to the inter-provider ledger; and
updating, by the one or more processing circuits, a central ledger by interfacing with of the central ledger via an application programming interface (API) based on establishing a second data feed;
wherein at least one of a plurality of fields of the encrypted digital asset is a universal field across the internal ledger, the inter-provider ledger, and the central ledger.
2. The method of claim 1, wherein the plurality of fields comprises at least an assignee field.
2. The computer-implemented method of claim 1, wherein each encrypted digital asset of the encrypted at least one digital asset comprises the plurality of fields, and wherein the plurality of fields comprises at least an assignee field.
3. The method of claim 2, wherein the assignee field comprises a read/write access level, and wherein the plurality of fields further comprises a trace field associated with a unique identifier and assigned a read access level.
3. The computer-implemented method of claim 2, wherein the assignee field has a read/write access level, and wherein the encrypted digital asset further comprises a trace field associated with a unique identifier and assigned a read access level.
4. The method of claim 1, wherein the encrypted digital asset comprises a central bank digital currency (CBDC) issued by a central ledger, and wherein the CBDC is a digital form of a fiat currency of one or more nations, one or more countries, or one or more regions.
4. The computer-implemented method of claim 1, wherein the encrypted digital asset is a central bank digital currency (CBDC) issued by the central ledger, and wherein the CBDC is a digital form of a fiat currency of one or more nations, one or more countries, or one or more regions.
5. The method of claim 4, wherein the central ledger comprises a plurality of nodes each associated with one or more providers, and wherein a central address is unique to the one or more processing circuits, and wherein the one or more processing circuits comprises a read/write access level for updating the central ledger.
5. The computer-implemented method of claim 4, wherein the central ledger comprises a plurality of nodes each associated with one or more providers, and wherein a central address is unique to the one or more processing circuits, and wherein the one or more processing circuits comprises a read/write access level for updating the central ledger.
6. The method of claim 1, further comprising:
establishing, by the one or more processing circuits utilizing a different API, a first data feed associated with the signed exchange request; and
monitoring, by the one or more processing circuits, the first data feed comprising executing API calls with the different API, wherein the API calls return a verification status of the signed exchange request.
7. The computer-implemented method of claim 1, further comprising:
establishing, by the one or more processing circuits utilizing a different API, the first data feed associated with the signed exchange request; and
monitoring, by the one or more processing circuits, the first data feed comprising executing API calls with the different API, wherein the API calls return a verification status of the signed exchange request.
7. The method of claim 1, wherein the internal ledger is operated by the one or more processing circuits, and wherein an inter-provider ledger comprises a plurality of nodes each associated with one or more providers.
8. The computer-implemented method of claim 1, wherein the internal ledger is operated by the one or more processing circuits, and wherein the inter-provider ledger comprises a plurality of nodes each associated with one or more providers.
8. The method of claim 7, wherein a source address associated with the one or more processing circuits is a first node of the plurality of nodes on the inter-provider ledger, and wherein a destination address is a second node of the plurality of nodes on the inter-provider ledger.
9. The computer-implemented method of claim 8, wherein a source address associated with the one or more processing circuits is a first node of the plurality of nodes on the inter-provider ledger, and wherein a destination address is a second node of the plurality of nodes on the inter-provider ledger.
9. A provider system comprising:
at least one processing circuit having at least one processor coupled to at least one memory, the at least one processing circuit configured to:
store an encrypted digital asset on a first ledger;
receive a signed exchange request signed by a first key corresponding with the encrypted digital asset on the first ledger;
determine the signed exchange request is verified, wherein the signed exchange request is verified using one or more cryptographic functions on a second ledger;
transfer the encrypted digital asset to the second ledger; and
update a third ledger by interfacing with of the third ledger via an application programming interface (API) based on establishing a data feed;
wherein at least one of a plurality of fields of the encrypted digital asset is a universal field across the first, second, and third ledgers.
10. A provider system comprising:
at least one processing circuit having at least one processor coupled to at least one memory, the at least one processing circuit configured to:
encrypt at least one digital asset on an internal ledger;
store the encrypted at least one digital asset on the internal ledger;
receive a signed exchange request signed by a first key corresponding with an encrypted digital asset on the internal ledger;
provide, to an inter-provider ledger, a second key based on interfacing with the inter-provider ledger based on establishing a first data feed;
determine the signed exchange request was verified, wherein the signed exchange request is verified using one or more cryptographic functions on the inter-provider ledger;
transfer the encrypted digital asset to the inter-provider ledger; and
update a central ledger by interfacing with the central ledger via an application programming interface (API) based on establishing a second data feed;
wherein at least one of a plurality of fields of the encrypted digital asset is a universal field across the internal ledger, the inter-provider ledger, and the central ledger.
10. The system of claim 9, wherein the plurality of fields comprises at least an assignee field.
11. The provider system of claim 10, wherein each encrypted digital asset of the encrypted at least one digital asset comprises the plurality of fields, and wherein the plurality of fields comprises at least an assignee field.
11. The system of claim 10, wherein the assignee field comprises a read/write access level, and wherein the plurality of fields further comprises a trace field associated with a unique identifier and assigned a read access level.
12. The provider system of claim 11, wherein the assignee field has a read/write access level, and wherein the encrypted digital asset further comprises a trace field associated with a unique identifier and assigned a read access level.
12. The system of claim 9, wherein the encrypted digital asset comprises a central bank digital currency (CBDC) issued by a central ledger, and wherein the CBDC is a digital form of a fiat currency of one or more nations, one or more countries, or one or more regions.
13. The provider system of claim 10, wherein the encrypted digital asset is a central bank digital currency (CBDC) issued by the central ledger, and wherein the CBDC is a digital form of a fiat currency of one or more nations, one or more countries, or one or more regions.
13. The system of claim 12, wherein the central ledger comprises a plurality of nodes each associated with one or more providers, and wherein a central address is unique to the one or more processing circuits, and wherein the one or more processing circuits comprises a read/write access level for updating the central ledger.
14. The provider system of claim 13, wherein the central ledger comprises a plurality of nodes each associated with one or more providers, and wherein a central address is unique to the at least one processing circuit, and wherein the at least one processing circuit comprises a read/write access level for updating the central ledger.
14. The system of claim 1, the at least one processing circuit configured to:
establish, utilizing a different API, a first data feed associated with the signed exchange request; and
monitor the first data feed comprising executing API calls with the different API, wherein the API calls return a verification status of the signed exchange request.
16. The provider system of claim 10, wherein the at least one processing circuit is further configured to:
establish, utilizing a different API, the first data feed associated with the signed exchange request; and
monitor the first data feed comprising executing API calls with the different API, wherein the API calls return a verification status of the signed exchange request.
15. The system of claim 1, wherein the internal ledger is operated by the one or more processing circuits, and wherein an inter-provider ledger comprises a plurality of nodes each associated with one or more providers.
17. The provider system of claim 10, wherein the internal ledger is operated by the at least one processing circuit, and wherein the inter-provider ledger comprises a plurality of nodes each associated with one or more providers.
16. The system of claim 15, wherein a source address associated with the one or more processing circuits is a first node of the plurality of nodes on the inter-provider ledger, and wherein a destination address is a second node of the plurality of nodes on the inter-provider ledger
18. The provider system of claim 17, wherein a source address associated with the at least one processing circuit is a first node of the plurality of nodes on the inter-provider ledger, and wherein a destination address is a second node of the plurality of nodes on the inter-provider ledger.
17. One or more non-transitory computer-readable storage media having instructions stored thereon that, when executed by at least one processing circuit, cause the at least one processing circuit to:
store an encrypted digital asset on a first ledger;
receive a signed exchange request signed by a first key corresponding with the encrypted digital asset on the first ledger;
determine the signed exchange request is verified, wherein the signed exchange request is verified using one or more cryptographic functions on a second ledger;
transfer the encrypted digital asset to the second ledger; and
update a third ledger by interfacing with of the third ledger via an application programming interface (API) based on establishing a data feed;
wherein at least one of a plurality of fields of the encrypted digital asset is a universal field across the first, second, and third ledgers.
19. One or more non-transitory computer-readable storage media having instructions stored thereon that, when executed by at least one processing circuit, cause the at least one processing circuit to:
encrypt at least one digital asset on an internal ledger;
store the encrypted at least one digital asset on the internal ledger;
receive a signed exchange request signed by a first key corresponding with an encrypted digital asset on the internal ledger;
provide, to an inter-provider ledger, a second key based on interfacing with the inter-provider ledger based on establishing a first data feed;
determine the signed exchange request was verified, wherein the signed exchange request is verified using one or more cryptographic functions on the inter-provider ledger;
transfer the encrypted digital asset to the inter-provider ledger; and
update a central ledger by interfacing with the central ledger via an application programming interface (API) based on establishing a second data feed;
wherein at least one of a plurality of fields of the encrypted digital asset is a universal field across the internal ledger, the inter-provider ledger, and the central ledger.
18. The non-transitory computer-readable storage media of claim 17, wherein the plurality of fields comprises at least an assignee field; and
the assignee field comprises a read/write access level, and wherein the plurality of fields further comprises a trace field associated with a unique identifier and assigned a read access level
11. The provider system of claim 10, wherein each encrypted digital asset of the encrypted at least one digital asset comprises the plurality of fields, and wherein the plurality of fields comprises at least an assignee field.
12. The provider system of claim 11, wherein the assignee field has a read/write access level, and wherein the encrypted digital asset further comprises a trace field associated with a unique identifier and assigned a read access level.
19. The non-transitory computer-readable storage media of claim 17, wherein the encrypted digital asset comprises a central bank digital currency (CBDC) issued by a central ledger, and wherein the CBDC is a digital form of a fiat currency of one or more nations, one or more countries, or one or more regions.
15. The provider system of claim 10, wherein the encrypted digital asset is a token derived from a central bank digital currency (CBDC) issued by the central ledger, and wherein the token is a digital form of a fiat currency of one or more nations, one or more countries, or one or more regions.
20. The non-transitory computer-readable storage media of claim 19, wherein the central ledger comprises a plurality of nodes each associated with one or more providers, and wherein a central address is unique to the one or more processing circuits, and wherein the one or more processing circuits comprises a read/write access level for updating the central ledger.
14. The provider system of claim 13, wherein the central ledger comprises a plurality of nodes each associated with one or more providers, and wherein a central address is unique to the at least one processing circuit, and wherein the at least one processing circuit comprises a read/write access level for updating the central ledger.
Claim Rejections - 35 USC §101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Analysis
In the instant case, claims 1-8 are directed to a method, claims 9-16 are directed to a system, and 17-20 are directed to a CRM. Therefore, these claims fall within the four statutory categories of invention.
The claim(s) recite(s) processing asset exchange transaction. Specifically, the claims recite “storing, by one or more [processing circuits], an encrypted digital asset on a [first ledger]; receiving, by the one or more [processing circuits], a signed exchange request signed by a first key corresponding with the encrypted digital asset on the [first ledger]; determining, by the one or more [processing circuits], the signed exchange request is verified, wherein the signed exchange request is verified using one or more [cryptographic functions] on a [second ledger]; transferring, by the one or more [processing circuits], the encrypted digital asset to the [second ledger]; and updating, by the one or more [processing circuits], a [third ledger] by interfacing with of the [third ledger] via an [application programming interface (API)] based on establishing a data feed; wherein at least one of a plurality of fields of the encrypted digital asset is a universal field across the [first, second, and third ledgers].”, which is “commercial or legal interactions” within the “certain methods of organizing human activity” grouping of abstract ideas in prong one of step 2A of the Alice/Mayo test (See MPEP 2106) because the claims involve a series of steps for processing asset exchange transaction. Accordingly, the claims recite an abstract idea.
Additionally, the claims recite cryptographic operations “...using one or more cryptographic functions on a second ledger;” which is the abstract idea of a mathematical concept. See MPEP 2106. Therefore, the claims recite an abstract idea, as it has been held that a combination of abstract ideas, in this case organizing human activity and a mathematical concept, is still an abstract idea. See FairWarning IP, LLC v. Iatric Sys., Inc., 839 F.3d 1089, 1093-94 (Fed. Cir. 2016).
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A of the Alice/Mayo test (See MPEP 2106), the additional element(s) of the claim(s) such as the use of processing circuits, first ledger, second ledger, third ledger, API, processor, memory and storage media merely use(s) a computer as a tool to perform an abstract idea. The processors and memories are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function of processing asset exchange transaction) such that it amounts no more than mere instructions to apply the exception using a generic computer components. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claims are directed to an abstract idea.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using processing circuits, first ledger, second ledger, third ledger, API, processor, memory and storage media steps amounts to no more than mere instructions to apply the exception using a generic computer components. Mere instructions to apply an exception using a generic computer components cannot provide an inventive concept. The claim is not patent eligible.
Dependent claims 2-3, 10-11 and 18 describe fields. Dependent claims 4, 12 and 19 describe encrypted digital asset. Dependent claims 5, 13 and 20 describe central ledger. Dependent claims 6 and 14 describe first data feed. Dependent claims 7 and 15 describe internal ledger. Dependent claims 8 and 16 describe source address and destination address in asset exchange transaction. These claims further recite the abstract idea of certain methods of organizing human activity and a mathematical concept. This judicial exception is not integrated into a practical application because the additional element(s) of the claim(s) such as the use of processing circuits, first ledger, second ledger, third ledger, API, processor, memory and storage media merely use(s) a computer as a tool to perform an abstract idea. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. The claims are not patent eligible.
Viewed as a whole, the combination of elements recited in the claims simply recite the concept of processing asset exchange transaction. The claims do not, for example, purport to improve the functioning of the computer itself. Nor do they effect an improvement in any other technology or technical field.
The use of processing circuits, first ledger, second ledger, third ledger, API, processor, memory and storage media as tools to implement the abstract idea does not render the claim patent eligible because it does not provide meaningful limitations beyond generally linking the use of an abstract idea to a particular technological environment and requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 7-8 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Insufficient Antecedent Basis
Claim 7 recites the limitation “wherein the internal ledger is operated by the one or more processing circuits, …” in line 1. There is insufficient antecedent basis for this limitation in the claim.
Dependent Claim 8 is also rejected as it depends from claim 7.
Allowable Subject Matter
Claims 1-20 would be allowable if the 101, 112b and double patent rejection, set forth in this Office action, are overcome. The closest prior art of US20210073913A1 (“Ingargiola”) disclose storing, by the one or more processing circuits, the encrypted digital asset on a first ledger; (Fig. 9 item 906, ¶0166); receiving, by the one or more processing circuits, a signed exchange request signed by a first key corresponding with the encrypted digital asset on the first ledger; (Fig. 9 item 908, ¶0166); determining, by the one or more processing circuits, a signed exchange request is verified, (Fig. 9 item 910, ¶0166) transferring, by the one or more processing circuits, the encrypted digital asset to the second ledger; (Fig. 9 item 912, ¶0111 and ¶0167). However, the prior art does not teach wherein the signed exchange request is verified using one or more cryptographic functions on a second ledger; updating, by the one or more processing circuits, a third ledger by interfacing with of the third ledger via an application programming interface (API) based on establishing a data feed; wherein at least one of a plurality of fields of the encrypted digital asset is a universal field across the first, second, and third ledgers.
Conclusion
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US20210073913A1 (“Ingargiola”) discloses systems and methods that utilize multiple single asset types and blockchain-based ledgers utilized by a custodian to issue a digital representation of assets held by the custodian. Trading entities place, with the custodian, respective assets that are represented on the ledgers. Genesis blocks on each blockchain-based ledger are signed by the exchange network which provides the initial trust and acts as a barricade against a rogue node from entering the network. Trading entities use the exchange network to agree on a price and enter into trades. The trades can include one asset type for another asset type. An atomic exchange is performed, and a trade is complete. Changes to token ownership are recorded on respective custodian ledgers automatically and redemption occurs upon request by a trading entity such that the ledger can be updated in actual currency and moved from the custodian to a trading entity account.
US20200334668A1(“Nicli et al.”) discloses a method and system of controlling by a control authority emission or destruction of digital assets from a request received by an accredited ledger, so that the control authority can access to the ledger for reading data stored therein. The request may relate to transfer registration of digital asset towards an account or between two accounts. Requests include stamp time and store and updated balance. In particular, the ledger registers the transfer according to the received request by updating balances only in case the updated digital account balance of the account to be debited is positive..
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YINGYING ZHOU whose telephone number is (571)272-5308. The examiner can normally be reached 9-5.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, John W Hayes can be reached on 571-272-6708. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/YINGYING ZHOU/Primary Examiner, Art Unit 3697
Prosecution Insights