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 .
Continuation Application
This Application is a continuation of US Application No. 16/642,842 and 18/410,830 filed on 02/27/2020 and 01/11/2024 now patent 12,026,710 and 12,493,877 (“Parent Application”). See MPEP § 201.07. In accordance with MPEP § 609.02 (II)(A)(2) and MPEP § 2001.06(b) (last paragraph), the Examiner has reviewed and considered the prior art cited in the Parent Application. Also, in accordance with MPEP § 2001.06(b) (last paragraph), all documents cited or considered ‘of record’ in the Parent Application are now considered cited or ‘of record’ in this application. Additionally, Applicant(s) is/are reminded that a listing of the information cited or ‘of record’ in the Parent Application need not be resubmitted in this application unless Applicant(s) desires the information to be printed on a patent issuing from this application. See MPEP § 609.02 (II)(A)(2).
Election/Restrictions
Applicant’s election without traverse of claims 1-14 and 16 in the reply filed on 08/19/2026 is acknowledged.
Claim 15 is withdrawn from further consideration pursuant to 37 CFR 1.142(b) as being drawn to a nonelected subcombination, there being no allowable generic or linking claim. Election was made without traverse in the reply filed on 08/19/2026.
Acknowledgements
This Office Action is in response to the claims filed on 08/19/2026.
Claims 1-16 were newly introduced.
Claim 15 was withdrawn.
Claims 1- 16 are pending.
Claims 1-14 and 16 were examined.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 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.
Claims 1-14 and 16 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-9 and 15 of U.S. Patent No. 12,493,877 B2. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims in the current Application represent a broader embodiment of the claims in the patent Application.
Current Application 19/358,964
US Patent US 12,493,877 B2
1.A computer-implemented method of processing blockchain transactions, comprising:
creating, at a node in a blockchain network, a blockchain transaction including a plurality of outputs, each output having a spendable value and a locking script;
including, in the locking script of each output, a set of constraints associated with a selected transaction output,
wherein the set of constraints is to be met by execution of a corresponding unlocking script of a spending blockchain transaction for the selected transaction output; and
at one or more verifying nodes of the blockchain network: processing the corresponding unlocking script with the locking script of the selected transaction output to produce a verification result indicating whether the selected transaction output satisfies the set of constraints; and
validating the spending blockchain transaction based at least in part on the verification result.
1. A computer-implemented method, comprising:
creating, at a node in a blockchain network, a first blockchain transaction, wherein the first blockchain transaction includes:
a first output having a first spendable value and a first locking script; and
a second output having a second spendable value and a second locking script;
including, in the first locking script, a first set of constraints on a first selected transaction output, wherein:
the first set of constraints are to be met by a first unlocking script if the first selected transaction output is to be valid for spending the first spendable value; and
including, in the second locking script, a second set of constraints on a second selected transaction output,
wherein the second set of constraints are to be met by a second unlocking script if the second selected transaction output is to be valid for spending the second spendable value, wherein:
the first set of constraints are to be met by execution, by a first verifying node of the blockchain network, of a first spending blockchain transaction having a first spending unlocking script; and
the second set of constraints are to be met by execution, by a second verifying node of the blockchain network, of a second spending blockchain transaction, distinct from the first spending blockchain transaction, having a second spending unlocking script;
at the first verifying node:
processing the first spending unlocking script with the first locking script to produce a verification result indicating whether the first spending transaction output satisfies the first set of constraints;
validating the first spending blockchain transaction based at least in part on the verification result; and
responsive to validating the first spending blockchain transaction, propagating the first spending blockchain transaction to other nodes in the blockchain network; and
at the second verifying node:
processing the second spending unlocking script with the second locking script to produce a second verification result indicating whether the second spending transaction output satisfies the second set of constraints;
validating the second spending blockchain transaction based at least in part on the second verification result; and
responsive to validating the second spending blockchain transaction, propagating the second spending blockchain transaction to other nodes in the blockchain network.
7.The method of claim 1, wherein the unlocking script corresponding to a first selected transaction output comprises fields of the blockchain transaction, fields of a first spending blockchain transaction, and fields of a second spending blockchain transaction, and wherein the locking script of the first selected transaction output comprises a first comparison of extracted fields of the blockchain transaction and a second comparison of extracted fields of the first spending blockchain transaction.
2. The method according to claim 1, wherein:
the first unlocking script comprises fields of the first blockchain transaction, fields of the first spending blockchain transaction, and fields of the second spending blockchain transaction; and
the first locking script comprises a first comparison of extracted fields of the first blockchain transaction and a second comparison of extracted fields of the first spending blockchain transaction.
8.The method of claim 1, wherein a first set of constraints associated with a first selected transaction output is distinct from a second set of constraints associated with a second selected transaction output and distinct from constraints on a transaction input of the blockchain transaction.
3. The method according to claim 1, wherein the first set of constraints is distinct from the second set of constraints and distinct from constraints on a transaction input of the first blockchain transaction.
9.The method of claim 1, wherein a first set of constraints associated with a first selected transaction output and a second set of constraints associated with a second selected transaction output each comprise a common set of constraints.
4. The method according to claim 1, wherein the first set of constraints and the second set of constraints each comprise a common set of constraints.
10.The method of claim 1, wherein a constraint on a locking script of a spending blockchain transaction requires that, for the spending blockchain transaction to be valid, the locking script of the spending blockchain transaction includes a reference to at least one field of the blockchain transaction.
5. The method according to claim 1, wherein a constraint on a locking script of the of the first spending blockchain transaction requires that, for the first spending blockchain transaction to be valid, the locking script of the first spending blockchain transaction is required to include a reference to at least one field of the spending transaction.
11.The method of claim 1, wherein a constraint on a locking script of a spending blockchain transaction requires that, for the spending blockchain transaction to be valid, the locking script of the spending blockchain transaction includes a copy of a portion of a locking script of the blockchain transaction.
6. The method according to claim 1, wherein a constraint on the locking script requires that, for the spending transaction to be valid, the locking script of the spending transaction is required to include a copy of a portion of the first locking script and/or a copy of a portion of the second locking script.
12.The method of claim 1, wherein a set of constraints comprises at least one of: a hash of a portion of a locking script of the blockchain transaction, or a constraint on a size of a portion of a locking script of the blockchain transaction.
7. The method of claim 1, wherein the first set of constraints and/or the second set of constraints comprises a hash of a portion of the first locking script and/or a hash of a portion of the second locking script, and/or a constraint on a size of a portion of the first locking script and/or a size of a portion of the second locking script.
13.The method of claim 1, wherein a set of constraints comprises an optional reference to input data.
8. The method of claim 1, wherein the first set of constraints and/or the second set of constraints comprise an optional reference to input data.
14.The method of claim 1, wherein each of the plurality of outputs of the blockchain transaction is constrained by a different constraint applied to outputs of the plurality of outputs.
9. The method of claim 1, wherein each of a plurality of outputs of the first blockchain transaction is constrained by a different constraint applied to outputs of the plurality of outputs.
16.A non-transitory computer-readable storage medium having stored thereon executable instructions that, as a result of being executed by one or more processors of a computer system, cause the computer system to perform the method of claim 1.
See claim 15 directed to a non-transitory computer-readable storage medium and corresponding in scope to claim 1.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-14 and 16 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
According to MPEP 2106 II, It is essential that the broadest reasonable interpretation (BRI) of the claim be established prior to examining a claim for eligibility. Further, MPEP 2103 I C establishes that the subject matter of a properly construed claim is defined by the terms that limit the scope of the claim when given their broadest reasonable interpretation. It is this subject matter that must be examined. Regarding the independent claim, claim 1 recites “a verification result indicating whether the selected transaction output satisfies the set of constraints”, language directed to non-functional descriptive material. See MPEP 2111.05.
With respect to the Eligibility Step 1 of the Alice/Mayo two-part test of the subject matter eligibility analysis (see MPEP 2106), in the instant case, claims 1-14 are directed to a method, and claim 16 are directed to a medium. Therefore, these claims fall within the four statutory categories of invention.
Following step 2A, prong one of the analysis, the language of the independent claims reciting an abstract idea are marked in bold below:
a. creating, at a node in a blockchain network, a blockchain transaction including a plurality of outputs, each output having a spendable value and a locking script;b. including, in the locking script of each output, a set of constraints associated with a selected transaction output, wherein the set of constraints is to be met by execution of a corresponding unlocking script of a spending blockchain transaction for the selected transaction output; andc. at one or more verifying nodes of the blockchain network: processing the corresponding unlocking script with the locking script of the selected transaction output to produce a verification result indicating whether the selected transaction output satisfies the set of constraints; andd. validating the spending blockchain transaction based at least in part on the verification result.
Therefore, the portions highlighted in bold above recite creating a contractual relationship, which is an abstract idea grouped within the certain methods of organizing human activity grouping of abstract ideas in prong one of step 2A. The claims are grouped within certain methods of organizing human activity creating a transaction including constraints, processing and validating the transaction. In situations like this where a series of steps recite judicial exceptions, examiners should combine all recited judicial exceptions and treat the claim as containing a single judicial exception for purposes of further eligibility analysis. See MPEP 2106.04 and 2106.05(II). Thus, the language identified in the certain methods of organizing human activity groupings were considered as a single abstract idea. Accordingly, the claims recite an abstract idea.
With respect to step 2A, prong two of the analysis, this judicial exception is not integrated into a practical application. Specifically, with respect to using nodes (i.e. node, verifying node) to perform the recited steps/functions, these additional elements performs the steps or functions such as: “creating… transaction…”, “including… constraints…”, “processing… script… to produce… result…”, “validating… transaction based… on… result”. These additional elements are recited at a high-level of generality such that it represents no more than mere instructions to apply the exception using a generic computer component, which only serves to use computers as a tool to perform the abstract idea. Therefore, these elements do not integrate the abstract idea into a practical application because they require no more than a computer performing functions that correspond to acts required to carry out the abstract idea. The additional element(s) of blockchain network amount to generally linking the use of the judicial exception to a particular technological environment or field of use.. Accordingly, 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. Therefore, following the analysis of step 2A, prong two, the claims are still directed to an abstract idea.
With respect to step 2B of the analysis, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract idea into a practical application, the additional computer elements, such as nodes (i.e. node, verifying node), blockchain network. The nodes (i.e. node, verifying node) perform the steps/functions of “creating… transaction…”, “including… constraints…”, “processing… script… to produce… result…”, “validating… transaction based… on… result”, and amount to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using generic computer components cannot provide an inventive concept beyond the abstract idea of creating a contractual relationship. The additional element(s) of blockchain network amount to generally linking the use of the judicial exception to a particular technological environment or field of use.. As discussed above, taking the claim elements separately, these additional elements perform the steps or functions that correspond to the actions required to perform the abstract idea. Viewed as a whole, the combination of elements recited in the claims merely recite the concept of creating a contractual relationship. Therefore, the independent claims are not eligible.
Examiner notes that, for elements recited in the dependent claims which were previously analyzed as additional elements of the independent claims above (i.e. nodes (i.e. node, verifying node)), the assessment of these elements under step 2A and step 2B for the dependent claims is inherited from the analysis of the independent claims and omitted for brevity, unless noted by Examiner below. Dependent claim 16 is directed to a non-transitory computer readable media to perform the method of claim 1, and is therefore not eligible as discussed above. Dependent claims 2-14 further recite the following additional language, in which elements which merely define the identified abstract idea are marked in bold below:
e) wherein the blockchain transaction includes a first output having a first spendable value and a first locking script and a second output having a second spendable value and a second locking script. f) wherein the first locking script includes a first set of constraints on a first selected transaction output, and the second locking script includes a second set of constraints on a second selected transaction output. g) wherein the first set of constraints is to be met by execution, at a first verifying node of the blockchain network, of a first spending blockchain transaction having a first unlocking script, and the second set of constraints is to be met by execution, at a second verifying node of the blockchain network, of a second spending blockchain transaction, distinct from the first spending blockchain transaction, having a second unlocking script. h) further comprising, at the first verifying node: validating the first spending blockchain transaction based at least in part on the verification result; and responsive to validation, propagating the first spending blockchain transaction to other nodes of the blockchain network. i) further comprising, at the second verifying node: validating the second spending blockchain transaction based at least in part on the second verification result; and responsive to validation, propagating the second spending blockchain transaction to other nodes of the blockchain network. j) wherein the unlocking script corresponding to a first selected transaction output comprises fields of the blockchain transaction, fields of a first spending blockchain transaction, and fields of a second spending blockchain transaction, and wherein the locking script of the first selected transaction output comprises a first comparison of extracted fields of the blockchain transaction and a second comparison of extracted fields of the first spending blockchain transaction. k) wherein a first set of constraints associated with a first selected transaction output is distinct from a second set of constraints associated with a second selected transaction output and distinct from constraints on a transaction input of the blockchain transaction. l) wherein a first set of constraints associated with a first selected transaction output and a second set of constraints associated with a second selected transaction output each comprise a common set of constraints. m) wherein a constraint on a locking script of a spending blockchain transaction requires that, for the spending blockchain transaction to be valid, the locking script of the spending blockchain transaction includes a reference to at least one field of the blockchain transaction. n) wherein a constraint on a locking script of a spending blockchain transaction requires that, for the spending blockchain transaction to be valid, the locking script of the spending blockchain transaction includes a copy of a portion of a locking script of the blockchain transaction. o) wherein a set of constraints comprises at least one of: a hash of a portion of a locking script of the blockchain transaction, or a constraint on a size of a portion of a locking script of the blockchain transaction. p) wherein a set of constraints comprises an optional reference to input data. q) wherein each of the plurality of outputs of the blockchain transaction is constrained by a different constraint applied to outputs of the plurality of outputs.
With respect to claim 2, the claim recites item e) above, language which does not introduce additional elements/functions. The additional language merely represents statements directed to directed to non-functional descriptive material by describing what the transaction "includes" (i.e. description of the data). Those statements are insufficient to significantly alter the eligibility analysis. This language further elaborates the abstract idea of creating a contractual relationship identified in the analysis of independent claims 1 and 16. Therefore, this language does not significantly alter the analysis with respect to the independent claims 1 and 16. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because no further additional elements/functions are introduced to the BRI of the claims. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because no further additional elements/functions are introduced to the BRI of the claims.
With respect to claim 3, the claim recites item f) above, language which does not introduce additional elements/functions. The additional language merely represents statements directed to directed to non-functional descriptive material by describing what each of the scripts "include" (i.e. description of the data). Those statements are insufficient to significantly alter the eligibility analysis. This language further elaborates the abstract idea of creating a contractual relationship identified in the analysis of independent claims 1 and 16. Therefore, this language does not significantly alter the analysis with respect to the independent claims 1 and 16. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because no further additional elements/functions are introduced to the BRI of the claims. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because no further additional elements/functions are introduced to the BRI of the claims.
With respect to claim 4, the claim recites item g) above, language which does not introduce additional elements/functions. The additional language merely represents statements directed to directed to intended use by describing that the constraints are "to be met" by execution of transactions. Those statements are insufficient to significantly alter the eligibility analysis. This language further elaborates the abstract idea of creating a contractual relationship identified in the analysis of independent claims 1 and 16. Therefore, this language does not significantly alter the analysis with respect to the independent claims 1 and 16. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because no further additional elements/functions are introduced to the BRI of the claims. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because no further additional elements/functions are introduced to the BRI of the claims.
With respect to claim 7, the claim recites item j) above, language which does not introduce additional elements/functions. The additional language merely represents statements directed to directed to non-functional descriptive material by describing what each of the scripts "comprise" (i.e. description of the data). Those statements are insufficient to significantly alter the eligibility analysis. This language further elaborates the abstract idea of creating a contractual relationship identified in the analysis of independent claims 1 and 16. Therefore, this language does not significantly alter the analysis with respect to the independent claims 1 and 16. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because no further additional elements/functions are introduced to the BRI of the claims. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because no further additional elements/functions are introduced to the BRI of the claims.
With respect to claim 8, the claim recites item k) above, language which does not introduce additional elements/functions. The additional language merely represents statements directed to directed to non-functional descriptive material by describing what the constraints are (i.e. description of what the data is "associated with" and "distinct" from). Those statements are insufficient to significantly alter the eligibility analysis. This language further elaborates the abstract idea of creating a contractual relationship identified in the analysis of independent claims 1 and 16. Therefore, this language does not significantly alter the analysis with respect to the independent claims 1 and 16. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because no further additional elements/functions are introduced to the BRI of the claims. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because no further additional elements/functions are introduced to the BRI of the claims.
With respect to claim 9, the claim recites item l) above, language which does not introduce additional elements/functions. The additional language merely represents statements directed to directed to non-functional descriptive material by describing what the constraints are (i.e. description of what the data is "associated with" and "comprise" - i.e. the description of the data). Those statements are insufficient to significantly alter the eligibility analysis. This language further elaborates the abstract idea of creating a contractual relationship identified in the analysis of independent claims 1 and 16. Therefore, this language does not significantly alter the analysis with respect to the independent claims 1 and 16. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because no further additional elements/functions are introduced to the BRI of the claims. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because no further additional elements/functions are introduced to the BRI of the claims.
With respect to claim 10, the claim recites item m) above, language which does not introduce additional elements/functions. The additional language merely represents statements directed to directed to non-functional descriptive material by describing what a constraint "requires" (i.e. description of the data). Those statements are insufficient to significantly alter the eligibility analysis. This language further elaborates the abstract idea of creating a contractual relationship identified in the analysis of independent claims 1 and 16. Therefore, this language does not significantly alter the analysis with respect to the independent claims 1 and 16. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because no further additional elements/functions are introduced to the BRI of the claims. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because no further additional elements/functions are introduced to the BRI of the claims.
With respect to claim 11, the claim recites item n) above, language which does not introduce additional elements/functions. The additional language merely represents statements directed to directed to non-functional descriptive material by describing what a constraint "requires" (i.e. description of the data). Those statements are insufficient to significantly alter the eligibility analysis. This language further elaborates the abstract idea of creating a contractual relationship identified in the analysis of independent claims 1 and 16. Therefore, this language does not significantly alter the analysis with respect to the independent claims 1 and 16. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because no further additional elements/functions are introduced to the BRI of the claims. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because no further additional elements/functions are introduced to the BRI of the claims.
With respect to claim 12, the claim recites item o) above, language which does not introduce additional elements/functions. The additional language merely represents statements directed to directed to non-functional descriptive material by describing what the constraint "comprises" (i.e. description of the data). Those statements are insufficient to significantly alter the eligibility analysis. This language further elaborates the abstract idea of creating a contractual relationship identified in the analysis of independent claims 1 and 16. Therefore, this language does not significantly alter the analysis with respect to the independent claims 1 and 16. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because no further additional elements/functions are introduced to the BRI of the claims. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because no further additional elements/functions are introduced to the BRI of the claims.
With respect to claim 13, the claim recites item p) above, language which does not introduce additional elements/functions. The additional language merely represents statements directed to directed to non-functional descriptive material by describing what the constraint "comprises" (i.e. description of the data). Those statements are insufficient to significantly alter the eligibility analysis. This language further elaborates the abstract idea of creating a contractual relationship identified in the analysis of independent claims 1 and 16. Therefore, this language does not significantly alter the analysis with respect to the independent claims 1 and 16. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because no further additional elements/functions are introduced to the BRI of the claims. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because no further additional elements/functions are introduced to the BRI of the claims.
With respect to claim 14, the claim recites item q) above, language which does not introduce additional elements/functions. The additional language merely represents statements directed to directed to non-functional descriptive material by describing what the description of outputs (i.e. what outputs are "constrained by"). Those statements are insufficient to significantly alter the eligibility analysis. This language further elaborates the abstract idea of creating a contractual relationship identified in the analysis of independent claims 1 and 16. Therefore, this language does not significantly alter the analysis with respect to the independent claims 1 and 16. The additional elements/functions, alone or in combination, are insufficient to integrate the abstract idea into a practical application because no further additional elements/functions are introduced to the BRI of the claims. The additional elements/functions, alone or in combination, do not offer significantly more than the abstract idea, because no further additional elements/functions are introduced to the BRI of the claims.
Therefore, while the additional language e) - g) and j) - q) of dependent claims 2-4, 7-14 slightly modify the analysis provided with respect to independent claim 1, these additional elements/functions are insufficient to render the dependent claims eligible, as detailed above. Therefore, these dependent claims are also ineligible.
With respect to claim 5, This language further elaborates the abstract idea of creating a contractual relationship identified in the analysis of independent claims 1 and 16. The additional elements/functions integrate the abstract idea into a practical application by applying the judicial exception in some other meaningful way. Therefore, claim 5 is eligible under step 2A of the analysis.
With respect to claim 6, This language further elaborates the abstract idea of creating a contractual relationship identified in the analysis of independent claims 1 and 16. The additional elements/functions integrate the abstract idea into a practical application by applying the judicial exception in some other meaningful way. Therefore, claim 6 is eligible under step 2A of the analysis.
Therefore, the additional language h) and i) of dependent claims 5 and 6 significantly alter the analysis provided with respect to independent Claim 1. These additional elements/functions are sufficient to render the dependent claims eligible, as detailed above. Therefore, dependent claims 5 and 6 are eligible.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 7 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 7 recites “the unlocking script corresponding to a first selected transaction output” in line 1. There is insufficient antecedent basis for this language in the claim.
Claim Rejections - 35 USC § 103
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.
Claims 1-14 and 16 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Wilson, JR. et al. (US 2016/0292680 A1), hereinafter Wilson in view of Antonopolous (NPL 2017).
With respect to claims 1 and 16, Wilson teaches a non-transitory computer-readable storage medium; and a computer-implemented method of processing blockchain transactions (Digital asset intermediary electronic settlement platform) comprising:
creating, at a node in a blockchain network, a blockchain transaction including a plurality of outputs, each output having a spendable value and a locking script (see Fig. 15, tx2, UTXO2.1 and UTXO2.2, paragraph [0103]: “Referring to FIG. 15, an exemplary staging of unused transaction outputs (“UTXOs”) for successful settlement process is shown.... Here, the seller notifies the digital asset intermediary electronic settlement platform server via using the trade entry tool of the indicative trade (1501). As is shown in FIG. 10, toggle for buy/sell, digital asset quantity (in the FIG. 10 example, BTC Amount), Price, and Counterparty are displayed. The seller reports quantity, price, and counterparty to the digital asset intermediary electronic settlement platform server. In the exemplary rights state shown in FIG. 14, the seller multi-signature wallet is staged for settlement (1104).”; Fig. 14, paragraph [0102]: "...The rights are split in the seller multi-signature wallet into two UTXO units: one UTXO unit will be used to settle a potential transaction; the other UTXO unit represents the remaining balance under control of the application. A new settlement state is entered (1401). The electronic settlement platform credit manager earmarks from the seller's balance and reserves rights for the impending transaction (1402). If the fund earmarking is denied (1403), then a declined state is entered (1405); if the rights are earmarked, then the seller settlement state becomes indicative (1404).”; paragraph [0104]: “In FIG. 15, the digital asset intermediary electronic settlement platform server creates and authorizes tx2, in which the input is UTXO1 and the outputs are UTXO2.1 and UTXO2.2 (1502). Both UTXO2.1 and UTXO2.2 destinations are to an address owned by the seller in the seller multi-signature application. The seller multi-signature application authorizes tx2 (1503). The seller multi-signature application generates hash of tx2, thus creating and sending txid(tx2) to the digital asset intermediary electronic settlement platform server (1504)...");
including, in the locking script of each output, a set of constraints associated with a selected transaction output, wherein the set of constraints is to be met by execution of a corresponding unlocking script of a spending blockchain transaction for the selected transaction output; and (see paragraph [0104]: “... The digital asset intermediary electronic settlement platform server uses txid(tx2) to generate and sign two redeem transactions (collectively, tx2.R) that will become valid in the future time frame (for example, +24 hours), and the digital asset intermediary electronic settlement platform server sends tx2.R to the seller multi-signature wallet (1505). The seller multi-signature application confirms tx2.R will be valid transactions in the time frame (for example, 24 hours) (1506). The seller multi-signature application sends tx2 to the digital asset intermediary electronic settlement platform server (1507). The digital asset intermediary electronic settlement platform server checks that tx2 is a valid transaction and broadcasts this to the blockchain (1508).”)
Wilson does not explicitly disclose a method and medium comprising: at one or more verifying nodes of the blockchain network: processing the corresponding unlocking script with the locking script of the selected transaction output to produce a verification result indicating whether the selected transaction output satisfies the set of constraints; and; and validating the spending blockchain transaction based at least in part on the verification result.
However, Antonopolous discloses a method and medium (Mastering Bitcoin, 2nd Edition) comprising:
at one or more verifying nodes of the blockchain network: processing the corresponding unlocking script with the locking script of the selected transaction output to produce a verification result indicating whether the selected transaction output satisfies the set of constraints; and (see page 132: "An unlocking script is a script that “solves,” or satisfies, the conditions placed on an output by a locking script and allows the output to be spent. Unlocking scripts are part of every transaction input. Most of the time they contain a digital signature producedby the user’s wallet from his or her private key. Historically, the unlocking script was called scriptSig, because it usually contained a digital signature. In most bitcoin applications, the source code refers to the unlocking script as scriptSig. You will also see the unlocking script referred to as a witness (see Appendix D). In this book, we refer to it as an “unlocking script” to acknowledge the much broader range of locking script requirements, because not all unlocking scripts must contain signatures. Every bitcoin validating node will validate transactions by executing the locking and unlocking scripts together. Each input contains an unlocking script and refers to a previously existing UTXO. The validation software will copy the unlocking script, retrieve the UTXO referenced by the input, and copy the locking script from that UTXO. The unlocking and locking script are then executed in sequence. The input is valid if the unlocking script satisfies the locking script conditions"; page 136: "First, the unlocking script is executed, using the stack execution engine. If then unlocking script is executed without errors (e.g., it has no “dangling” operators leftover), the main stack (not the alternate stack) is copied and the locking script is executed. If the result of executing the locking script with the stack data copied from the unlocking script is “TRUE,” the unlocking script has succeeded in resolving the conditions imposed by the locking script and, therefore, the input is a valid authorization to spend the UTXO. If any result other than “TRUE” remains after execution of the combined script, the input is invalid because it has failed to satisfy the spending conditions placed on the UTXO." See also "conditional clauses with VERIFY Opcodes", pages 165-166); and
validating the spending blockchain transaction based at least in part on the verification result. (see page 133: "All the inputs are validated independently, as part of the overall validation of the transaction. Note that the UTXO is permanently recorded in the blockchain, and therefore is invariable and is unaffected by failed attempts to spend it by reference in a new transaction. Only a valid transaction that correctly satisfies the conditions of the output results in the output being considered as “spent” and removed from the set of unspent transaction outputs (UTXO set).").
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the teachings as disclosed by Antonopolous in the method and medium of Wilson, the motivation being to allow tracking of tokens in the Bitcoin network (see Antonopolous, pages 115-117 and 133-134).
With respect to the BRI of the claims, Examiner notes that claim 1 recites “a verification result indicating whether the selected transaction output satisfies the set of constraints”, language directed to non-functional descriptive material. See MPEP 2111.05.
With respect to claim 2, the combination of Wilson and Antonopolous teaches all the subject matter of the method as described above with respect to claim 1. Furthermore, Antonopolous discloses a method wherein the blockchain transaction includes a first output having a first spendable value and a first locking script and a second output having a second spendable value and a second locking script (see page 46, "Vout" "n": 0, "value": 0.015000000, "scriptPubKey" for a first output, page 47 "Vout" "n": 1 "value": 0.008450000, "scriptPubKey" for a second output). Regarding the BRI of the claim, Examiner notes that claim 2 recites “wherein the blockchain transaction includes a first output having a first spendable value and a first locking script”; “a second output having a second spendable value and a second locking script.”, language directed to non-functional descriptive material. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 3, the combination of Wilson and Antonopolous teaches all the subject matter of the method as described above with respect to claim 2. Furthermore, Antonopolous discloses a method wherein the first locking script includes a first set of constraints on a first selected transaction output, and the second locking script includes a second set of constraints on a second selected transaction output (see page 46, "Vout" "n": 0, for a first output, page 47 "Vout" "n": 1 for a second output, page 158 Check Lock Time Verify (CLTV): "CLTV is a per output timelock, rather than a per-transaction timelock as is the case with nLocktime. This allows for much greater flexibility in the way timelocks are applied. In simple terms, by adding the CLTV opcode in the redeem script of an output it restricts the output, so that it can only be spent after the specified time has elapsed. CLTV doesn’t replace nLocktime, but rather restricts specific UTXO such that they can only be spent in a future transaction with nLocktime set to a greater or equal value."). Regarding the BRI of the claim, Examiner notes that claim 3 recites “the first locking script includes a first set of constraints on a first selected transaction output,”; “the second locking script includes a second set of constraints on a second selected transaction output”, language directed to non-functional descriptive material. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 4, the combination of Wilson and Antonopolous teaches all the subject matter of the method as described above with respect to claim 3. Furthermore, Antonopolous discloses a method wherein the first set of constraints is to be met by execution, at a first verifying node of the blockchain network, of a first spending blockchain transaction having a first unlocking script, and the second set of constraints is to be met by execution, at a second verifying node of the blockchain network, of a second spending blockchain transaction, distinct from the first spending blockchain transaction, having a second unlocking script (see page 46, "Vout" "n": 0, for a first output, page 47 "Vout" "n": 1 for a second output, page 158 Check Lock Time Verify (CLTV): "CLTV is a per output timelock, rather than a per-transaction timelock as is the case with nLocktime. This allows for much greater flexibility in the way timelocks are applied. In simple terms, by adding the CLTV opcode in the redeem script of an output it restricts the output, so that it can only be spent after the specified time has elapsed. CLTV doesn’t replace nLocktime, but rather restricts specific UTXO such that they can only be spent in a future transaction with nLocktime set to a greater or equal value." Examiner notes that in a sufficiently large, distributed network, outputs with distinct timelocks for each output are processed by distinct nodes at distinct times.). Regarding the BRI of the claim, Examiner notes that claim 4 is a method claim and recites “wherein the first set of constraints is to be met by execution, at a first verifying node …...”; “the second set of constraints is to be met by execution, at a second verifying node…...” language directed to not positively recited method steps. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 5, the combination of Wilson and Antonopolous teaches all the subject matter of the method as described above with respect to claim 4. Furthermore, Antonopolous discloses a method further comprising,
at the first verifying node: validating the first spending blockchain transaction based at least in part on the verification result (see page 158, "The CLTV opcode takes one parameter as input, expressed as a number in the same format as nLocktime (either a block height or Unix epoch time). As indicated by the VERIFY suffix, CLTV is the type of opcode that halts execution of the script if the outcome is FALSE. If it results in TRUE, execution continues."); and
responsive to validation, propagating the first spending blockchain transaction to other nodes of the blockchain network (see page 133: "All the inputs are validated independently, as part of the overall validation of the transaction. Note that the UTXO is permanently recorded in the blockchain, and therefore is invariable and is unaffected by failed attempts to spend it by reference in a new transaction. Only a valid transaction that correctly satisfies the conditions of the output results in the output being considered as “spent” and removed from the set of unspent transaction outputs (UTXO set)."). The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 6, the combination of Wilson and Antonopolous teaches all the subject matter of the method as described above with respect to claim 5. Furthermore, Antonopolous discloses a method further comprising, at the second verifying node:
validating the second spending blockchain transaction based at least in part on the second verification result (see page 158, "The CLTV opcode takes one parameter as input, expressed as a number in the same format as nLocktime (either a block height or Unix epoch time). As indicated by the VERIFY suffix, CLTV is the type of opcode that halts execution of the script if the outcome is FALSE. If it results in TRUE, execution continues."); and
responsive to validation, propagating the second spending blockchain transaction to other nodes of the blockchain network (see page 133: "All the inputs are validated independently, as part of the overall validation of the transaction. Note that the UTXO is permanently recorded in the blockchain, and therefore is invariable and is unaffected by failed attempts to spend it by reference in a new transaction. Only a valid transaction that correctly satisfies the conditions of the output results in the output being considered as “spent” and removed from the set of unspent transaction outputs (UTXO set)."). The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 7, the combination of Wilson and Antonopolous teaches all the subject matter of the method as described above with respect to claim 1. Furthermore, Wilson discloses a method wherein the unlocking script corresponding to a first selected transaction output comprises fields of the blockchain transaction, fields of a first spending blockchain transaction, and fields of a second spending blockchain transaction, and wherein the locking script of the first selected transaction output comprises a first comparison of extracted fields of the blockchain transaction and a second comparison of extracted fields of the first spending blockchain transaction (see paragraph [0104]: “In FIG. 15, the digital asset intermediary electronic settlement platform server creates and authorizes tx2, in which the input is utxo1 and the outputs are utxo2.1 and utxo2.2 (1502). Both utxo2.1 and utxo2.2 destinations are to an address owned by the seller in the seller multi-signature application. The seller multi-signature application authorizes tx2 (1503). The seller multi-signature application generates hash of tx2, thus creating and sending txid(tx2) to the digital asset intermediary electronic settlement platform server (1504). The digital asset intermediary electronic settlement platform server uses txid(tx2) to generate and sign two redeem transactions (collectively, tx2.R) that will become valid in the future time frame (for example, +24 hours), and the digital asset intermediary electronic settlement platform server sends tx2.R to the seller multi-signature wallet (1505). The seller multi-signature application confirms tx2.R will be valid transactions in the time frame (for example, 24 hours) (1506). The seller multi-signature application sends tx2 to the digital asset intermediary electronic settlement platform server (1507). The digital asset intermediary electronic settlement platform server checks that tx2 is a valid transaction and broadcasts this to the blockchain (1508).”;). Regarding the BRI of the claim, Examiner notes that claim 7 recites “wherein… script… comprises fields of the blockchain transaction, fields of a first spending blockchain transaction, and fields of a second spending blockchain transaction”; “wherein… script… comprises a first comparison of extracted fields of the blockchain transaction and a second comparison of extracted fields of the first spending blockchain transaction”, language directed to non-functional descriptive material. See MPEP 2111.05. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 8, the combination of Wilson and Antonopolous teaches all the subject matter of the method as described above with respect to claim 1. Furthermore, Wilson discloses a method wherein a first set of constraints associated with a first selected transaction output is distinct from a second set of constraints associated with a second selected transaction output and distinct from constraints on a transaction input of the blockchain transaction (see paragraph [0104]: “In FIG. 15, the digital asset intermediary electronic settlement platform server creates and authorizes tx2, in which the input is utxo1 and the outputs are utxo2.1 and utxo2.2 (1502). Both utxo2.1 and utxo2.2 destinations are to an address owned by the seller in the seller multi-signature application. The seller multi-signature application authorizes tx2 (1503). The seller multi-signature application generates hash of tx2, thus creating and sending txid(tx2) to the digital asset intermediary electronic settlement platform server (1504). The digital asset intermediary electronic settlement platform server uses txid(tx2) to generate and sign two redeem transactions (collectively, tx2.R) that will become valid in the future time frame (for example, +24 hours), and the digital asset intermediary electronic settlement platform server sends tx2.R to the seller multi-signature wallet (1505). The seller multi-signature application confirms tx2.R will be valid transactions in the time frame (for example, 24 hours) (1506). The seller multi-signature application sends tx2 to the digital asset intermediary electronic settlement platform server (1507). The digital asset intermediary electronic settlement platform server checks that tx2 is a valid transaction and broadcasts this to the blockchain (1508).”;). Regarding the BRI of the claim, Examiner notes that claim 8 recites “wherein a first set of constraints associated with a first selected transaction output is distinct from a second set of constraints associated with a second selected transaction output and distinct from constraints on a transaction input of the blockchain transaction”, language directed to non-functional descriptive material. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 9, the combination of Wilson and Antonopolous teaches all the subject matter of the method as described above with respect to claim 1. Furthermore, Wilson discloses a method wherein a first set of constraints associated with a first selected transaction output and a second set of constraints associated with a second selected transaction output each comprise a common set of constraints (see paragraph [0104]: “In FIG. 15, the digital asset intermediary electronic settlement platform server creates and authorizes tx2, in which the input is utxo1 and the outputs are utxo2.1 and utxo2.2 (1502). Both utxo2.1 and utxo2.2 destinations are to an address owned by the seller in the seller multi-signature application. The seller multi-signature application authorizes tx2 (1503). The seller multi-signature application generates hash of tx2, thus creating and sending txid(tx2) to the digital asset intermediary electronic settlement platform server (1504). The digital asset intermediary electronic settlement platform server uses txid(tx2) to generate and sign two redeem transactions (collectively, tx2.R) that will become valid in the future time frame (for example, +24 hours), and the digital asset intermediary electronic settlement platform server sends tx2.R to the seller multi-signature wallet (1505). The seller multi-signature application confirms tx2.R will be valid transactions in the time frame (for example, 24 hours) (1506). The seller multi-signature application sends tx2 to the digital asset intermediary electronic settlement platform server (1507). The digital asset intermediary electronic settlement platform server checks that tx2 is a valid transaction and broadcasts this to the blockchain (1508).”;). Regarding the BRI of the claim, Examiner notes that claim 9 recites “wherein a first set of constraints associated with a first selected transaction output and a second set of constraints associated with a second selected transaction output each comprise a common set of constraints”, language directed to non-functional descriptive material. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 10, the combination of Wilson and Antonopolous teaches all the subject matter of the method as described above with respect to claim 1. Furthermore, Wilson discloses a method wherein a constraint on a locking script of a spending blockchain transaction requires that, for the spending blockchain transaction to be valid, the locking script of the spending blockchain transaction includes a reference to at least one field of the blockchain transaction (see paragraph [0111]: “Referring back to FIG. 16, the digital asset intermediary electronic settlement platform server authorizes tx3 with inputs utxo 2.1, destination buyer multi-signature application, and output uxto3 (1602). This is also seen in FIG. 15 (1512). The digital asset intermediary electronic settlement platform server creates a hash of tx3, thus creating and sending txid(tx3) to the buyer multi-signature application (1603). The digital asset intermediary electronic settlement platform server sends a message to the member to transfer conventional currency from the buying member's account to the selling member's account at the same moment that the digital asset intermediary electronic settlement platform server broadcasts tx3 to the blockchain (1604). Movement of rights and funds is subject to member controls, and the members are notified that rights and funds have been requested to move. In the exemplary settlement states shown in FIG. 14, the matched state settles (1414) into a settled state (1416). A ‘declined’ state (1405) shows that a settlement has been identified as a bad transaction and refused by the digital asset intermediary electronic settlement platform and the attempted settlement does not advance beyond the attempt to report to the system via the trade entry tool. The digital asset intermediary electronic settlement platform cannot prevent the digital asset from moving if the transaction has both signatures, but in the manual process state (1417) the member can freeze the conventional currency from both sides of the transaction if the transaction comes under dispute for any reason.”). Regarding the BRI of the claim, Examiner notes that claim 10 recites “wherein a constraint on a locking script of a spending blockchain transaction requires that, for the spending blockchain transaction to be valid, the locking script of the spending blockchain transaction includes a reference to at least one field of the blockchain transaction”, language directed to non-functional descriptive material. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 11, the combination of Wilson and Antonopolous teaches all the subject matter of the method as described above with respect to claim 1. Furthermore, Wilson discloses a method wherein a constraint on a locking script of a spending blockchain transaction requires that, for the spending blockchain transaction to be valid, the locking script of the spending blockchain transaction includes a copy of a portion of a locking script of the blockchain transaction (see paragraph [0111]: “Referring back to FIG. 16, the digital asset intermediary electronic settlement platform server authorizes tx3 with inputs utxo 2.1, destination buyer multi-signature application, and output uxto3 (1602). This is also seen in FIG. 15 (1512). The digital asset intermediary electronic settlement platform server creates a hash of tx3, thus creating and sending txid(tx3) to the buyer multi-signature application (1603). The digital asset intermediary electronic settlement platform server sends a message to the member to transfer conventional currency from the buying member's account to the selling member's account at the same moment that the digital asset intermediary electronic settlement platform server broadcasts tx3 to the blockchain (1604). Movement of rights and funds is subject to member controls, and the members are notified that rights and funds have been requested to move. In the exemplary settlement states shown in FIG. 14, the matched state settles (1414) into a settled state (1416). A ‘declined’ state (1405) shows that a settlement has been identified as a bad transaction and refused by the digital asset intermediary electronic settlement platform and the attempted settlement does not advance beyond the attempt to report to the system via the trade entry tool. The digital asset intermediary electronic settlement platform cannot prevent the digital asset from moving if the transaction has both signatures, but in the manual process state (1417) the member can freeze the conventional currency from both sides of the transaction if the transaction comes under dispute for any reason.”;). Regarding the BRI of the claim, Examiner notes that claim 11 recites “wherein a constraint on a locking script of a spending blockchain transaction requires that, for the spending blockchain transaction to be valid, the locking script of the spending blockchain transaction includes a copy of a portion of a locking script of the blockchain transaction”, language directed to non-functional descriptive material. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 12, the combination of Wilson and Antonopolous teaches all the subject matter of the method as described above with respect to claim 1. Furthermore, Wilson discloses a method wherein a set of constraints comprises at least one of: a hash of a portion of a locking script of the blockchain transaction, or a constraint on a size of a portion of a locking script of the blockchain transaction (see paragraph [0104]: “In FIG. 15, the digital asset intermediary electronic settlement platform server creates and authorizes tx2, in which the input is utxo1 and the outputs are utxo2.1 and utxo2.2 (1502). Both utxo2.1 and utxo2.2 destinations are to an address owned by the seller in the seller multi-signature application. The seller multi-signature application authorizes tx2 (1503). The seller multi-signature application generates hash of tx2, thus creating and sending txid(tx2) to the digital asset intermediary electronic settlement platform server (1504). The digital asset intermediary electronic settlement platform server uses txid(tx2) to generate and sign two redeem transactions (collectively, tx2.R) that will become valid in the future time frame (for example, +24 hours), and the digital asset intermediary electronic settlement platform server sends tx2.R to the seller multi-signature wallet (1505). The seller multi-signature application confirms tx2.R will be valid transactions in the time frame (for example, 24 hours) (1506). The seller multi-signature application sends tx2 to the digital asset intermediary electronic settlement platform server (1507). The digital asset intermediary electronic settlement platform server checks that tx2 is a valid transaction and broadcasts this to the blockchain (1508).”;). Regarding the BRI of the claim, Examiner notes that claim 12 recites “wherein a set of constraints comprises at least one of: a hash of a portion of a locking script of the blockchain transaction, or a constraint on a size of a portion of a locking script of the blockchain transaction.”, language directed to non-functional descriptive material. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 13, the combination of Wilson and Antonopolous teaches all the subject matter of the method as described above with respect to claim 1. Furthermore, Wilson discloses a method wherein a set of constraints comprises an optional reference to input data (see paragraph [0104]: “In FIG. 15, the digital asset intermediary electronic settlement platform server creates and authorizes tx2, in which the input is utxo1 and the outputs are utxo2.1 and utxo2.2 (1502). Both utxo2.1 and utxo2.2 destinations are to an address owned by the seller in the seller multi-signature application. The seller multi-signature application authorizes tx2 (1503). The seller multi-signature application generates hash of tx2, thus creating and sending txid(tx2) to the digital asset intermediary electronic settlement platform server (1504). The digital asset intermediary electronic settlement platform server uses txid(tx2) to generate and sign two redeem transactions (collectively, tx2.R) that will become valid in the future time frame (for example, +24 hours), and the digital asset intermediary electronic settlement platform server sends tx2.R to the seller multi-signature wallet (1505). The seller multi-signature application confirms tx2.R will be valid transactions in the time frame (for example, 24 hours) (1506). The seller multi-signature application sends tx2 to the digital asset intermediary electronic settlement platform server (1507). The digital asset intermediary electronic settlement platform server checks that tx2 is a valid transaction and broadcasts this to the blockchain (1508).”;). Regarding the BRI of the claim, Examiner notes that claim 13 recites “wherein a set of constraints comprises an optional reference to input data.”, language directed to non-functional descriptive material. The motivation for combining the references remain unaltered from the motivation described above in conjunction with the rejection of the independent claims.
With respect to claim 14, the combination of Wilson and Antonopolous teaches all the subject matter of the method as described above with respect to claim 1. Furthermore, Wilson discloses a method wherein each of the plurality of outputs of the blockchain transaction is constrained by a different constraint applied to outputs of the plurality of outputs (see Fig. 16, paragraph [0112]: “In the exemplary funds states shown in FIG. 11, the buyer's multi-signature rights are staged for settlement (1106). Back to FIG. 16, the buyer multi-signature application now contains utxo3 with tx3.R that contains an active settlement system settlement balance of a single digital asset for the time frame (for example, 24 hours) (1605). The seller multi-signature application now contains utxo2.2 with tx2.R that contains an active settlement system settlement balance of digital assets (for example, 99) for the time frame (for example, 24 hours) (1606).”).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Non-Patent Literature
Ali et al. (NPL 2021, listed in PTO-892 as page 1, reference "X") disclose A Secure and Efficient Multi-Factor Authentication Algorithm for Mobile Money Applications., including transaction scripts.
Patent Literature
Finlow-Bates (US 2016/0283939 A1) discloses system and method to prevent loss of bitcoins due to address errors, including a method for determining whether a transaction message of a digital currency system is valid.
Middleton et al. (US 2017/0187535 A1) disclose devices, systems, and methods for facilitating low trust and zero trust value transfers, including a transaction having multiple outputs, allowing one to make multiple payments in one go.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EDUARDO D CASTILHO whose telephone number is (571)270-1592. The examiner can normally be reached Mon-Fri 8-5.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patrick McAtee can be reached at (571) 272-7575. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/EDUARDO CASTILHO/
Primary Examiner, Art Unit 3698
