DETAILED ACTION
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 .
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.
2. Claims 14-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Independent claim 14 recites a series of steps and therefore, is a process. As such, claim 14 is one of the statutory categories. The claim recites “determining, by the first self-validating digital record, that a first validation requirement is met, wherein the first self-validating digital record and the first validation requirement are complied at the first off-chain server in response to determining that the first validation requirement is met; and confirming, by the cross-network registry, transfer of the first off-chain record to the second entity by creating the first self-validating digital record on a first cryptographically secure network” which is merely a concept can be performed in the human mind. Human mind through observation can perform the determining and confirming steps. These limitations, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components. Thus, the claim recites a mental process and are directed to a judicial exception.
This judicial exception is not integrated into a practical application because the claim recites the additional element: “receiving, at a cross-network registry, a first self-validating digital record, wherein the first self-validating digital record is validated by: receiving, at a first off-chain server, the first self-validating digital record from a first entity, wherein the first self-validating digital record corresponds to a first off-chain record designated by the first entity to be transferred to a second entity”, which indicates using the internet to gather data. As such, this limitation amounts to mere data gathering in conjunction with a law of nature or abstract idea that the courts have found to be insignificant extra-solution activity. See MPEP 2106.05(g). Use of a computer or other machinery in its ordinary capacity for economic or other tasks or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone); TLI Communications LLC v. AV Auto, LLC, 823 F.3d 607, 613, 118 USPQ2d 1744, 1748 (Fed. Cir. 2016) (computer server and telephone unit). See MPEP 2106.05(f). The addition of insignificant extra-solution activity does not amount to an inventive concept. Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. See MPEP 2016.05(h).
As discussed with respect to Step 2A Prong Two, the additional elements in the claim amount to no more than mere instructions to apply the exception using a generic computer component. The same analysis applies here in 2B, i.e., mere instructions to apply an exception using a generic computer component cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. Thus, the claim 14 is ineligible.
Regarding claims 15-20, claims further recite the limitations which further recite mental processes and are directed to perform mental processes that fall into the “Mental Processes” groupings of abstract ideas and are directed to a judicial exception. Furthermore, claims include no additional elements that would integrate the judicial exception into a practical application or would amount to significantly more than the abstract idea. Thus, the claims are ineligible.
Double Patenting
3. 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 § 2146 et seq. 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 filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual 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/apply/applying-online/eterminal-disclaimer.
4. Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 12277109. The subject matter claimed in the instant application is fully disclosed in the U.S. Patent No. 12277109 and is covered by the U.S. Patent No. 12277109 and the application are claiming common subject matter, as follows:
U.S. Patent No. 12277109
Instant Application - 19/076,983
1. A system for real-time recording of transfers of self-validating digital records across cryptographically secure networks using cross-network registries, the system comprising: one or more processors: and one or more non-transitory, computer-readable mediums comprising instructions recorded thereon that when executed by the one or more processors cause operations comprising: receiving, at a first off-chain server, a first self-validating digital record from a first entity, wherein the first self-validating digital record corresponds to a first off-chain record designated by the first entity to be transferred to a second entity during a first transfer, wherein the first self-validating digital record indicates a first cryptographically secure network for confirming the first transfer, wherein the first self-validating digital record comprises a first validation requirement for validating the first self-validating digital record prior to creation, and wherein the first validation requirement is encoded by the first entity in the first self-validating digital record; determining, by the first self-validating digital record, that the first validation requirement is met; and in response to determining that the first validation requirement is met: compiling, at the first off-chain server, the first self-validating digital record and the first validation requirement in a first self-executing program corresponding to the first self-validating digital record; and providing the first self-executing program corresponding to the first self-validating digital record to a cross-network registry, wherein the cross-network registry modifies and re-compiles the first self-executing program corresponding to the first self-validating digital record based on a protocol for the first cryptographically secure network, and wherein the cross-network registry confirms the first transfer by creating the first self-validating digital record on a first cryptographically secure network by executing the first self-executing program.
1. A system for real-time recording of transfers of self-validating digital records across cryptographically secure networks using cross-network registries, the system comprising: one or more processors: and one or more non-transitory, computer-readable mediums comprising instructions recorded thereon that when executed by the one or more processors cause operations comprising: receiving, at a first off-chain server, a first self-validating digital record from a first entity, wherein the first self-validating digital record corresponds to a first off-chain record designated by the first entity to be transferred to a second entity during a first transfer; receiving, at the first off-chain server, first off-chain data from an off-chain data source; determining, by the first self-validating digital record, that a first validation requirement is met; andin response to determining that the first validation requirement is met: compiling, at the first off-chain server, the first self-validating digital record and the first validation requirement in a first self-executing program corresponding to the first self- validating digital record; and providing the first self-executing program corresponding to the first self- validating digital record to a cross-network registry, wherein the cross-network registry modifies and re-compiles the first self-executing program corresponding to the first self-validating digital record based on a protocol for a first cryptographically secure network, and wherein the cross- network registry confirms the first transfer by creating the first self-validating digital record on the first cryptographically secure network by executing the first self-executing program.
2. A method for real-time recording of transfers of self-validating digital records across cryptographically secure networks using cross-network registries, the method comprising: receiving, at a first off-chain server, a first self-validating digital record from a first entity, wherein the first self-validating digital record corresponds to a first off-chain record designated by the first entity to be transferred to a second entity, wherein the first self-validating digital record comprises a first validation requirement for validating the first self-validating digital record prior to creation, and wherein the first validation requirement is encoded by the first entity in the first self-validating digital record; determining, by the first self-validating digital record, that the first validation requirement is met; and in response to determining that the first validation requirement is met: compiling, at the first off-chain server, the first self-validating digital record and the first validation requirement in a first self-executing program corresponding to the first self-validating digital record; and providing the first self-executing program corresponding to the first self-validating digital record to a cross-network registry, wherein the cross-network registry confirms transfer of the first off-chain record to the second entity by creating the first self-validating digital record on a first cryptographically secure network by executing the first self-executing program.
2. A method for real-time recording of transfers of self-validating digital records across cryptographically secure networks using cross-network registries, the method comprising: receiving, at a first off-chain server, a first self-validating digital record from a first entity, wherein the first self-validating digital record corresponds to a first off-chain record designated by the first entity to be transferred to a second entity; receiving, at the first off-chain server, first off-chain data from an off-chain data source; determining, by the first self-validating digital record, that a first validation requirement is met; and in response to determining that the first validation requirement is met: compiling, at the first off-chain server, the first self-validating digital record and the first validation requirement in a first self-executing program, for a first cryptographically secure network, corresponding to the first self-validating digital record; and providing the first self-executing program corresponding to the first self-validating digital record to a cross-network registry, wherein the cross-network registry confirms transfer of the first off-chain record to the second entity by creating the first self-validating digital record on the first cryptographically secure network by executing the first self-executing program.
3. The method of claim 2, further comprising: receiving first off-chain data; determining based on a first self-executing program of the first self-validating digital record a first pre-deployment validation characteristic for the first validation requirement, wherein the first pre-deployment validation characteristic confirms that the first off-chain record is immobilized at a secure location; and determining, based on a second self-executing program of the first self-validating digital record, that the first pre-deployment validation characteristic corresponds to the first off-chain data.
3. The method of claim 2, further comprising: determining based on the first self-executing program of the first self-validating digital record a first pre-deployment validation characteristic for the first validation requirement, wherein the first pre-deployment validation characteristic confirms that the first off-chain record is immobilized at a secure location; and determining, based on a second self-executing program of the first self-validating digital record, that the first pre-deployment validation characteristic corresponds to the first off-chain data.
4. The method of claim 3, further comprising: detecting, by the first off-chain server, an instance of the first self-validating digital record on the first cryptographically secure network; and generating a communication to the secure location to release the first off-chain record to the second entity, wherein the communication comprises a digital signature for the secure location.
4. The method of claim 3, further comprising: detecting, by the first off-chain server, an instance of the first self-validating digital record on the first cryptographically secure network; and generating a communication to the secure location to release the first off-chain record to the second entity, wherein the communication comprises a digital signature for the secure location.
5. The method of claim 2, further comprising: determining a secure location of the first off-chain record; and determining the first validation requirement based on the secure location.
5. The method of claim 2, further comprising: determining a secure location of the first off-chain record; and determining the first validation requirement based on the secure location.
6. The method of claim 2, further comprising: receiving first off-chain data; determining an encoding format for a third self-executing program of the first self-validating digital record, wherein the third self-executing program is used to process the first off-chain data; and formatting the first off-chain data based on the encoding format.
6. The method of claim 2, further comprising: determining an encoding format for a third self-executing program of the first self- validating digital record, wherein the third self-executing program is used to process the first off- chain data; and formatting the first off-chain data based on the encoding format.
7. The method of claim 2, wherein confirming the transfer of the first off-chain record to the second entity by creating the first self-validating digital record on the first cryptographically secure network further comprises: determining, by a fourth self-executing program at the cross-network registry, that a second validation requirement for validating the first self-validating digital record prior to creation is required; determining based on a fourth self-executing program a second pre-deployment validation characteristic for the second validation requirement, wherein the second pre-deployment validation characteristic corresponds to a geographic restriction of transfers of the first off-chain record; retrieving second off-chain data, wherein the second off-chain data indicates a geographic location of the second entity; and determining that the second pre-deployment validation characteristic corresponds to the second off-chain data.
7. The method of claim 2, wherein confirming the transfer of the first off-chain record to the second entity by creating the first self-validating digital record on the first cryptographically secure network further comprises: determining, by a fourth self-executing program at the cross-network registry, that a second validation requirement for validating the first self-validating digital record prior to creation is required; determining, based on the fourth self-executing program, a second pre-deployment validation characteristic for the second validation requirement, wherein the second pre-deployment validation characteristic corresponds to a geographic restriction of transfers of the first off-chain record; retrieving second off-chain data, wherein the second off-chain data indicates a geographic location of the second entity; and determining that the second pre-deployment validation characteristic corresponds to the second off-chain data.
8. The method of claim 2, wherein confirming the transfer of the first off-chain record to the second entity by creating the first self-validating digital record on the first cryptographically secure network further comprises: determining, by a fourth self-executing program at the cross-network registry, that a second validation requirement for validating the first self-validating digital record prior to creation is required; determining based on a fourth self-executing program a second pre-deployment validation characteristic for the second validation requirement, wherein the second pre-deployment validation characteristic corresponds to a KYC restriction of transfers of the first off-chain record; retrieving second off-chain data, wherein the second off-chain data indicates a known customer number of the second entity; and determining that the second pre-deployment validation characteristic corresponds to the second off-chain data.
8. The method of claim 2, wherein confirming the transfer of the first off-chain record to the second entity by creating the first self-validating digital record on the first cryptographically secure network further comprises: determining, by a fourth self-executing program at the cross-network registry, that a second validation requirement for validating the first self-validating digital record prior to creation is required; determining, based on the fourth self-executing program, a second pre-deployment validation characteristic for the second validation requirement, wherein the second pre-deployment validation characteristic corresponds to a KYC restriction of transfers of the first off-chain record; retrieving second off-chain data, wherein the second off-chain data indicates a known customer number of the second entity; and determining that the second pre-deployment validation characteristic corresponds to the second off-chain data.
9. The method of claim 2, wherein confirming the transfer of the first off-chain record to the second entity by creating the first self-validating digital record on the first cryptographically secure network further comprises: determining, by a fourth self-executing program at the cross-network registry, that a second validation requirement for validating the first self-validating digital record prior to creation is required; determining based on a fourth self-executing program a second pre-deployment validation characteristic for the second validation requirement, wherein the second pre-deployment validation characteristic corresponds to a temporal restriction of transfers of the first off-chain record; retrieving second off-chain data, wherein the second off-chain data indicates a current time; and determining that the second pre-deployment validation characteristic corresponds to the second off-chain data.
9. The method of claim 2, wherein confirming the transfer of the first off-chain record to the second entity by creating the first self-validating digital record on the first cryptographically secure network further comprises: determining, by a fourth self-executing program at the cross-network registry, that a second validation requirement for validating the first self-validating digital record prior to creation is required; determining, based on the fourth self-executing program, a second pre-deployment validation characteristic for the second validation requirement, wherein the second pre-deployment validation characteristic corresponds to a temporal restriction of transfers of the first off-chain record; retrieving second off-chain data, wherein the second off-chain data indicates a current time; and determining that the second pre-deployment validation characteristic corresponds to the second off-chain data.
10. The method of claim 2, wherein confirming the transfer of the first off-chain record to the second entity by creating the first self-validating digital record on the first cryptographically secure network further comprises: determining, by a fourth self-executing program at the cross-network registry, that a second validation requirement for validating the first self-validating digital record prior to creation is required; determining based on a fourth self-executing program a second pre-deployment validation characteristic for the second validation requirement, wherein the second pre-deployment validation characteristic corresponds to a network route restriction of transfers of the first off-chain record; retrieving second off-chain data, wherein the second off-chain data indicates a network route for the transfer of the first off-chain record; and determining that the second pre-deployment validation characteristic corresponds to the second off-chain data.
10. The method of claim 2, wherein confirming the transfer of the first off-chain record to the second entity by creating the first self-validating digital record on the first cryptographically secure network further comprises: determining, by a fourth self-executing program at the cross-network registry, that a second validation requirement for validating the first self-validating digital record prior to creation is required; determining, based on the fourth self-executing program, a second pre-deployment validation characteristic for the second validation requirement, wherein the second pre-deployment validation characteristic corresponds to a network route restriction of transfers of the first off-chain record; retrieving second off-chain data, wherein the second off-chain data indicates a network route for the transfer of the first off-chain record; and determining that the second pre-deployment validation characteristic corresponds to the second off-chain data.
11. The method of claim 2, wherein confirming the transfer of the first off-chain record to the second entity by creating the first self-validating digital record on the first cryptographically secure network further comprises: determining, by a fourth self-executing program at the cross-network registry, that a second validation requirement for validating the first self-validating digital record prior to creation is required; determining based on a fourth self-executing program a second pre-deployment validation characteristic for the second validation requirement, wherein the second pre-deployment validation characteristic corresponds to an asset type restriction of transfers of the first off-chain record; retrieving second off-chain data, wherein the second off-chain data indicates an asset type of the first off-chain record; and determining that the second pre-deployment validation characteristic corresponds to the second off-chain data.
11. The method of claim 2, wherein confirming the transfer of the first off-chain record to the second entity by creating the first self-validating digital record on the first cryptographically secure network further comprises: determining, by a fourth self-executing program at the cross-network registry, that a second validation requirement for validating the first self-validating digital record prior to creation is required; determining, based on the fourth self-executing program, a second pre-deployment validation characteristic for the second validation requirement, wherein the second pre-deployment validation characteristic corresponds to an asset type restriction of transfers of the first off-chain record; retrieving second off-chain data, wherein the second off-chain data indicates an asset type of the first off-chain record; and determining that the second pre-deployment validation characteristic corresponds to the second off-chain data.
12. The method of claim 2, wherein receiving, at the first off-chain server, the first self-validating digital record from the first entity further comprises: extracting, by the first off-chain server, implementation details for creating the first self-validating digital record; and generating the first validation requirement based on the implementation details.
12. The method of claim 2, wherein receiving, at the first off-chain server, the first self- validating digital record from the first entity further comprises: extracting, by the first off-chain server, implementation details for creating the first self- validating digital record; and generating the first validation requirement based on the implementation details.
13. The method of claim 2, wherein providing the first self-validating digital record to the cross-network registry further comprises: retrieving, at the cross-network registry, a complier; and compiling a fifth self-executing program for creating the first self-validating digital record on the first cryptographically secure network.
13. The method of claim 2, wherein providing the first self-validating digital record to the cross-network registry further comprises: retrieving, at the cross-network registry, a complier; and compiling a fifth self-executing program for creating the first self-validating digital record on the first cryptographically secure network.
14. One or more non-transitory, computer-readable mediums comprising instructions recorded thereon that when executed by one or more processors cause operations comprising: receiving, at a cross-network registry, a first self-validating digital record, wherein the first self-validating digital record is validated by: receiving, at a first off-chain server, the first self-validating digital record from a first entity, wherein the first self-validating digital record corresponds to a first off-chain record designated by the first entity to be transferred to a second entity, wherein the first self-validating digital record comprises a first validation requirement for validating the first self-validating digital record prior to creation, wherein the first validation requirement is encoded by the first entity in the first self-validating digital record, and wherein the first self-validating digital record uses the first validation requirement to validate itself for creation on first cryptographically secure network; determining, by the first self-validating digital record, that the first validation requirement is met, wherein the first self-validating digital record and the validation requirement are complied at the first off-chain server in response to determining that the first validation requirement is met; and confirming, by the cross-network registry, transfer of the first off-chain record to the second entity by creating the first self-validating digital record on a first cryptographically secure network.
14. One or more non-transitory, computer-readable mediums comprising instructions recorded thereon that when executed by one or more processors cause operations comprising: receiving, at a cross-network registry, a first self-validating digital record, wherein the first self-validating digital record is validated by: receiving, at a first off-chain server, the first self-validating digital record from a first entity, wherein the first self-validating digital record corresponds to a first off-chain record designated by the first entity to be transferred to a second entity; determining, by the first self-validating digital record, that a first validation requirement is met, wherein the first self-validating digital record and the first validation requirement are complied at the first off-chain server in response to determining that the first validation requirement is met; and confirming, by the cross-network registry, transfer of the first off-chain record to the second entity by creating the first self-validating digital record on a first cryptographically secure network.
15. The one or more non-transitory, computer-readable mediums of claim 14, wherein the instructions further cause operations comprising: receiving first off-chain data; determining based on a first self-executing program of the first self-validating digital record a first pre-deployment validation characteristic for the first validation requirement, wherein the first pre-deployment validation characteristic confirms that the first off-chain record is immobilized at a secure location; and determining, based on a second self-executing program of the first self-validating digital record, that the first pre-deployment validation characteristic corresponds to the first off-chain data.
15. The one or more non-transitory, computer-readable mediums of claim 14, wherein the operations further cause operations comprising: receiving first off-chain data; determining based on a first self-executing program of the first self-validating digital record a first pre-deployment validation characteristic for the first validation requirement, wherein the first pre-deployment validation characteristic confirms that the first off-chain record is immobilized at a secure location; and determining, based on a second self-executing program of the first self-validating digital record, that the first pre-deployment validation characteristic corresponds to the first off-chain data.
16. The one or more non-transitory, computer-readable mediums of claim 15, wherein the instructions further cause operations comprising: detecting, by the first off-chain server, an instance of the first self-validating digital record on the first cryptographically secure network; and generating a communication to the secure location to release the first off-chain record to the second entity, wherein the communication comprises a digital signature for the secure location.
16. The one or more non-transitory, computer-readable mediums of claim 15, wherein the operations further cause operations comprising: detecting, by the first off-chain server, an instance of the first self-validating digital record on the first cryptographically secure network; and generating a communication to the secure location to release the first off-chain record to the second entity, wherein the communication comprises a digital signature for the secure location.
17. The one or more non-transitory, computer-readable mediums of claim 14, wherein the instructions further cause operations comprising: determining a secure location of the first off-chain record; and determining the first validation requirement based on the secure location.
17. The one or more non-transitory, computer-readable mediums of claim 14, wherein the operations further cause operations comprising: determining a secure location of the first off-chain record; and determining the first validation requirement based on the secure location.
18. The one or more non-transitory, computer-readable mediums of claim 14, wherein the instructions further cause operations comprising: receiving first off-chain data; determining an encoding format for a third self-executing program of the first self-validating digital record, wherein the third self-executing program is used to process the first off-chain data; and formatting the first off-chain data based on the encoding format.
18. The one or more non-transitory, computer-readable mediums of claim 14, wherein the operations further comprise: determining an encoding format for a third self-executing program of the first self- validating digital record, wherein the third self-executing program is used to process first off-chain data; and formatting the first off-chain data based on the encoding format.
19. The one or more non-transitory, computer-readable mediums of claim 14, wherein the first self-validating digital record designates the first cryptographically secure network.
19. The one or more non-transitory, computer-readable mediums of claim 14, wherein the first self-validating digital record designates the first cryptographically secure network.
20. The one or more non-transitory, computer-readable mediums of claim 14, wherein the cross-network registry compiles the first self-validating digital record based on a protocol for the first cryptographically secure network.
20. The one or more non-transitory, computer-readable mediums of claim 14, wherein the cross-network registry compiles the first self-validating digital record based on a protocol for the first cryptographically secure network.
Noted, it would have been obvious to a person of ordinary skill in the art at the time the invention was made to modify or to omit the additional elements of claims 1-20 of U.S. Patent No. 12277109 to arrive at the claims 1-20 of the instant application because the person would have realized that the remaining element would perform the same functions as before. "Omission of element and its function in combination is obvious expedient if the remaining elements perform same functions as before." See In re Karlson (CCPA) 136 USPQ 184, decide Jan 16, 1963, Appl. No. 6857, U.S. Court of Customs and Patent Appeals.
5. Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 11971881. The subject matter claimed in the instant application is fully disclosed in the U.S. Patent No. 11971881and is covered by the U.S. Patent No. 11971881 and the application are claiming common subject matter, as follows:
U.S. Patent No. 11971881
Instant Application - 19/076,983
1. (Currently Amended) A system for real-time recording of transfers of self-validating digital records across cryptographically secure networks using cross-network registries, the system comprising: one or more processors: and one or more non-transitory, computer-readable mediums comprising instructions recorded thereon that when executed by the one or more processors cause operations comprising: receiving, at a first off-chain server, a first self-validating digital record from a first entity, wherein the first self-validating digital record corresponds to a first off-chain record designated by the first entity to be transferred to a second entity during a first transfer, wherein the first self-validating digital record indicates a first cryptographically secure network for confirming the first transfer, wherein the first self-validating digital record comprises a first validation requirement for validating the first self-validating digital record prior to creation, wherein the first validation requirement is encoded by the first entity in the first self-validating digital record, and wherein the first self-validating digital record uses the first validation requirement to validate itself for creation on first cryptographically secure network; receiving, at the first off-chain server, first off-chain data from an off-chain data source; determining, by the first self-validating digital record, that the first validation requirement is met by executing a self-executing program that compares the first off-chain data to a pre-deployment validation characteristic for the first validation requirement; and in response to determining that the first validation requirement is met: compiling, at the first off-chain server, the first self-validating digital record, the first off-chain data, and the first validation requirement in a first self-executing program corresponding to the first self-validating digital record; and providing the first self-executing program corresponding to the first self- validating digital record to a cross-network registry, wherein the cross-network registry modifies and re-compiles the first self-executing program corresponding to the first self-validating digital record based on a protocol for the first cryptographically secure network, and wherein the cross- network registry confirms the first transfer by creating the first self-validating digital record on the first cryptographically secure network by executing the first self-executing program.
1. A system for real-time recording of transfers of self-validating digital records across cryptographically secure networks using cross-network registries, the system comprising: one or more processors: and one or more non-transitory, computer-readable mediums comprising instructions recorded thereon that when executed by the one or more processors cause operations comprising: receiving, at a first off-chain server, a first self-validating digital record from a first entity, wherein the first self-validating digital record corresponds to a first off-chain record designated by the first entity to be transferred to a second entity during a first transfer; receiving, at the first off-chain server, first off-chain data from an off-chain data source; determining, by the first self-validating digital record, that a first validation requirement is met; andin response to determining that the first validation requirement is met: compiling, at the first off-chain server, the first self-validating digital record and the first validation requirement in a first self-executing program corresponding to the first self- validating digital record; and providing the first self-executing program corresponding to the first self- validating digital record to a cross-network registry, wherein the cross-network registry modifies and re-compiles the first self-executing program corresponding to the first self-validating digital record based on a protocol for a first cryptographically secure network, and wherein the cross- network registry confirms the first transfer by creating the first self-validating digital record on the first cryptographically secure network by executing the first self-executing program.
2. (Currently Amended) A method for real-time recording of transfers of self-validating digital records across cryptographically secure networks using cross-network registries, the method comprising: receiving, at a first off-chain server, a first self-validating digital record from a first entity, wherein the first self-validating digital record corresponds to a first off-chain record designated by the first entity to be transferred to a second entity, [[and]] wherein the first self-validating digital record comprises a first validation requirement for validating the first self-validating digital record prior to creation, wherein the first validation requirement is encoded by the first entity in the first self-validating digital record, and wherein the first self-validating digital record uses the first validation requirement to validate itself for creation on first cryptographically secure network; receiving, at the first off-chain server, first off-chain data; determining, by the first self-validating digital record, that the first validation requirement is met based on the first off-chain data; and in response to determining that the first validation requirement is met: compiling, at the first off-chain server, the first self-validating digital record, the first off-chain data, and the first validation requirement in a first self-executing program corresponding to the first self-validating digital record; and providing the first self-executing program corresponding to the first self-validating digital record to a cross-network registry, wherein the cross-network registry confirms transfer of the first off-chain record to the second entity by creating the first self-validating digital record on the first cryptographically secure network by executing the first self-executing program.
2. A method for real-time recording of transfers of self-validating digital records across cryptographically secure networks using cross-network registries, the method comprising: receiving, at a first off-chain server, a first self-validating digital record from a first entity, wherein the first self-validating digital record corresponds to a first off-chain record designated by the first entity to be transferred to a second entity; receiving, at the first off-chain server, first off-chain data from an off-chain data source; determining, by the first self-validating digital record, that a first validation requirement is met; and in response to determining that the first validation requirement is met: compiling, at the first off-chain server, the first self-validating digital record and the first validation requirement in a first self-executing program, for a first cryptographically secure network, corresponding to the first self-validating digital record; and providing the first self-executing program corresponding to the first self-validating digital record to a cross-network registry, wherein the cross-network registry confirms transfer of the first off-chain record to the second entity by creating the first self-validating digital record on the first cryptographically secure network by executing the first self-executing program.
3. The method of claim 2, wherein determining that the first validation requirement is met based on the first off-chain data comprises: determining based on a first self-executing program of the first self-validating digital record a first pre-deployment validation characteristic for the first validation requirement, wherein the first pre-deployment validation characteristic confirms that the first off-chain record is immobilized at a secure location; and determining, based on a second self-executing program of the first self-validating digital record, that the first pre-deployment validation characteristic corresponds to the first off-chain data.
3. The method of claim 2, further comprising: determining based on the first self-executing program of the first self-validating digital record a first pre-deployment validation characteristic for the first validation requirement, wherein the first pre-deployment validation characteristic confirms that the first off-chain record is immobilized at a secure location; and determining, based on a second self-executing program of the first self-validating digital record, that the first pre-deployment validation characteristic corresponds to the first off-chain data.
4. The method of claim 3, further comprising: detecting, by the first off-chain server, an instance of the first self-validating digital record on the first cryptographically secure network; and generating a communication to the secure location to release the first off-chain record to the second entity, wherein the communication comprises a digital signature for the secure location.
4. The method of claim 3, further comprising: detecting, by the first off-chain server, an instance of the first self-validating digital record on the first cryptographically secure network; and generating a communication to the secure location to release the first off-chain record to the second entity, wherein the communication comprises a digital signature for the secure location.
5. The method of claim 2, further comprising: determining a secure location of the first off-chain record; and determining the first validation requirement based on the secure location.
5. The method of claim 2, further comprising: determining a secure location of the first off-chain record; and determining the first validation requirement based on the secure location.
6. The method of claim 2, wherein receiving the first off-chain data further comprises: determining an encoding format for a third self-executing program of the first self-validating digital record, wherein the third self-executing program is used to process the first off-chain data; and formatting the first off-chain data based on the encoding format.
6. The method of claim 2, further comprising: determining an encoding format for a third self-executing program of the first self- validating digital record, wherein the third self-executing program is used to process the first off- chain data; and formatting the first off-chain data based on the encoding format.
7. The method of claim 2, wherein confirming the transfer of the first off-chain record to the second entity by creating the first self-validating digital record on the first cryptographically secure network further comprises: determining, by a fourth self-executing program at the cross-network registry, that a second validation requirement for validating the first self-validating digital record prior to creation is required; determining based on a fourth self-executing program a second pre-deployment validation characteristic for the second validation requirement, wherein the second pre-deployment validation characteristic corresponds to a geographic restriction of transfers of the first off-chain record; retrieving second off-chain data, wherein the second off-chain data indicates a geographic location of the second entity; and determining that the second pre-deployment validation characteristic corresponds to the second off-chain data.
7. The method of claim 2, wherein confirming the transfer of the first off-chain record to the second entity by creating the first self-validating digital record on the first cryptographically secure network further comprises: determining, by a fourth self-executing program at the cross-network registry, that a second validation requirement for validating the first self-validating digital record prior to creation is required; determining, based on the fourth self-executing program, a second pre-deployment validation characteristic for the second validation requirement, wherein the second pre-deployment validation characteristic corresponds to a geographic restriction of transfers of the first off-chain record; retrieving second off-chain data, wherein the second off-chain data indicates a geographic location of the second entity; and determining that the second pre-deployment validation characteristic corresponds to the second off-chain data.
8. The method of claim 2, wherein confirming the transfer of the first off-chain record to the second entity by creating the first self-validating digital record on the first cryptographically secure network further comprises: determining, by a fourth self-executing program at the cross-network registry, that a second validation requirement for validating the first self-validating digital record prior to creation is required; determining based on a fourth self-executing program a second pre-deployment validation characteristic for the second validation requirement, wherein the second pre-deployment validation characteristic corresponds to a KYC restriction of transfers of the first off-chain record; retrieving second off-chain data, wherein the second off-chain data indicates a known customer number of the second entity; and determining that the second pre-deployment validation characteristic corresponds to the second off-chain data.
8. The method of claim 2, wherein confirming the transfer of the first off-chain record to the second entity by creating the first self-validating digital record on the first cryptographically secure network further comprises: determining, by a fourth self-executing program at the cross-network registry, that a second validation requirement for validating the first self-validating digital record prior to creation is required; determining, based on the fourth self-executing program, a second pre-deployment validation characteristic for the second validation requirement, wherein the second pre-deployment validation characteristic corresponds to a KYC restriction of transfers of the first off-chain record; retrieving second off-chain data, wherein the second off-chain data indicates a known customer number of the second entity; and determining that the second pre-deployment validation characteristic corresponds to the second off-chain data.
9. The method of claim 2, wherein confirming the transfer of the first off-chain record to the second entity by creating the first self-validating digital record on the first cryptographically secure network further comprises: determining, by a fourth self-executing program at the cross-network registry, that a second validation requirement for validating the first self-validating digital record prior to creation is required; determining based on a fourth self-executing program a second pre-deployment validation characteristic for the second validation requirement, wherein the second pre-deployment validation characteristic corresponds to a temporal restriction of transfers of the first off-chain record; retrieving second off-chain data, wherein the second off-chain data indicates a current time; and determining that the second pre-deployment validation characteristic corresponds to the second off-chain data.
9. The method of claim 2, wherein confirming the transfer of the first off-chain record to the second entity by creating the first self-validating digital record on the first cryptographically secure network further comprises: determining, by a fourth self-executing program at the cross-network registry, that a second validation requirement for validating the first self-validating digital record prior to creation is required; determining, based on the fourth self-executing program, a second pre-deployment validation characteristic for the second validation requirement, wherein the second pre-deployment validation characteristic corresponds to a temporal restriction of transfers of the first off-chain record; retrieving second off-chain data, wherein the second off-chain data indicates a current time; and determining that the second pre-deployment validation characteristic corresponds to the second off-chain data.
10. The method of claim 2, wherein confirming the transfer of the first off-chain record to the second entity by creating the first self-validating digital record on the first cryptographically secure network further comprises: determining, by a fourth self-executing program at the cross-network registry, that a second validation requirement for validating the first self-validating digital record prior to creation is required; determining based on a fourth self-executing program a second pre-deployment validation characteristic for the second validation requirement, wherein the second pre-deployment validation characteristic corresponds to a network route restriction of transfers of the first off-chain record; retrieving second off-chain data, wherein the second off-chain data indicates a network route for the transfer of the first off-chain record; and determining that the second pre-deployment validation characteristic corresponds to the second off-chain data.
10. The method of claim 2, wherein confirming the transfer of the first off-chain record to the second entity by creating the first self-validating digital record on the first cryptographically secure network further comprises: determining, by a fourth self-executing program at the cross-network registry, that a second validation requirement for validating the first self-validating digital record prior to creation is required; determining, based on the fourth self-executing program, a second pre-deployment validation characteristic for the second validation requirement, wherein the second pre-deployment validation characteristic corresponds to a network route restriction of transfers of the first off-chain record; retrieving second off-chain data, wherein the second off-chain data indicates a network route for the transfer of the first off-chain record; and determining that the second pre-deployment validation characteristic corresponds to the second off-chain data.
11. The method of claim 2, wherein confirming the transfer of the first off-chain record to the second entity by creating the first self-validating digital record on the first cryptographically secure network further comprises: determining, by a fourth self-executing program at the cross-network registry, that a second validation requirement for validating the first self-validating digital record prior to creation is required; determining based on a fourth self-executing program a second pre-deployment validation characteristic for the second validation requirement, wherein the second pre-deployment validation characteristic corresponds to an asset type restriction of transfers of the first off-chain record; retrieving second off-chain data, wherein the second off-chain data indicates an asset type of the first off-chain record; and determining that the second pre-deployment validation characteristic corresponds to the second off-chain data.
11. The method of claim 2, wherein confirming the transfer of the first off-chain record to the second entity by creating the first self-validating digital record on the first cryptographically secure network further comprises: determining, by a fourth self-executing program at the cross-network registry, that a second validation requirement for validating the first self-validating digital record prior to creation is required; determining, based on the fourth self-executing program, a second pre-deployment validation characteristic for the second validation requirement, wherein the second pre-deployment validation characteristic corresponds to an asset type restriction of transfers of the first off-chain record; retrieving second off-chain data, wherein the second off-chain data indicates an asset type of the first off-chain record; and determining that the second pre-deployment validation characteristic corresponds to the second off-chain data.
12. The method of claim 2, wherein receiving, at the first off-chain server, the first self-validating digital record from the first entity further comprises: extracting, by the first off-chain server, implementation details for creating the first self-validating digital record; and generating the first validation requirement based on the implementation details.
12. The method of claim 2, wherein receiving, at the first off-chain server, the first self- validating digital record from the first entity further comprises: extracting, by the first off-chain server, implementation details for creating the first self- validating digital record; and generating the first validation requirement based on the implementation details.
13. The method of claim 2, wherein providing the first self-validating digital record to the cross-network registry further comprises: retrieving, at the cross-network registry, a complier; and compiling a fifth self-executing program for creating the first self-validating digital record on the first cryptographically secure network.
13. The method of claim 2, wherein providing the first self-validating digital record to the cross-network registry further comprises: retrieving, at the cross-network registry, a complier; and compiling a fifth self-executing program for creating the first self-validating digital record on the first cryptographically secure network.
14. (Currently Amended) One or more non-transitory, computer-readable mediums comprising instructions recorded thereon that when executed by one or more processors cause operations comprising: receiving, at a cross-network registry, a first self-validating digital record, wherein the first self-validating digital record is validated by: receiving, at a first off-chain server, the first self-validating digital record from a first entity, wherein the first self-validating digital record corresponds to a first off-chain record designated by the first entity to be transferred to a second entity, [[and]] wherein the first self- validating digital record comprises a first validation requirement for validating the first self- validating digital record prior to creation, wherein the first validation requirement is encoded by the first entity in the first self-validating digital record, and wherein the first self-validating digital record uses the first validation requirement to validate itself for creation on first cryptographically secure network; receiving, at the first off-chain server, first off-chain data; and determining, by the first self-validating digital record, that the first validation requirement is met based on the first off-chain data, wherein the first self-validating digital record, the first off-chain data, and the validation requirement are complied at the first off-chain server in response to determining that the first validation requirement is met; and in response to determining that the first validation requirement is met, providing the first self-validating digital record to a cross-network registry; confirming, by the cross-network registry, transfer of the first off-chain record to the second entity by creating the first self-validating digital record on a first cryptographically secure network.
14. One or more non-transitory, computer-readable mediums comprising instructions recorded thereon that when executed by one or more processors cause operations comprising: receiving, at a cross-network registry, a first self-validating digital record, wherein the first self-validating digital record is validated by: receiving, at a first off-chain server, the first self-validating digital record from a first entity, wherein the first self-validating digital record corresponds to a first off-chain record designated by the first entity to be transferred to a second entity; determining, by the first self-validating digital record, that a first validation requirement is met, wherein the first self-validating digital record and the first validation requirement are complied at the first off-chain server in response to determining that the first validation requirement is met; and confirming, by the cross-network registry, transfer of the first off-chain record to the second entity by creating the first self-validating digital record on a first cryptographically secure network.
15. The one or more non-transitory, computer-readable mediums of claim 14, wherein determining that the first validation requirement is met based on the first off-chain data comprises: determining based on a first self-executing program of the first self-validating digital record a first pre-deployment validation characteristic for the first validation requirement, wherein the first pre-deployment validation characteristic confirms that the first off-chain record is immobilized at a secure location; and determining, based on a second self-executing program of the first self-validating digital record, that the first pre-deployment validation characteristic corresponds to the first off-chain data.
15. The one or more non-transitory, computer-readable mediums of claim 14, wherein the operations further cause operations comprising: receiving first off-chain data; determining based on a first self-executing program of the first self-validating digital record a first pre-deployment validation characteristic for the first validation requirement, wherein the first pre-deployment validation characteristic confirms that the first off-chain record is immobilized at a secure location; and determining, based on a second self-executing program of the first self-validating digital record, that the first pre-deployment validation characteristic corresponds to the first off-chain data.
16. The one or more non-transitory, computer-readable mediums of claim 15, further comprising: detecting, by the first off-chain server, an instance of the first self-validating digital record on the first cryptographically secure network; and generating a communication to the secure location to release the first off-chain record to the second entity, wherein the communication comprises a digital signature for the secure location.
16. The one or more non-transitory, computer-readable mediums of claim 15, wherein the operations further cause operations comprising: detecting, by the first off-chain server, an instance of the first self-validating digital record on the first cryptographically secure network; and generating a communication to the secure location to release the first off-chain record to the second entity, wherein the communication comprises a digital signature for the secure location.
17. The one or more non-transitory, computer-readable mediums of claim 14, wherein the operations further cause operations comprising: determining a secure location of the first off-chain record; and determining the first validation requirement based on the secure location.
17. The one or more non-transitory, computer-readable mediums of claim 14, wherein the operations further cause operations comprising: determining a secure location of the first off-chain record; and determining the first validation requirement based on the secure location.
18. The one or more non-transitory, computer-readable mediums of claim 14, wherein receiving the first off-chain data further comprises: determining an encoding format for a third self-executing program of the first self-validating digital record, wherein the third self-executing program is used to process the first off-chain data; and formatting the first off-chain data based on the encoding format.
18. The one or more non-transitory, computer-readable mediums of claim 14, wherein the operations further comprise: determining an encoding format for a third self-executing program of the first self- validating digital record, wherein the third self-executing program is used to process first off-chain data; and formatting the first off-chain data based on the encoding format.
19. The one or more non-transitory, computer-readable mediums of claim 14, wherein the first self-validating digital record designates the first cryptographically secure network.
19. The one or more non-transitory, computer-readable mediums of claim 14, wherein the first self-validating digital record designates the first cryptographically secure network.
20. The one or more non-transitory, computer-readable mediums of claim 14, wherein the cross-network registry compiles the first self-validating digital record based on a protocol for the first cryptographically secure network.
20. The one or more non-transitory, computer-readable mediums of claim 14, wherein the cross-network registry compiles the first self-validating digital record based on a protocol for the first cryptographically secure network.
Noted, it would have been obvious to a person of ordinary skill in the art at the time the invention was made to modify or to omit the additional elements of claims 1-20 of U.S. Patent No. 11971881 to arrive at the claims 1-20 of the instant application because the person would have realized that the remaining element would perform the same functions as before. "Omission of element and its function in combination is obvious expedient if the remaining elements perform same functions as before." See In re Karlson (CCPA) 136 USPQ 184, decide Jan 16, 1963, Appl. No. 6857, U.S. Court of Customs and Patent Appeals.
Claim Rejections - 35 USC § 103
6. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
7. Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Koh (US 2023/0169510 A1) hereinafter Koh, in view of Madl et al. (US 2020/0252202 A1) hereinafter Madl.
As to claim 1, Koh discloses a system for real-time recording of transfers of self-validating digital records across cryptographically secure networks using cross-network registries (Fig. 1, Para. 264, “the system 100 can be used to perform or otherwise record information regarding an exchange of one type of currency or electronic token for another (e.g., an exchange of one non-fungible token for another non-fungible token, an exchange of one currency for another, an exchange of a non-fungible token for a currency, etc.).”. Para. 329, “the first transaction node can provide medical information to the second transaction node in real time or approximately real time (e.g., to allow the health care provider to determine information regarding the patient in real time or approximately real time).”.), the system comprising: one or more processors (Para. 58): and one or more non-transitory, computer-readable mediums comprising instructions recorded thereon that when executed by the one or more processors cause operations comprising (Para. 58): receiving, at a first off-chain server, a first self-validating digital record from a first entity (Para. 16, a method includes receiving, by a second computing node of a distributed transaction network, a data record, i.e. a first self-validating digital record, from a first computing node, i.e. first entity, of the distributed transaction network, where the data record includes: an indication of a proposed transaction, an indication of a transaction value associated with the proposed transaction, and an indication of a smart contract associated with the proposed transaction.), wherein the first self-validating digital record corresponds to a first off-chain record designated by the first entity to be transferred to a second entity during a first transfer (Para. 13, a record indicating the transfer of a digital asset (e.g., an amount of cryptocurrency, non-fungible token, etc.) from a first party to a second party can itself constitute the transfer of ownership, i.e., first transfer, of the digital asset from the first party, i.e. first entity, to the second party, i.e. second entity.),
receiving, at the first off-chain server, first off-chain data from an off-chain data source (Para. 95, for a transaction including the transfer of other digital property (e.g., electronic tokens, such as non-fungible tokens) from first entity, i.e. an off-chain data source, associated with a first transaction node to a second entity associated with a second transaction node, the first transaction node can instruct the payment processor system 106 to transfer the digital property from a first account associated with the first entity to a second account associated with the second entity, where non-fungible tokens represents off-chain data.);
determining, by the first self-validating digital record, that a first validation requirement is met (Para. 354, “The second computing node validates the proposed transaction (block 904). Validating the proposed transaction includes at least one of: (i) determining that the first computing node is in possession of the transaction value, or (ii) determining that the second computing nodes satisfies one or more requirements specified by the smart contract.”. Para. 13, a recipient of the digital asset can self-validate a transaction, i.e., the first self-validating digital record, by confirming receipt of the digital asset and recording the receipt of the digital asset in the digital ledger with a signature that is unique to the recipient (e.g., a unique signature). This can be beneficial, for example, in ensuring the finality of the transaction (e.g., such that the transaction value cannot be transferred to others or "double spent" prior to being transferred to the recipient) by the recipient's own self-validation of proof of reception instead of external validation by third-party "miners" in proof of work and third-party "stakers" in proof of stake.); and
in response to determining that the first validation requirement is met: providing the first self-executing program corresponding to the first self- validating digital record to a cross-network registry, wherein the cross-network registry modifies and re-compiles the first self-executing program corresponding to the first self-validating digital record based on a protocol for a first cryptographically secure network, and wherein the cross- network registry confirms the first transfer by creating the first self-validating digital record on the first cryptographically secure network by executing the first self-executing program (Para. 13, “a recipient of the digital asset can self-validate a transaction by confirming receipt of the digital asset, and recording the receipt of the digital asset in the digital ledger with a signature that is unique to the recipient (e.g., a unique signature). This can be beneficial, for example, in ensuring the finality of the transaction (e.g., such that the transaction value cannot be transferred to others or "double spent" prior to being transferred to the recipient) by the recipient's own self-validation of proof of reception instead of external validation by third-party "miners" in proof of work and third-party "stakers" in proof of stake.”. Para. 235, a proposed transaction may include a transfer of a first value held by a first transaction node to a second transaction node, in exchange for a second value held by the second transaction node. Upon (on concurrently with) completion of the Transfer operations, the first transaction node and/or the second transaction node can record information regarding the completed transaction, i.e. creating the first self-validating digital record, in the distributed ledger 150, i.e., the first cryptographically secure network, or some other data storage medium (e.g., information confirming the completion of the transaction, the transferred value(s), the parties to the transaction, the time the transaction was performed, the location of the transaction, etc.). Para. 164, “the first computing node and the second computing node can transmit respective data blocks to the distributed transaction network 102, and the distributed transaction network 102 can store the blocks as additional blocks in a chain of blocks of the distributed ledger.”.).
Koh does not explicitly disclose in response to determining that the first validation requirement is met: compiling, at the first off-chain server, the first self-validating digital record and the first validation requirement in a first self-executing program corresponding to the first self- validating digital record;
However, in the same field of endeavor, Madl discloses in response to determining that the first validation requirement is met: compiling, at the first off-chain server, the first self-validating digital record and the first validation requirement in a first self-executing program corresponding to the first self- validating digital record (Para. 37, Smart contracts can be employed to automate parts of the cross-chain validation service. For example, to perform the cross-validation service, a user may send a blockchain address and a public key to an authority. A smart contract, i.e., a first self-executing program, can then be written that automatically takes this input data and generates the new block in the authority registry. Para. 49, The smart contract may include executable code which is registered, stored, and/or replicated with a blockchain (e.g., distributed network of blockchain peers). A transaction is an execution of the smart contract code which can be performed in response to conditions associated with the smart contract being satisfied, i.e., determining that the first validation requirement is met. Para. 46, “The blockchain configuration may include one or more applications 224 which are linked to application programming interfaces (APIs) 222 to access and execute stored program/application code 220 (e.g., chaincode, smart contracts, etc.) which can be created according to a customized configuration sought by participants and can maintain their own state, control their own assets, and receive external information. This can be deployed as a transaction and installed, via appending to the distributed ledger, on all blockchain nodes 204-210.”. Thus, in response to determining that the first validation requirement is met: compiling, at the first off-chain server, the first self-validating digital record and the first validation requirement in a first self-executing program corresponding to the first self- validating digital record.).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system of Koh by creating the smart contract such as the first self-executing program for the transaction record to be added to the blockchain as disclosed by Madl (Para. 46). A transaction is an execution of the smart contract code which can be performed in response to conditions associated with the smart contract being satisfied. Blockchain is utilized to provide a tamper-proof signature service and validation. One of the ordinary skills in the art would have motivated to make this modification in order to provide a tamper-proof service to validate the integrity of digital records via smart contracts as suggested by Madl (Para. 32).
As to claim 2, Koh discloses a method for real-time recording of transfers of self-validating digital records across cryptographically secure networks using cross-network registries (Fig. 1, Para. 264, “the system 100 can be used to perform or otherwise record information regarding an exchange of one type of currency or electronic token for another (e.g., an exchange of one non-fungible token for another non-fungible token, an exchange of one currency for another, an exchange of a non-fungible token for a currency, etc.).”. Para. 329, “the first transaction node can provide medical information to the second transaction node in real time or approximately real time (e.g., to allow the health care provider to determine information regarding the patient in real time or approximately real time).”.), the method comprising: receiving, at a first off-chain server, a first self-validating digital record from a first entity (Para. 16, a method includes receiving, by a second computing node of a distributed transaction network, a data record, i.e. a first self-validating digital record, from a first computing node, i.e. first entity, of the distributed transaction network, where the data record includes: an indication of a proposed transaction, an indication of a transaction value associated with the proposed transaction, and an indication of a smart contract associated with the proposed transaction.), wherein the first self-validating digital record corresponds to a first off-chain record designated by the first entity to be transferred to a second entity (Para. 13, a record indicating the transfer of a digital asset (e.g., an amount of cryptocurrency, non-fungible token, etc.) from a first party to a second party can itself constitute the transfer of ownership, i.e., first transfer, of the digital asset from the first party, i.e. first entity, to the second party, i.e. second entity.);
receiving, at the first off-chain server, first off-chain data from an off-chain data source (Para. 95, for a transaction including the transfer of other digital property (e.g., electronic tokens, such as non-fungible tokens) from first entity, i.e. an off-chain data source, associated with a first transaction node to a second entity associated with a second transaction node, the first transaction node can instruct the payment processor system 106 to transfer the digital property from a first account associated with the first entity to a second account associated with the second entity, where non-fungible tokens represents off-chain data.);
determining, by the first self-validating digital record, that the first validation requirement is met (Para. 354, “The second computing node validates the proposed transaction (block 904). Validating the proposed transaction includes at least one of: (i) determining that the first computing node is in possession of the transaction value, or (ii) determining that the second computing nodes satisfies one or more requirements specified by the smart contract.”. Para. 13, a recipient of the digital asset can self-validate a transaction, i.e., the first self-validating digital record, by confirming receipt of the digital asset and recording the receipt of the digital asset in the digital ledger with a signature that is unique to the recipient (e.g., a unique signature). This can be beneficial, for example, in ensuring the finality of the transaction (e.g., such that the transaction value cannot be transferred to others or "double spent" prior to being transferred to the recipient) by the recipient's own self-validation of proof of reception instead of external validation by third-party "miners" in proof of work and third-party "stakers" in proof of stake.); and
in response to determining that the first validation requirement is met, providing the first self-executing program corresponding to the first self-validating digital record to a cross-network registry, wherein the cross-network registry confirms transfer of the first off-chain record to the second entity by creating the first self-validating digital record on the first cryptographically secure network by executing the first self-executing program (Para. 13, “a recipient of the digital asset can self-validate a transaction by confirming receipt of the digital asset, and recording the receipt of the digital asset in the digital ledger with a signature that is unique to the recipient (e.g., a unique signature). This can be beneficial, for example, in ensuring the finality of the transaction (e.g., such that the transaction value cannot be transferred to others or "double spent" prior to being transferred to the recipient) by the recipient's own self-validation of proof of reception instead of external validation by third-party "miners" in proof of work and third-party "stakers" in proof of stake.”. Para. 235, a proposed transaction may include a transfer of a first value held by a first transaction node to a second transaction node, in exchange for a second value held by the second transaction node. Upon (on concurrently with) completion of the Transfer operations, the first transaction node and/or the second transaction node can record information regarding the completed transaction, i.e. creating the first self-validating digital record, in the distributed ledger 150, i.e., the first cryptographically secure network, or some other data storage medium (e.g., information confirming the completion of the transaction, the transferred value(s), the parties to the transaction, the time the transaction was performed, the location of the transaction, etc.). Para. 164, “the first computing node and the second computing node can transmit respective data blocks to the distributed transaction network 102, and the distributed transaction network 102 can store the blocks as additional blocks in a chain of blocks of the distributed ledger.”.).
Koh does not explicitly disclose in response to determining that the first validation requirement is met: compiling, at the first off-chain server, the first self-validating digital record and the first validation requirement in a first self-executing program, for a first cryptographically secure network, corresponding to the first self-validating digital record;
However, in the same field of endeavor, Madl discloses in response to determining that the first validation requirement is met: compiling, at the first off-chain server, the first self-validating digital record and the first validation requirement in a first self-executing program, for a first cryptographically secure network, corresponding to the first self-validating digital record (Para. 37, Smart contracts can be employed to automate parts of the cross-chain validation service. For example, to perform the cross-validation service, a user may send a blockchain address and a public key to an authority. A smart contract, i.e., a first self-executing program, can then be written that automatically takes this input data and generates the new block in the authority registry. Para. 49, The smart contract may include executable code which is registered, stored, and/or replicated with a blockchain (e.g., distributed network of blockchain peers). A transaction is an execution of the smart contract code which can be performed in response to conditions associated with the smart contract being satisfied, i.e., determining that the first validation requirement is met. Para. 46, “The blockchain configuration may include one or more applications 224 which are linked to application programming interfaces (APIs) 222 to access and execute stored program/application code 220 (e.g., chaincode, smart contracts, etc.) which can be created according to a customized configuration sought by participants and can maintain their own state, control their own assets, and receive external information. This can be deployed as a transaction and installed, via appending to the distributed ledger, on all blockchain nodes 204-210.”. Thus, in response to determining that the first validation requirement is met: compiling, at the first off-chain server, the first self-validating digital record and the first validation requirement in a first self-executing program corresponding to the first self- validating digital record.).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system of Koh by creating the smart contract such as the first self-executing program for the transaction record to be added to the blockchain as disclosed by Madl (Para. 46). A transaction is an execution of the smart contract code which can be performed in response to conditions associated with the smart contract being satisfied. Blockchain is utilized to provide a tamper-proof signature service and validation. One of the ordinary skills in the art would have motivated to make this modification in order to provide a tamper-proof service to validate the integrity of digital records via smart contracts as suggested by Madl (Para. 32).
As to claim 3, the claim is rejected for the same reasons as claim 2 above. In addition, Koh discloses determining based on the first self-executing program of the first self-validating digital record a first pre-deployment validation characteristic for the first validation requirement, wherein the first pre-deployment validation characteristic confirms that the first off-chain record is immobilized at a secure location (Para. 144, “this node can additionally lock the specified transaction value, such that the first node cannot transfer the transaction value to other nodes prior to the completion of the validation process”. Para. 243, “during each transaction, a transaction node (e.g., without any other third party, such as a neutral party), can (i) self-lock value held by the transaction node and/or (ii) lock value held by the other transaction node that is party to the transaction. Locking can be performed by preventing the transfer of value using the distributed ledger 150, using some other data storage (e.g., data stored on local or network storage), and/or using the data interface system 120. For example, locking can be performed by securing a bilateral connection between the two transaction nodes so each transaction node can lock the other transaction node's transaction value locally at each transaction node's storage ledger, on the distributed ledger, or elsewhere on some other system”.); and
determining, based on a second self-executing program of the first self-validating digital record, that the first pre-deployment validation characteristic corresponds to the first off-chain data (Para. 13, “a recipient of the digital asset can self-validate a transaction by confirming receipt of the digital asset, and recording the receipt of the digital asset in the digital ledger with a signature that is unique to the recipient (e.g., a unique signature). This can be beneficial, for example, in ensuring the finality of the transaction (e.g., such that the transaction value cannot be transferred to others or "double spent" prior to being transferred to the recipient) by the recipient's own self-validation of proof of reception instead of external validation by third-party "miners" in proof of work and third-party "stakers" in proof of stake.”. Thus, the first pre-deployment validation characteristic corresponds to the first off-chain data.).
As to claim 4, the claim is rejected for the same reasons as claim 3 above. In addition, Koh discloses detecting, by the first off-chain server, an instance of the first self-validating digital record on the first cryptographically secure network; and generating a communication to the secure location to release the first off-chain record to the second entity, wherein the communication comprises a digital signature for the secure location (Para. 237, “the Record operations can also be used to record a security signature, cryptographic key, "link signature," and/or biometric information of one or more of the parties to the transaction (also referred to as the parties "VITALS"). For example, using the Record operations, a transaction node 104 can record the security signature, cryptographic key, link signature, and/or biometric information of (i) the entity that is associated with the transaction node 104 and/or (ii) the entity with whom the transaction was performed.”. Para. 239, “the transaction node 104 can also add a signature unique to the second computing node (e.g., a PoR signature) to the distributed ledger to finalize the validation and indicate the finality of the transaction.”. Para. 240, “transaction nodes can provide each other with signatures concurrently and/or simultaneously as a part of the validation process.”. Thus, the communication comprises a digital signature for the secure location.).
As to claim 5, the claim is rejected for the same reasons as claim 2 above. In addition, Koh discloses further comprising: determining a secure location of the first off-chain record (Para. 176, “process 500, a second computing node transmits a first data record regarding the ownership of an asset for recordation to a distributed ledger (block 502). As an example, the first data record (e.g., a "PoRtion") can identify the asset, the location of the asset (e.g., in the case of a physical asset), the owner ( or owners) of the asset, and any other details regarding the asset.”.); and
determining the first validation requirement based on the secure location (Para. 217, “Validation operations can include (a) Store, (b) Search, (c) Lock, (d) Confirm, and (e) Prove.”. Para. 219, “(b) Search: These operations enable a transaction node 104 to search for specific values stored in the distributed ledger 150 and/or using some other storage medium. The search can be performed based on one or more criteria (e.g., categories of value, the amount of value, the time in which the value is available for transaction, the entity that is offering the value, the location associated with the value, etc.).”. Thus, determining the first validation requirement based on the secure location.).
As to claim 6, the claim is rejected for the same reasons as claim 2 above. In addition, Koh discloses determining an encoding format for a third self-executing program of the first self- validating digital record, wherein the third self-executing program is used to process the first off- chain data (Para. 13, “a recipient of the digital asset can self-validate a transaction by confirming receipt of the digital asset, and recording the receipt of the digital asset in the digital ledger with a signature that is unique to the recipient (e.g., a unique signature).”.); and
formatting the first off-chain data based on the encoding format (Para. 103, “the records of the distributed ledger 150 can cryptographically "wrap" digital assets that are not native to the distributed ledger 150, such that the digital asset can be transferred using the distributed ledger 150. For example, the distributed ledger 150 can record the generation and transfer of a first set of cryptographic tokens indicating ownership or control or another digital asset (e.g., a second set of cryptographic tokens that are not native to the distributed ledger 150).”. Para. 279, “The tokens can be traded with other entities (e.g., in a carbon market) and/or exchanged for other value (e.g., fiat currency, cryptocurrency, fungible tokens, nonfungible tokens, tax credits or deductions, etc.), such as in accordance with a proof of reception validation protocol.”.).
As to claim 7, the claim is rejected for the same reasons as claim 2 above. In addition, Koh discloses wherein confirming the transfer of the first off-chain record to the second entity by creating the first self-validating digital record on the first cryptographically secure network further comprises: determining, by a fourth self-executing program at the cross-network registry, that a second validation requirement for validating the first self-validating digital record prior to creation is required; determining, based on the fourth self-executing program, a second pre-deployment validation characteristic for the second validation requirement, wherein the second pre-deployment validation characteristic corresponds to a geographic restriction of transfers of the first off-chain record (Para. 294, “the smart contract can specify that the network resources be provided with respect to certain geographical areas (e.g., certain coverage areas of the satellites)”.);
retrieving second off-chain data, wherein the second off-chain data indicates a geographic location of the second entity (Para. 188, “Using a computing node, the entity can publicize details regarding the offered service on the distributed ledger, such as the identity of the service, an associated location or geographical area for that service”.); and
determining that the second pre-deployment validation characteristic corresponds to the second off-chain data (Para. 75, a first entity associated with a first computing node may wish to provide a first item or other property to a second entity associated with a second computing node, in exchange for a second item or other property from the second entity. To complete the transaction, the first computing node and the second computing node each validates one or more aspects of the transaction. For example, the second computing node can (i) verify that the first entity is in possession or otherwise controls the disposition of the first item or property and/or (ii) confirm the provenance of the first item or property. Further, the first computing node can (i) verify that the second entity is in possession or otherwise controls the disposition of the second item or property and/or (ii) confirm the provenance of the second item or property. Upon validating the transaction, the second computing node receives the specified first item or property, and the first computing node receives the specified second item or property, i.e., second off-chain data. Para. 17, “receiving, by a second computing node of a distributed transaction network, a data record from a first computing node of the distributed transaction network, where the data record includes: an indication of a proposed transaction, an indication of a transaction value associated with the proposed transaction, and an indication of a smart contract associated with the proposed transaction; validating, by the second computing node, the proposed transaction, wherein validating the proposed transaction comprises at least one of: determining that the first computing node is in possession of the transaction value, or determining that the second computing node satisfies one or more requirements specified by the smart contract; upon validating the proposed transaction: receiving, by the second computing node, the transaction value from the first computing node.”. Thus, the second pre-deployment validation characteristic corresponds to the second off-chain data.).
As to claim 8, the claim is rejected for the same reasons as claim 2 above. In addition, Koh discloses wherein confirming the transfer of the first off-chain record to the second entity by creating the first self-validating digital record on the first cryptographically secure network further comprises: determining, by a fourth self-executing program at the cross-network registry, that a second validation requirement for validating the first self-validating digital record prior to creation is required; determining, based on the fourth self-executing program, a second pre-deployment validation characteristic for the second validation requirement, wherein the second pre-deployment validation characteristic corresponds to a KYC restriction of transfers of the first off-chain record; retrieving second off-chain data, wherein the second off-chain data indicates a known customer number of the second entity; and determining that the second pre-deployment validation characteristic corresponds to the second off-chain data (Para. 75, a first entity associated with a first computing node may wish to provide a first item or other property to a second entity associated with a second computing node, in exchange for a second item or other property from the second entity. To complete the transaction, the first computing node and the second computing node each validates one or more aspects of the transaction. For example, the second computing node can (i) verify that the first entity is in possession or otherwise controls the disposition of the first item or property and/or (ii) confirm the provenance of the first item or property. Further, the first computing node can (i) verify that the second entity is in possession or otherwise controls the disposition of the second item or property and/or (ii) confirm the provenance of the second item or property. Upon validating the transaction, the second computing node receives the specified first item or property, and the first computing node receives the specified second item or property, i.e., second off-chain data. Para. 17, “receiving, by a second computing node of a distributed transaction network, a data record from a first computing node of the distributed transaction network, where the data record includes: an indication of a proposed transaction, an indication of a transaction value associated with the proposed transaction, and an indication of a smart contract associated with the proposed transaction; validating, by the second computing node, the proposed transaction, wherein validating the proposed transaction comprises at least one of: determining that the first computing node is in possession of the transaction value, or determining that the second computing node satisfies one or more requirements specified by the smart contract; upon validating the proposed transaction: receiving, by the second computing node, the transaction value from the first computing node.”. Thus, the second pre-deployment validation characteristic corresponds to the second off-chain data.).
As to claim 9, the claim is rejected for the same reasons as claim 2 above. In addition, Koh discloses wherein confirming the transfer of the first off-chain record to the second entity by creating the first self-validating digital record on the first cryptographically secure network further comprises: determining, by a fourth self-executing program at the cross-network registry, that a second validation requirement for validating the first self-validating digital record prior to creation is required; determining, based on the fourth self-executing program, a second pre-deployment validation characteristic for the second validation requirement, wherein the second pre-deployment validation characteristic corresponds to a temporal restriction of transfers of the first off-chain record; retrieving second off-chain data, wherein the second off-chain data indicates a current time; and determining that the second pre-deployment validation characteristic corresponds to the second off-chain data (Para. 223, a proposed transaction may include a transfer of a first value, i.e., first off-chain data, held by a first transaction node to a second transaction node, in exchange for a second value, i.e., second off-chain data, held by the second transaction node. The first transaction node can lock the second value held by the second transaction node (e.g., such that the second transaction node cannot transfer the value to another entity prior to the completion of the transaction). Further, the second transaction node can lock the first value held by the first transaction node (e.g., such that the first transaction node cannot transfer the value to another entity prior to the completion of the transaction). Para. 211, “FIGS. 6A and 6B, the first computing node can lock the advertised asset to the second node concurrently with transmitting a data record regarding acceptance of the modified transaction for the advertised asset to the second node (e.g., block 612). The lock can be configured such that the advertised asset can only be transferred to the first node (e.g., step 616) while the transaction is pending. The lock can be removed if the transaction is canceled by one or more of the computing nodes, or upon expiration of a specified amount of time (e.g., specified by the smart contract).”.).
As to claim 10, the claim is rejected for the same reasons as claim 2 above. In addition, Koh discloses wherein confirming the transfer of the first off-chain record to the second entity by creating the first self-validating digital record on the first cryptographically secure network further comprises: determining, by a fourth self-executing program at the cross-network registry, that a second validation requirement for validating the first self-validating digital record prior to creation is required; determining, based on the fourth self-executing program, a second pre-deployment validation characteristic for the second validation requirement, wherein the second pre-deployment validation characteristic corresponds to a network route restriction of transfers of the first off-chain record; retrieving second off-chain data, wherein the second off-chain data indicates a network route for the transfer of the first off-chain record; and determining that the second pre-deployment validation characteristic corresponds to the second off-chain data (Para. 227, “while the transaction node 104 is performing a transaction, the transaction node 104 can be restricted from initiating and/or performing any other transactions (e.g., until the completion or cancellation of the pending transaction). As another example, while the transaction node 104 is performing a transaction, the transaction node 104 can be restricted from conducting transactions with one or more other computing nodes prior to validation of the transaction.”. Para. 316, “a proof of reception validation protocol can be used to facilitate the exchange of data in a terrestrial communications network (e.g., a communications network that exchanges data using ground-based transmitters and/or receivers, such as a cellular network). As another example, a proof of reception validation protocol can be used to facilitate the exchange of data in a Vehicle-to-Vehicle (V2V) communications network (e.g., a communications network that exchanges data between vehicles). As another example, a proof of reception validation protocol can be used to facilitate the exchange of data in Mobile-to Mobile (M2M) communications network (e.g., a communications network that exchanges data between any type of mobile devices, such as vehicles, laptops, smartphones, wearable devices, tablet computers, etc.).”.).
As to claim 11, the claim is rejected for the same reasons as claim 2 above. In addition, Koh discloses wherein confirming the transfer of the first off-chain record to the second entity by creating the first self-validating digital record on the first cryptographically secure network further comprises: determining, by a fourth self-executing program at the cross-network registry, that a second validation requirement for validating the first self-validating digital record prior to creation is required; determining, based on the fourth self-executing program, a second pre-deployment validation characteristic for the second validation requirement, wherein the second pre-deployment validation characteristic corresponds to an asset type restriction of transfers of the first off-chain record; retrieving second off-chain data, wherein the second off-chain data indicates an asset type of the first off-chain record; and determining that the second pre-deployment validation characteristic corresponds to the second off-chain data (Para. 176, “a second computing node transmits a first data record regarding the ownership of an asset for recordation to a distributed ledger (block 502). As an example, the first data record (e.g., a "PoRtion") can identify the asset, the location of the asset (e.g., in the case of a physical asset), the owner (or owners) of the asset, and any other details regarding the asset.”. Thus, the second pre-deployment validation characteristic corresponds to an asset type restriction of transfers of the first off-chain record.).
As to claim 12, the claim is rejected for the same reasons as claim 2 above. In addition, Koh discloses wherein receiving, at the first off-chain server, the first self- validating digital record from the first entity further comprises: extracting, by the first off-chain server, implementation details for creating the first self- validating digital record; and generating the first validation requirement based on the implementation details (Para. 279, “the system 100 can be used to facilitate the exchange of tokens representing any value and/or service. As an example, a cryptocurrency system can generate tokens representing carbon credits or carbon offsets. For instance, each token can represent authorization (e.g., issued by an authority or regulator, such as a government and/or private entity) for the owner of the token to emit a certain amount of carbon dioxide or other greenhouse gases into the atmosphere. As an example, one token can permit the owner of the token to emit one ton of carbon dioxide or the equivalent in other greenhouse gases. In some implementations, an entity can be allotted a particular amount of tokens by an authority or regulator, either for free or in exchange for a particular amount of value (e.g., a carbon "tax" that places a price tag put on fossil fuel emissions to disincentivize their use and to promote a switch to green energy). The tokens can be traded with other entities (e.g., in a carbon market) and/or exchanged for other value (e.g., fiat currency, cryptocurrency, fungible tokens, nonfungible tokens, tax credits or deductions, etc.), such as in accordance with a proof of reception validation protocol.”.).
As to claim 13, the claim is rejected for the same reasons as claim 2 above. In addition, Koh discloses wherein providing the first self-validating digital record to the cross-network registry further comprises: retrieving, at the cross-network registry, a complier; and compiling a fifth self-executing program for creating the first self-validating digital record on the first cryptographically secure network (Para. 375, “A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages. A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.”. Para. 231, “a transaction node 104 can self-validate a transaction upon receiving the proposed value of the transaction.”. Para. 119, “the payment processor system 106 and/or the transaction nodes 104 can be implemented on one or more respective computing devices (e.g., each computing device including at least one processor such as a microprocessor or microcontroller).”. Thus, compiling a fifth self-executing program for creating the first self-validating digital record on the first cryptographically secure network.).
As to claim 14, Koh discloses one or more non-transitory, computer-readable mediums comprising instructions recorded thereon that when executed by one or more processors cause operations (Para. 58) comprising: receiving, at a cross-network registry, a first self-validating digital record, wherein the first self-validating digital record is validated by: receiving, at a first off-chain server, the first self-validating digital record from a first entity (Para. 16, a method includes receiving, by a second computing node of a distributed transaction network, a data record, i.e. a first self-validating digital record, from a first computing node, i.e. first entity, of the distributed transaction network, where the data record includes: an indication of a proposed transaction, an indication of a transaction value associated with the proposed transaction, and an indication of a smart contract associated with the proposed transaction.), wherein the first self-validating digital record corresponds to a first off-chain record designated by the first entity to be transferred to a second entity (Para. 13, a record indicating the transfer of a digital asset (e.g., an amount of cryptocurrency, non-fungible token, etc.) from a first party to a second party can itself constitute the transfer of ownership, i.e., first transfer, of the digital asset from the first party, i.e., first entity, to the second party, i.e., second entity.);
determining, by the first self-validating digital record, that the first validation requirement is met (Para. 354, “The second computing node validates the proposed transaction (block 904). Validating the proposed transaction includes at least one of: (i) determining that the first computing node is in possession of the transaction value, or (ii) determining that the second computing nodes satisfies one or more requirements specified by the smart contract.”. Para. 13, a recipient of the digital asset can self-validate a transaction, i.e., the first self-validating digital record, by confirming receipt of the digital asset and recording the receipt of the digital asset in the digital ledger with a signature that is unique to the recipient (e.g., a unique signature). This can be beneficial, for example, in ensuring the finality of the transaction (e.g., such that the transaction value cannot be transferred to others or "double spent" prior to being transferred to the recipient) by the recipient's own self-validation of proof of reception instead of external validation by third-party "miners" in proof of work and third-party "stakers" in proof of stake.); and
confirming, by the cross-network registry, transfer of the first off-chain record to the second entity by creating the first self-validating digital record on a first cryptographically secure network (Para. 13, “a recipient of the digital asset can self-validate a transaction by confirming receipt of the digital asset, and recording the receipt of the digital asset in the digital ledger with a signature that is unique to the recipient (e.g., a unique signature). This can be beneficial, for example, in ensuring the finality of the transaction (e.g., such that the transaction value cannot be transferred to others or "double spent" prior to being transferred to the recipient) by the recipient's own self-validation of proof of reception instead of external validation by third-party "miners" in proof of work and third-party "stakers" in proof of stake.”. Para. 235, a proposed transaction may include a transfer of a first value held by a first transaction node to a second transaction node, in exchange for a second value held by the second transaction node. Upon (on concurrently with) completion of the Transfer operations, the first transaction node and/or the second transaction node can record information regarding the completed transaction, i.e. creating the first self-validating digital record, in the distributed ledger 150, i.e., the first cryptographically secure network, or some other data storage medium (e.g., information confirming the completion of the transaction, the transferred value(s), the parties to the transaction, the time the transaction was performed, the location of the transaction, etc.). Para. 164, “the first computing node and the second computing node can transmit respective data blocks to the distributed transaction network 102, and the distributed transaction network 102 can store the blocks as additional blocks in a chain of blocks of the distributed ledger.”.).
Koh does not explicitly disclose wherein the first self-validating digital record and the first validation requirement are complied at the first off-chain server in response to determining that the first validation requirement is met;
However, in the same field of endeavor, Madl discloses wherein the first self-validating digital record and the first validation requirement are complied at the first off-chain server in response to determining that the first validation requirement is met (Para. 37, Smart contracts can be employed to automate parts of the cross-chain validation service. For example, to perform the cross-validation service, a user may send a blockchain address and a public key to an authority. A smart contract can then be written that automatically takes this input data and generates the new block in the authority registry. Para. 49, The smart contract may include executable code which is registered, stored, and/or replicated with a blockchain (e.g., distributed network of blockchain peers). A transaction is an execution of the smart contract code which can be performed in response to conditions associated with the smart contract being satisfied, i.e., determining that the first validation requirement is met. Para. 46, “The blockchain configuration may include one or more applications 224 which are linked to application programming interfaces (APIs) 222 to access and execute stored program/application code 220 (e.g., chaincode, smart contracts, etc.) which can be created according to a customized configuration sought by participants and can maintain their own state, control their own assets, and receive external information. This can be deployed as a transaction and installed, via appending to the distributed ledger, on all blockchain nodes 204-210.”. Thus, the first self-validating digital record and the first validation requirement are complied at the first off-chain server in response to determining that the first validation requirement is met.).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system of Koh by creating the smart contract such as the first self-executing program for the transaction record to be added to the blockchain as disclosed by Madl (Para. 46). A transaction is an execution of the smart contract code which can be performed in response to conditions associated with the smart contract being satisfied. Blockchain is utilized to provide a tamper-proof signature service and validation. One of the ordinary skills in the art would have motivated to make this modification in order to provide a tamper-proof service to validate the integrity of digital records via smart contracts as suggested by Madl (Para. 32).
As to claim 15, the claim is rejected for the same reasons as claim 14 above. In addition, Koh discloses wherein the operations further cause operations comprising: receiving first off-chain data; determining based on a first self-executing program of the first self-validating digital record a first pre-deployment validation characteristic for the first validation requirement, wherein the first pre-deployment validation characteristic confirms that the first off-chain record is immobilized at a secure location (Para. 144, “this node can additionally lock the specified transaction value, such that the first node cannot transfer the transaction value to other nodes prior to the completion of the validation process”. Para. 243, “during each transaction, a transaction node (e.g., without any other third party, such as a neutral party), can (i) self-lock value held by the transaction node and/or (ii) lock value held by the other transaction node that is party to the transaction. Locking can be performed by preventing the transfer of value using the distributed ledger 150, using some other data storage (e.g., data stored on local or network storage), and/or using the data interface system 120. For example, locking can be performed by securing a bilateral connection between the two transaction nodes so each transaction node can lock the other transaction node's transaction value locally at each transaction node's storage ledger, on the distributed ledger, or elsewhere on some other system”.); and
determining, based on a second self-executing program of the first self-validating digital record, that the first pre-deployment validation characteristic corresponds to the first off-chain data (Para. 13, “a recipient of the digital asset can self-validate a transaction by confirming receipt of the digital asset, and recording the receipt of the digital asset in the digital ledger with a signature that is unique to the recipient (e.g., a unique signature). This can be beneficial, for example, in ensuring the finality of the transaction (e.g., such that the transaction value cannot be transferred to others or "double spent" prior to being transferred to the recipient) by the recipient's own self-validation of proof of reception instead of external validation by third-party "miners" in proof of work and third-party "stakers" in proof of stake.”. Thus, the first pre-deployment validation characteristic corresponds to the first off-chain data.).
As to claim 16, the claim is rejected for the same reasons as claim 15 above. In addition, Koh discloses wherein the operations further cause operations comprising: detecting, by the first off-chain server, an instance of the first self-validating digital record on the first cryptographically secure network; and generating a communication to the secure location to release the first off-chain record to the second entity, wherein the communication comprises a digital signature for the secure location (Para. 237, “the Record operations can also be used to record a security signature, cryptographic key, "link signature," and/or biometric information of one or more of the parties to the transaction (also referred to as the parties "VITALS"). For example, using the Record operations, a transaction node 104 can record the security signature, cryptographic key, link signature, and/or biometric information of (i) the entity that is associated with the transaction node 104 and/or (ii) the entity with whom the transaction was performed.”. Para. 239, “the transaction node 104 can also add a signature unique to the second computing node (e.g., a PoR signature) to the distributed ledger to finalize the validation and indicate the finality of the transaction.”. Para. 240, “transaction nodes can provide each other with signatures concurrently and/or simultaneously as a part of the validation process.”. Thus, the communication comprises a digital signature for the secure location.).
As to claim 17, the claim is rejected for the same reasons as claim 14 above. In addition, Koh discloses wherein the operations further cause operations comprising: determining a secure location of the first off-chain record (Para. 176, “process 500, a second computing node transmits a first data record regarding the ownership of an asset for recordation to a distributed ledger (block 502). As an example, the first data record (e.g., a "PoRtion") can identify the asset, the location of the asset (e.g., in the case of a physical asset), the owner ( or owners) of the asset, and any other details regarding the asset.”.); and
determining the first validation requirement based on the secure location (Para. 217, “Validation operations can include (a) Store, (b) Search, (c) Lock, (d) Confirm, and (e) Prove.”. Para. 219, “(b) Search: These operations enable a transaction node 104 to search for specific values stored in the distributed ledger 150 and/or using some other storage medium. The search can be performed based on one or more criteria (e.g., categories of value, the amount of value, the time in which the value is available for transaction, the entity that is offering the value, the location associated with the value, etc.).”. Thus, determining the first validation requirement based on the secure location.).
As to claim 18, the claim is rejected for the same reasons as claim 14 above. In addition, Koh discloses wherein the operations further comprise: determining an encoding format for a third self-executing program of the first self- validating digital record, wherein the third self-executing program is used to process first off-chain data (Para. 13, “a recipient of the digital asset can self-validate a transaction by confirming receipt of the digital asset, and recording the receipt of the digital asset in the digital ledger with a signature that is unique to the recipient (e.g., a unique signature).”.); and
formatting the first off-chain data based on the encoding format (Para. 103, “the records of the distributed ledger 150 can cryptographically "wrap" digital assets that are not native to the distributed ledger 150, such that the digital asset can be transferred using the distributed ledger 150. For example, the distributed ledger 150 can record the generation and transfer of a first set of cryptographic tokens indicating ownership or control or another digital asset (e.g., a second set of cryptographic tokens that are not native to the distributed ledger 150).”. Para. 279, “The tokens can be traded with other entities (e.g., in a carbon market) and/or exchanged for other value (e.g., fiat currency, cryptocurrency, fungible tokens, nonfungible tokens, tax credits or deductions, etc.), such as in accordance with a proof of reception validation protocol.”.).
As to claim 19, the claim is rejected for the same reasons as claim 14 above. In addition, Koh discloses wherein the first self-validating digital record designates the first cryptographically secure network (Para. 228, “(d) Confirm: These operations enable a transaction node 104 to self-validate ownership (e.g., the provenance) of a proposed value for a transaction. In some implementations, these operations can include accessing the distributed ledger 150”. Para. 231, “a transaction node 104 can self-validate a transaction upon receiving the proposed value of the transaction. For example, if a transaction includes transmitting a particular proposed value to the transaction node 104, the transaction node 104 can validate the transaction upon receipt of that proposed value. Further upon validating the proposed transaction, the transaction node 104 can add a transaction record to a distributed ledger of the distributed transaction network to indicate receipt of the proposed value”. Thus, the first self-validating digital record designates the first cryptographically secure network.).
As to claim 20, the claim is rejected for the same reasons as claim 14 above. In addition, Koh discloses wherein the cross-network registry compiles the first self-validating digital record based on a protocol for the first cryptographically secure network (Para. 375, “A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages. A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.”. Para. 231, “a transaction node 104 can self-validate a transaction upon receiving the proposed value of the transaction.”. Para. 119, “the payment processor system 106 and/or the transaction nodes 104 can be implemented on one or more respective computing devices (e.g., each computing device including at least one processor such as a microprocessor or microcontroller.).”. Thus, the cross-network registry compiles the first self-validating digital record based on a protocol for the first cryptographically secure network.).
Conclusion
8. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Govindarajan et al. (US 2022/0329653 A1) teaches blockchain declarative descriptor for cross-network communication.
Chintala (US 2024/0177124 A1) teaches improving security surrounding the dispensation of digital assets by improving the manner in which digital assets are, validated and transferred.
CHOW et al. (US 2019/0081796 A1) teaches management of cryptographically secure exchange of data using permissioned distributed ledgers.
9. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOHAMMAD SOLAIMAN BHUYAN whose telephone number is (571)272-7843. The examiner can normally be reached on Monday - Friday 9:00am-5:00pm EST.
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, Charles Rones can be reached on 571-272-4085. The fax phone number for the organization where this application or proceeding is assigned is 571 -273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Mohammad S Bhuyan/Examiner, Art Unit 2168 /CHARLES RONES/Supervisory Patent Examiner, Art Unit 2168