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 .
Continued Examination Under 37 CFR 1.114
2. A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on January 29th 2026 has been entered.
Response to Amendment
3. The Amendment filed on January 29th 2026 has been entered. Claims 1, 3, 24, 25 and 30 have been amended, claims 4 – 7, 9, 17 – 18, 20 – 22 and 26 have been cancelled from consideration and claim 31 newly added. Claims 1 – 3, 8, 10 – 16, 19, 23 – 25 and 27 - 31 are pending in the application.
Response to Arguments
35 U.S.C. §103
4. Applicant's arguments, see Remarks pp. 9 -13, filed November 2, 2018, with
respect to the rejections of claims 1-20 under 35 U.S.C. §103 have been fully
considered but they are/not persuasive.
Applicant argues that the cited art fail to teach applicants following steps defined in claim 1, “adding, by the smart contracts, output items to the smart transaction during execution of the calls of the smart contracts; and adding, by the smart contracts, output items to a coinbase transaction of a current block during execution of the calls of the smart contracts; wherein each output item comprises a token which is a representation of values;”
Examiner respectfully agrees
Regarding claim 3, applicant argues that Furukawa and Lancashire either alone or in combination fails to teach applicant’s following steps defined in claim 3, “A. spending instruction; the method for interpreting and executing the spending instruction by the virtual machine comprising: adding input items to a smart transaction; B. delivery instruction; the method for interpreting and executing the delivery instruction by said virtual machine comprising: adding first output items to the smart transaction; and C. mint instruction; the method for interpreting and executing said mint instruction by said virtual machine comprising: adding second output items to a coinbase transaction; wherein the virtual machine is a program that interprets and executes smart contract instructions; wherein each output item comprises a token which is a representation of values.”
Examiner respectfully agrees
Regarding claim 30 applicant argues that none of cited prior arts teach the limitations, especially the geometric tokens, and monodromy tokens
Examiner agrees that the cited art does not disclose geometric tokens, and monodromy tokens
Upon further consideration new grounds of rejection have been necessitated due
to Applicant's amendments and are made in view of So et al. (United States Patent Number 11,139,955), hereinafter So.
Claim Rejections - 35 USC § 112
5. 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.
6. Claims 1, 2, 10, 12, 14, 19, 23, 25, 27, 28 and 29 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention. Claim 1 disclose “adding, by the smart contracts, output items to the smart transaction during execution of the calls of the smart contracts; and adding, by the smart contracts, output items to a coinbase transaction of a current block during execution of the calls of the smart contracts;” It is unclear whether the “output items” added to the smart transaction are the same “output items” added to the coinbase transaction. Dependent claims 2, 10, 12, 14, 19, 23, 25, 27, 28 and 29 inherit the same defect.
Claim 8 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 pre-AIA the applicant regards as the invention. Claim 8 discloses, “The blockchain smart contract method of claim 3,” whilst claim 3 discloses, “A virtual machine method for blockchain smart contract” There is no antecedent basis for claim 8. Applicant’s attention to the matter is desired.
Dependent claim inherits the same deficit and is rejected accordingly.
Claim Rejection – 35 U.S.C. 102
7. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
8. 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.
Claims 1 – 3, 8, 10 – 16, 19, 23 – 25 and 27 - 31 are rejected under 35 U.S.C. 102(a)(1)/(a)(2) as being anticipated by So et al. (United States Patent Number 11,139,955), hereinafter So.
Regarding claim 1 So teaches a blockchain smart contract method, (Fig. 57A method for conducting a block trade order of a digital asset (e .g., BTC) on a digital asset exchange computer system Col 234 ln 65 – 67, Col 235 ln 1) comprising the following steps: S2. a node (“speaker” node selected from bookkeeping nodes Col 24 ln 56 – 59) executing all calls of smart contracts (calls from ERC20Proxy 6410, ERC20Impl 6420, and ERC20Store 6430, respectively Col 31 ln 4 – 19), (Custodian 6450 Col 31 ln 20 – 25), (Fig. 68 e.g., smart contract address 6805A Col 96 ln 31) (smart contract address 6807 A Col 96 ln 32) (calls to one or more other smart contracts having their own smart contract addresses Col 96 ln 36 - 37) in a smart transaction; (Fig. 57 a block trade order of a digital asset (e .g., BTC) Col 234 ln 67) such as a “smart transaction” which further comprising at least one of the following steps: adding, (store Col 40 ln 9) such as “adding” by the smart contracts, (ERC20Proxy 6410, ERC20Impl 6420, and ERC20Store 6430, respectively Col 31 ln 4 – 19), (Custodian 6450 Col 31 ln 20 – 25) (Fig. 68 e.g., smart contract address 6805A Col 96 ln 31) (smart contract address 6807 A Col 96 ln 32) output items (digital outputs … 15 BTC of which will be a spent output that is sent to the desired destination and 5 BTC of which will be an unspent output Col 40 ln 13 - 25) to the smart transaction (Fig. 57 a block trade order of a digital asset (e .g., BTC) Col 234 ln 67) such as a “smart transaction” during execution of the calls of the smart contracts; (calls from ERC20Proxy 6410, ERC20Impl 6420, and ERC20Store 6430, respectively Col 31 ln 4 – 19), (Custodian 6450 Col 31 ln 20 – 25) SEE EXAMPLE execution of the prospective sell order Col 118 ln 39 and adding, (store Col 40 ln 9) such as “adding” by the smart contracts, (ERC20Proxy 6410, ERC20Impl 6420, and ERC20Store 6430, respectively Col 31 ln 4 – 19), (Custodian 6450 Col 31 ln 20 – 25) (Fig. 68 e.g., smart contract address 6805A Col 96 ln 31) (smart contract address 6807 A Col 96 ln 32) output items (digital outputs … 15 BTC of which will be a spent output that is sent to the desired destination and 5 BTC of which will be an unspent output Col 40 ln 13 - 25) to a coinbase transaction (if a first digital asset account is initially empty and receives a transaction output of 20 BTC ( a bitcoin unit) from a second digital asset account, the first account then stores that 20 BTC output for future use as a transaction input Col 40 ln 16 - 19) such as “coinbase transaction” SEE ALSO a new addition to a ledger can create or reflect creation of one or more newly minted digital assets, such as bitcoin Col 42 ln 1 – 3; SEE EXAMPLE FIG 3 illustrates an exemplary Coinbase website interface for buying bitcoin. Col 52 ln 39 - 40 of a current block (new block Col 25 ln 23, Col 40 ln 67, Col 165 ln 21) such as “current block” during execution of the calls of the smart contracts; (calls from ERC20Proxy 6410, ERC20Impl 6420, and ERC20Store 6430, respectively Col 31 ln 4 – 19), (Custodian 6450 Col 31 ln 20 – 25) SEE EXAMPLE execution of the prospective sell order Col 118 ln 39 wherein each output item (digital outputs Col 40 ln 13) comprises a token (SVCoin tokens Col 69 ln 4) which is a representation of values; (the Stable Value Tokens may be created in batches (for example, 100,000 SVCoins worth $100,000 U.S. dollars)Col 28 ln 45 - 50) S3. the node (a verifier 160, which may confirm other miners' work. A verifier 160 may be one or more computers, software, or specialized device, to name a few Col 41 ln 50 - 52) validating legitimacy (At step S5606, the digital asset exchange computer system 3230 may verify that the first block trade order qualifies as a legitimate transaction Col 238 ln 29 - 31) of the smart transaction, (Fig. 57 a block trade order of a digital asset (e .g., BTC) Col 234 ln 67) such as a “smart transaction” which comprises verifying integrity (In Step S6006, if the request is verified the transaction is published in the Security Token database of the blockchain reflecting a debit against Alice's token holdings and a corresponding credit to Bob's token holdings (less any applicable fees). In Step S6008, response messages to the digital asset addresses of both Alice and Bob may be sent to reflect that the transaction was successfully processed. Col 37 ln 21 - 28) of the smart transaction (Fig. 57 a block trade order of a digital asset (e .g., BTC) Col 234 ln 67) such as a “smart transaction” after completion of execution of all the calls of the smart contracts; (calls from ERC20Proxy 6410, ERC20Impl 6420, and ERC20Store 6430, respectively Col 31 ln 4 – 19), (Custodian 6450 Col 31 ln 20 – 25) SEE EXAMPLE execution of the prospective sell order Col 118 ln 39 and S4. the node (“citizens” anyone of delegates of the bookkeeping nodes Col 24 ln 60 – 65) rejecting (rejecting opportunity to transact Col 241 ln 34 - 37)the smart transaction (Fig. 57 a block trade order of a digital asset (e .g., BTC) Col 234 ln 67) such as a “smart transaction” under the circumstance that a validation result (In embodiments, the digital asset exchange computer system 3230 may verify the validity of each response by each market maker received during the available time period, and only validated responses may be considered. Col 240 ln 4 - 7) indicates that the smart transaction(Fig. 57 a block trade order of a digital asset (e .g., BTC) Col 234 ln 67) such as a “smart transaction” is not legitimate; (In embodiments, a response which offers a bid that is outside the collar may be rejected. In embodiments, a response which offers an amount outside of the authorized amount for the respective market maker may also be rejected. In embodiments, a response which is not for a least an acceptable minimum amount may also be rejected. In embodiments, a response for an amount of digital assets greater than the indication of interest may also be rejected, and/or applied as if it were for the amount of digital assets included in the indication of interest. Col 240 ln 4 - 17) wherein under the circumstance that the smart transaction (Fig. 57 a block trade order of a digital asset (e .g., BTC) Col 234 ln 67) such as a “smart transaction” is submitted by a user, (market maker may be an exchange user Col 56 ln 11 – 12) rejecting (rejecting opportunity to transact Col 241 ln 34 - 37) the smart transaction (Fig. 57 a block trade order of a digital asset (e .g., BTC) Col 234 ln 67) such as a “smart transaction” means to discard the smart transaction; (in which case the block trade fails. Col 241 ln 2 – 3) and under the circumstance that the smart transaction(Fig. 57 a block trade order of a digital asset (e .g., BTC) Col 234 ln 67) such as a “smart transaction” is one of the transactions in a block (amalgamated transactions Col 25 ln 11) transmitted by another node, (“citizens” anyone of delegates of the bookkeeping nodes Col 24 ln 60 – 65) rejecting (rejecting opportunity to transact Col 241 ln 34 - 37) the smart transaction (Fig. 57 a block trade order of a digital asset (e .g., BTC) Col 234 ln 67) such as a “smart transaction” means not to add the block into a blockchain (If the delegates do not give their approval, the block is not added Col 24 ln 67; Col 25 ln 1 - 8)
Regarding claim 2 So teaches the blockchain smart contract method (Fig. 57A method for conducting a block trade order of a digital asset (e .g., BTC) on a digital asset exchange computer system Col 234 ln 65 – 67, Col 235 ln 1) of claim 1,
So further teaches wherein said node(“speaker” node selected from bookkeeping nodes Col 24 ln 56 – 59) invokes a virtual machine (Ethereum virtual machine Col 27 ln 20 - 21) to execute said calls of said smart contracts (allows smart contracts to be run, Col 27 ln 18 - 21) and the virtual machine (Ethereum virtual machine Col 27 ln 20 - 21) interprets and executes programs of said smart contracts, (The side chain can share miners with the Bitcoin blockchain and allows smart contracts to be run, such as contracts using the Ethereum virtual machine Col 27 ln 18 - 21) wherein the virtual machine (Ethereum virtual machine Col 27 ln 20 - 21) is a program that interprets and executes smart contract instructions (decentralized virtual currency and blockchain network with a programming language that can automatically facilitate, verify, and enforce the terms of a digital contract entered into by human or computer counterparties Col 43 ln 27 – 31)
Regarding claim 3 So teaches a virtual machine method (Ethereum virtual machine Col 27 ln 20 - 21) for blockchain smart contract, (smart contracts Col 27 ln 18 - 21) wherein an instruction set (the use of two way peg with a sidechain Col 27 ln 17 – 19) of a virtual machine (Ethereum virtual machine Col 27 ln 20 - 21) consists of at least one of the following three instructions: A. spending instruction; the method for interpreting and executing the spending instruction by the virtual machine comprising: adding input items to a smart transaction; B. delivery instruction; (procedures for the creation and redemption of baskets of trust shares and for the delivery of the digital math-based assets, e.g., Bitcoin, Ethereum … Col 151 ln 64 - 67 – Col 152 ln 1) the method for interpreting and executing the delivery instruction(procedures for the creation and redemption of baskets of trust shares and for the delivery of the digital math-based assets, e.g., Bitcoin, Ethereum … Col 151 ln 64 - 67 – Col 152 ln 1) by said virtual machine (Ethereum virtual machine Col 27 ln 20 - 21) comprising: adding (store Col 40 ln 9) such as “adding” first output items(any combination of multiple digital outputs … 15 BTC of which will be a spent output that is sent to the desired destination and 5 BTC of which will be an unspent output Col 40 ln 13 - 26) t to the smart transaction; (Fig. 57 a block trade order of a digital asset (e .g., BTC) Col 234 ln 67) such as a “smart transaction” and C. mint instruction; the method for interpreting and executing said mint instruction by said virtual machine comprising: adding second output items to a coinbase transaction; wherein the virtual machine (Ethereum virtual machine Col 27 ln 20 - 21) is a program that interprets and executes smart contract instructions; (allows smart contracts to be run, such as contracts using the Ethereum virtual machine Col 27 ln 18 - 21) wherein each output item (digital outputs Col 40 ln 13) comprises a token (SVCoin tokens Col 69 ln 4) which is a representation of values (the Stable Value Tokens may be created in batches (for example, 100,000 SVCoins worth $100,000 U.S. dollars)Col 28 ln 45 - 50)
Regarding claim 8 So teaches the blockchain smart contract method (Fig. 57A method for conducting a block trade order of a digital asset (e .g., BTC) on a digital asset exchange computer system Col 234 ln 65 – 67, Col 235 ln 1) of claim 3,
So further teaches the method for executing said spending instruction (spending transaction Col 71 ln 50 – 53) by said virtual machine (Ethereum virtual machine Col 27 ln 20 - 21)comprising a step verifying (verifying Col 59 ln 10 – 18) that said input items (digital inputs Col 71 ln 49 – 52) are owned (the digital asset seller may transfer digital assets to a digital wallet associated with ( e.g., owned by and/or operated by) the exchange. The exchange may hold such funds in escrow until the buyer's payment is received, e.g. into a bank account (for fiat currencies) or into a digital wallet (for other digital assets). Col 42 ln 45 - 52) SEE ALSO proof of work and proof of stake Col 42 ln 34 - 65 by said smart contract, (ERC20Proxy 6410, ERC20Impl 6420, and ERC20Store 6430, respectively Col 31 ln 4 – 19), (Custodian 6450 Col 31 ln 20 – 25) (Fig. 68 e.g., smart contract address 6805A Col 96 ln 31) wherein said input items (digital inputs Col 71 ln 49 – 52)are contained in data (combination of outputs Col 40 ln 25 – 26) of said spending instruction (spending transaction Col 40 ln 26; Col 71 ln 50 – 53)and only under the circumstance that a result of the verification is affirmative, (At step S5606, the digital asset exchange computer system 3230 may verify that the first block trade order qualifies as a legitimate transaction Col 238 ln 29 - 31) adding (store Col 40 ln 9) such as “adding” said input items (digital inputs Col 71 ln 49 – 52)to said smart transaction (Fig. 57 a block trade order of a digital asset (e .g., BTC) Col 234 ln 67) such as a “smart transaction”
Regarding claim 10 So teaches a blockchain system (blockchain system Co 50 ln 45 – 50) comprising a plural number of nodes (The blockchain recognized by the
nodes corresponding to the majority of computing power, or some other consensus mechanism will become the accepted Col 23 ln 60 – 65) and a plural number of terminals; (participant user devices Col 164 ln 25 – 30) a terminal (authorized participant user devices Col 164 ln 65) is configured to transmit (Fig. 33 S5026 transmit Col 18 ln 60 - 65) a smart transaction (Fig. 57 a block trade order of a digital asset (e .g., BTC) Col 234 ln 67) such as a “smart transaction” to one of said nodes; (nodes corresponding to the majority of computing power, Col 23 ln 60 - 65) a node (a node Col 25 ln 20 – 25) is configured to transmit(Fig. 33 S5026 transmit Col 18 ln 60 - 65) a block to (a block to Col 23 ln 28 – 30) another of said nodes; (nodes corresponding to the majority of computing power, Col 23 ln 60 – 65) said nodes (nodes corresponding to the majority of computing power, Col 23 ln 60 - 65) are configured to perform (perform Col 27 ln 46) a blockchain smart contract method (Fig. 57A method for conducting a block trade order of a digital asset (e .g., BTC) on a digital asset exchange computer system Col 234 ln 65 – 67, Col 235 ln 1) according to claim 1 when receiving (receiving Col 56 ln 36) a smart transaction (Fig. 57 a block trade order of a digital asset (e .g., BTC) Col 234 ln 67) such as a “smart transaction” or a block.
Regarding claim 11 a blockchain system (blockchain system Co 50 ln 45 – 50) comprising a plural number of nodes (nodes corresponding to the majority of computing power, Col 23 ln 60 – 65) and a plural number of terminals; (participant user devices Col 164 ln 25 – 30) a terminal (authorized participant user devices Col 164 ln 65)is configured to transmit(Fig. 33 S5026 transmit Col 18 ln 60 - 65) a smart transaction (Fig. 57 a block trade order of a digital asset (e .g., BTC) Col 234 ln 67) such as a “smart transaction” to one of said nodes; (nodes corresponding to the majority of computing power, Col 23 ln 60 – 65) a node(a node Col 25 ln 20 – 25) is configured to transmit (Fig. 33 S5026 transmit Col 18 ln 60 - 65) a block to (a block to Col 23 ln 28 – 30) another of said nodes; (nodes corresponding to the majority of computing power, Col 23 ln 60 – 65) said nodes (nodes corresponding to the majority of computing power, Col 23 ln 60 – 65) are configured to perform a blockchain smart contract method (Fig. 57A method for conducting a block trade order of a digital asset (e .g., BTC) on a digital asset exchange computer system Col 234 ln 65 – 67, Col 235 ln 1)according to claim 3 when receiving (receiving Col 56 ln 36) a smart transaction (Fig. 57 a block trade order of a digital asset (e .g., BTC) Col 234 ln 67) such as a “smart transaction” or a block.
Regarding claim 12 So teaches an electronic device (computer, smartphone, or other electronic device Col 39 ln 60) comprising a storage device, (processor readable memory, Col 38 ln 66/storage devices (e.g., digital wallets) Col 39 ln 58) a processor (one or more processors Col 38 ln 67) and a computer program (source code Col 38 ln 65 – 66) stored in said storage device (stored in processor readable memory, Col 38 ln 66) and executable by (execute the logic Col 44 ln 34)said processor; (one or more processors Col 38 ln 67) said electronic device(computer, smartphone, or other electronic device Col 39 ln 60) is configured such that when said processor (one or more processors Col 38 ln 67) executes (execute the logic Col 44 ln 34) said program, (source code Col 38 ln 65 – 66) implementing a blockchain smart contract method (Fig. 57A method for conducting a block trade order of a digital asset (e .g., BTC) on a digital asset exchange computer system Col 234 ln 65 – 67, Col 235 ln 1) according to claim 1.
Regarding claim 13 So teaches an electronic device (computer, smartphone, or other electronic device Col 39 ln 60) comprising a storage device, (processor readable memory, Col 38 ln 66/storage devices (e.g., digital wallets) Col 39 ln 58) a processor (one or more processors Col 38 ln 67)and a computer program (source code Col 38 ln 65 – 66) stored in said storage device (stored in processor readable memory, Col 38 ln 66) and executable by (execute the logic Col 44 ln 34) said processor; (one or more processors Col 38 ln 67) said electronic device(computer, smartphone, or other electronic device Col 39 ln 60) is configured such that when said processor executes (execute the logic Col 44 ln 34)said program, (source code Col 38 ln 65 – 66) implementing a blockchain smart contract method(Fig. 57A method for conducting a block trade order of a digital asset (e .g., BTC) on a digital asset exchange computer system Col 234 ln 65 – 67, Col 235 ln 1) according to claim 3.
Regarding claim 14 So teaches a non-transitory computer-readable storage medium (non-transitory computer-readable memory Col 55 ln 37 - 9) in which a computer program(source code Col 38 ln 65 – 66) is stored, (be stored in Col 38 ln 66) when said computer program (source code Col 38 ln 65 – 66) is executed by(execute the logic Col 44 ln 34) a processor, (stored in processor readable memory, Col 38 ln 66) implementing a blockchain smart contract method (Fig. 57A method for conducting a block trade order of a digital asset (e .g., BTC) on a digital asset exchange computer system Col 234 ln 65 – 67, Col 235 ln 1) according to claim 1.
Regarding claim 15 So teaches a non-transitory computer-readable storage medium (non-transitory computer-readable memory Col 55 ln 37 - 9) in which a computer program(source code Col 38 ln 65 – 66) is stored, (stored in processor readable memory, Col 38 ln 66) when said computer program (source code Col 38 ln 65 – 66)is executed by (execute the logic Col 44 ln 34)a processor, (stored in processor readable memory, Col 38 ln 66) implementing a blockchain smart contract method (Fig. 57A method for conducting a block trade order of a digital asset (e .g., BTC) on a digital asset exchange computer system Col 234 ln 65 – 67, Col 235 ln 1) according to claim 3.
Regarding claim 16 So teaches the blockchain smart contract method (Fig. 57A method for conducting a block trade order of a digital asset (e .g., BTC) on a digital asset exchange computer system Col 234 ln 65 – 67, Col 235 ln 1) of claim 3,
So further teaches wherein said first output items(any combination of multiple digital outputs … 15 BTC of which will be a spent output that is sent to the desired destination and 5 BTC of which will be an unspent output Col 40 ln 13 - 26)) are contained in data (combination of outputs Col 40 ln 25 – 26)of said delivery instruction, (procedures for the creation and redemption of baskets of trust shares and for the delivery of the digital math-based assets, e.g., Bitcoin, Ethereum … Col 151 ln 64 - 67 – Col 152 ln 1) said second output items (any combination of multiple digital outputs … 15 BTC of which will be a spent output that is sent to the desired destination and 5 BTC of which will be an unspent output Col 40 ln 13 - 26)consist of a token (Stable Value Digital Asset token Col 43 ln 20 – 25) contained in data of said mint instruction (operations associated with generating or minting new digital assets, Col 40 ln 33 - 35)
Regarding claim 19 So teaches the blockchain smart contract method(Fig. 57A method for conducting a block trade order of a digital asset (e .g., BTC) on a digital asset exchange computer system Col 234 ln 65 – 67, Col 235 ln 1) according to claim 1,
So teaches before (prior to Col 66 ln 35, Col 237 ln 46) executing all calls of smart contracts (calls from ERC20Proxy 6410, ERC20Impl 6420, and ERC20Store 6430, respectively Col 31 ln 4 – 19), (Custodian 6450 Col 31 ln 20 – 25), (Fig. 68 e.g., smart contract address 6805A Col 96 ln 31) (smart contract address 6807 A Col 96 ln 32) (calls to one or more other smart contracts having their own smart contract addresses Col 96 ln 36 - 37)in the smart transaction, (Fig. 57 a block trade order of a digital asset (e .g., BTC) Col 234 ln 67) such as a “smart transaction” the method (Fig. 57A method for conducting a block trade order of a digital asset (e .g., BTC) on a digital asset exchange computer system Col 234 ln 65 – 67, Col 235 ln 1)comprising: S1. the node (a node Col 25 ln 20 – 25)receiving (receiving Col 58 on 49) the smart transaction (Fig. 57 a block trade order of a digital asset (e .g., BTC) Col 234 ln 67) such as a “smart transaction” submitted (submitted col 237 ln 33) by the user, (market maker may be an exchange user Col 56 ln 11 – 12) wherein the smart transaction(Fig. 57 a block trade order of a digital asset (e .g., BTC) Col 234 ln 67) such as a “smart transaction” submitted (submitted col 237 ln 33)by the user(market maker may be an exchange user Col 56 ln 11 – 12) comprises calls of smart contracts. (calls from ERC20Proxy 6410, ERC20Impl 6420, and ERC20Store 6430, respectively Col 31 ln 4 – 19), (Custodian 6450 Col 31 ln 20 – 25), (Fig. 68 e.g., smart contract address 6805A Col 96 ln 31) (smart contract address 6807 A Col 96 ln 32) (calls to one or more other smart contracts having their own smart contract addresses Col 96 ln 36 - 37)
Regarding claim 23 So teaches the blockchain smart contract method (Fig. 57A method for conducting a block trade order of a digital asset (e .g., BTC) on a digital asset exchange computer system Col 234 ln 65 – 67, Col 235 ln 1)according to claim 1,
So further teaches a node executing all calls of smart contracts (calls from ERC20Proxy 6410, ERC20Impl 6420, and ERC20Store 6430, respectively Col 31 ln 4 – 19), (Custodian 6450 Col 31 ln 20 – 25), (Fig. 68 e.g., smart contract address 6805A Col 96 ln 31) (smart contract address 6807 A Col 96 ln 32) (calls to one or more other smart contracts having their own smart contract addresses Col 96 ln 36 - 37)in a smart transaction (Fig. 57 a block trade order of a digital asset (e .g., BTC) Col 234 ln 67) such as a “smart transaction” further comprises: adding, by the smart contracts, (ERC20Proxy 6410, ERC20Impl 6420, and ERC20Store 6430, respectively Col 31 ln 4 – 19), (Custodian 6450 Col 31 ln 20 – 25), input items to the smart transaction during execution of the smart contracts (Next, in step 2, to confirm the pending request, the Custodian contract 6450 for ERC20 Proxy 6410 calls requestUnlock and passes as arguments the lockld generated for the change request, and the function in ERC20Proxy 6410 the Custodian 6450 needs to call to confirm the change request. This generates a request, which is a unique identifier for this unlock request.) Col 32 ln 55 – 61)
Regarding claim 24 So teaches the virtual machine method (Ethereum virtual machine Col 27 ln 20 - 21)for blockchain smart contract (smart contracts Col 27 ln 18 - 21)according to claim 8,
So further teaches wherein the step verifying (verifying Col 59 ln 10 – 18) that said input items are owned by (the digital asset seller may transfer digital assets to a digital wallet associated with ( e.g., owned by and/or operated by) the exchange. The exchange may hold such funds in escrow until the buyer's payment is received, e.g. into a bank account (for fiat currencies) or into a digital wallet (for other digital assets). Col 42 ln 45 - 52) SEE ALSO proof of work and proof of stake Col 42 ln 34 – 65 said smart contract (ERC20Proxy 6410, ERC20Impl 6420, and ERC20Store 6430, respectively Col 31 ln 4 – 19), (Custodian 6450 Col 31 ln 20 – 25) (Fig. 68 e.g., smart contract address 6805A Col 96 ln 31)comprises: verifying (verifying Col 59 ln 10 – 18) that an address in a script of the output items (digital outputs Col 40 ln 13 - 25) referenced by the input items(digital inputs Col 71 ln 49 – 52) is an address of the smart contract being called, or verifying (verifying Col 59 ln 10 – 18)that the input item (digital inputs Col 71 ln 49 – 52) consists of an address (associated digital asset addresses Col 60 ln 16)of the smart contract being called(ERC20Proxy 6410, ERC20Impl 6420, and ERC20Store 6430, respectively Col 31 ln 4 – 19), (Custodian 6450 Col 31 ln 20 – 25) (Fig. 68 e.g., smart contract address 6805A Col 96 ln 31) and account balance (check account balance Col 204 ln 37 - 38 )of a smart contract account is not less than a value of the input items (verifying, by the digital math-based asset computer system, that first fiat account balance data indicating a first fiat account balance of a purchaser insured fiat account associated with the institutional exchange account at least equals the purchase order fiat amount; Col 232 ln 42 - 47)
Regarding claim 25 So teaches the blockchain smart contract method (Fig. 57A method for conducting a block trade order of a digital asset (e .g., BTC) on a digital asset exchange computer system Col 234 ln 65 – 67, Col 235 ln 1) of claim 23,
So further teaches comprising one of the following three steps: for each output item in said coinbase transaction, crediting the token of the output item to an account of an address in the output item; for each input item (digital inputs Col 71 ln 49 – 52) in said smart transaction, (Fig. 57 a block trade order of a digital asset (e .g., BTC) Col 234 ln 67) such as a “smart transaction” deducting the token of the input item from an account of an address in the input item; (debiting assets from a user's account Col 64 ln 60 - 61) and for each output item (digital outputs Col 40 ln 13 - 25) in said smart transaction, (Fig. 57 a block trade order of a digital asset (e .g., BTC) Col 234 ln 67) such as a “smart transaction” crediting the token of the output item to an account of an address in the output item (crediting assets to a user's account. Col 64 ln 60 - 61)
Regarding claim 27 So teaches the blockchain smart contract method(Fig. 57A method for conducting a block trade order of a digital asset (e .g., BTC) on a digital asset exchange computer system Col 234 ln 65 – 67, Col 235 ln 1) according to claim 1
So further teaches wherein validating (validating Col 24 ln 25 – 30) the smart transaction (Fig. 57 a block trade order of a digital asset (e .g., BTC) Col 234 ln 67) such as a “smart transaction” further comprises: verifying signatures (This change requires the authorization of Custodian 6450, which in turn requires two signatures from keys in its designated keyset (e.g., Off-Line Keyset 6462) sent to it on the blockchain. Table 3 represents an exemplary embodiment of the steps used to implement this process:
TABLE 3
1. lock!D - proxy.requestlmp1Change(imp_2)
2. request = custodian.requestUnlock(
lockld,proxy.confirmlmpl.Change)
3. Off-line signing of request
4. custodian.completeUnlock (request, signature_1, signature 2)
a. proxy.confirmlmplChange(locklD)
Col ln 35 – 49) (two signatures are required (signature 1 and signature 2) Col 32 ln 67) for original input items (digital inputs Col 71 ln 49 – 52) and blocking double spending; (solve double-spending problems where users attempt to spend the same digital assets in more than one transaction Col 23 ln 20 - 22)wherein the original input items are input items (digital inputs Col 71 ln 49 – 52) in the smart transaction (Fig. 57 a block trade order of a digital asset (e .g., BTC) Col 234 ln 67) such as a “smart transaction” submitted by the user; the blocking double spending (double-spending problems Col 23 ln 20 – 22) consists of verifying that the input items(digital inputs Col 71 ln 49 – 52) in the smart transaction (Fig. 57 a block trade order of a digital asset (e .g., BTC) Col 234 ln 67) such as a “smart transaction” references to outputs of other transactions that has not been used (In embodiments, before a transaction may be cleared, the transaction participants may need to wait for some period of time, e.g., a six-confirmation wait (typically one hour in the context of the Bitcoin network, 15 minutes in the context of the Litecoin network, to name a few), before feeling confident that the transaction is valid (e.g., not a double count).Col 23 ln 22 - 28) or verifying that the input items (digital inputs Col 71 ln 49 – 52) in the smart transaction (Fig. 57 a block trade order of a digital asset (e .g., BTC) Col 234 ln 67) such as a “smart transaction” does not exceed balance of corresponding accounts (a client's outstanding interest
on orders books of the digital asset exchange cannot exceed their account balance at any time and all open orders reduce a client's available balance until such orders are
fulfilled or canceled. Col 73 ln 7 - 11)
Regarding claim 28 So teaches the blockchain smart contract method (Fig. 57A method for conducting a block trade order of a digital asset (e .g., BTC) on a digital asset exchange computer system Col 234 ln 65 – 67, Col 235 ln 1)according to claim 23,
So further teaches wherein a separation item
(TABLE 5
require(msg.sender == custodian); Col 34 ln 50 – 60) such as “separation item”
is added to a list of input or output group
(TABLE 5
mapping (bytes32 -> PendingAction) public pendingActionMap Col 34 ln55) such as “output group” of the smart transaction (Fig. 57 a block trade order of a digital asset (e .g., BTC) Col 234 ln 67) such as a “smart transaction”
before (prior to Col 66 ln 35, Col 237 ln 46) the input items
(TABLE 5
function requestAction(t_v, ... ) public returns (bytes32 lock:Id) {
require(_v !- 0);
lockld -generateLockld( );
pendingActionMap [lockld] -PendingAction( {
v: _v,
Col 34 ln 55 - 60
and the output items
(TABLE 5
function requestAction(t_v, ... ) public returns (bytes32 lock:Id) {
require(_v !- 0);
lockld -generateLockld( );
pendingActionMap [lockld] -PendingAction( {
v: _v,
Col 34 ln 55 - 60
are added to the smart transaction; (Fig. 57 a block trade order of a digital asset (e .g., BTC) Col 234 ln 67) such as a “smart transaction” the separation item (TABLE 5
require(msg.sender == custodian); Col 34 ln 50 – 60) such as “separation item”
is configured to distinguish original input items (digital inputs Col 71 ln 49 – 52) and output items(digital outputs Col 40 ln 13 - 25) from those added by smart contracts, (ERC20Proxy 6410, ERC20Impl 6420, and ERC20Store 6430, respectively Col 31 ln 4 – 19), (Custodian 6450 Col 31 ln 20 – 25) (Fig. 68 e.g., smart contract address 6805A Col 96 ln 31) (smart contract address 6807 A Col 96 ln 32)the original input items (digital inputs Col 71 ln 49 – 52)and output items (digital outputs Col 40 ln 13 - 25) are
input items (TABLE 5
function requestAction(t_v, ... ) public returns (bytes32 lock:Id) {
require(_v !- 0);
lockld -generateLockld( );
pendingActionMap [lockld] -PendingAction( {
v: _v,
Col 34 ln 55 - 60
and output items
(TABLE 5
function requestAction(t_v, ... ) public returns (bytes32 lock:Id) {
require(_v !- 0);
lockld -generateLockld( );
pendingActionMap [lockld] -PendingAction( {
v: _v,
Col 34 ln 55 - 60
in the smart transaction (Fig. 57 a block trade order of a digital asset (e .g., BTC) Col 234 ln 67) such as a “smart transaction” submitted by the user(market maker may be an exchange user Col 56 ln 11 – 12)
Regarding claim 29 So teaches the blockchain smart contract method (Fig. 57A method for conducting a block trade order of a digital asset (e .g., BTC) on a digital asset exchange computer system Col 234 ln 65 – 67, Col 235 ln 1) according to claim 23, So further teaches wherein a flag (indication of interest Col 98 ln 64, col 99 ln 40, Col 239 ln 19)is included in each input (digital inputs Col 71 ln 49 – 52)or output item (digital outputs Col 40 ln 13 - 25)to indicate whether each input or output item is submitted by the user or added(flag potentially erroneous transactions, and/or stop potentially erroneous or unauthorized transactions). Col 134 ln 45 – 46, Col 140 ln 39 – 40; flag transactions for review (e.g., by portal administrators), 50 before the transactions may be confirmed Col 134 ln 49 - 51) by the smart contract (ERC20Proxy 6410, ERC20Impl 6420, and ERC20Store 6430, respectively Col 31 ln 4 – 19), (Custodian 6450 Col 31 ln 20 – 25)
Regarding claim 30 So teaches the blockchain smart contract method (Fig. 57A method for conducting a block trade order of a digital asset (e .g., BTC) on a digital asset exchange computer system Col 234 ln 65 – 67, Col 235 ln 1) according to claim 23, So further teaches wherein if tokens is a numerical token, (Stable Value Digital Asset Token /com 43 ln 20 – 25) such as “numerical token” or a geometric token, or a monodromy token; transaction integrity verification (verification of the first block trade order in step S5608, the digital asset exchange computer system 3230 may update a user account associated with the taker to set aside sufficient reserves in the
first digital asset, the first fiat and/or the second digital asset sufficient to cover the first block trade order if filled in full. Col 239 ln 5 – 11) consists of a step verifying that, for each type of tokens, total input tokens equals to total output tokens (In Step S6006, if the request is verified the transaction is published in the Security Token database of the blockchain reflecting a debit against Alice's token holdings and a corresponding credit to Bob's token holdings (less any applicable fees). Col 37 ln 20 - 25) with transaction fee taken into consideration; (with the transaction fee discussed paid to the miner for confirming the transaction as noted Col 37 ln 18 - 20 ) SEE ALSO first transaction fees Col 101 ln 9, second transaction fee Col 101 ln 44, third transaction fee Col 102 ln 5 - 6, fourth transaction fee Col 102 ln 56 for the numerical token, (Stable Value Digital Asset Token /com 43 ln 20 – 25) such as “numerical token” total means sum of numerical values; (sum of all digital asset balances and fiat currency balances. Col 108 ln 23 - 24) for the geometric token, total means merged geometric objects; for the monodromy token, total means a number of each monodromy;
Regarding claim 31 So teaches the blockchain smart contract method (Fig. 57A method for conducting a block trade order of a digital asset (e .g., BTC) on a digital asset exchange computer system Col 234 ln 65 – 67, Col 235 ln 1) according to claim 30 So further teaches wherein for the numerical token, (Stable Value Digital Asset Token /com 43 ln 20 – 25) such as “numerical token” verifying integrity (verification of the first block trade order in step S5608, the digital asset exchange computer system 3230 may update a user account associated with the taker to set aside sufficient reserves in the first digital asset, the first fiat and/or the second digital asset sufficient to cover the first block trade order if filled in full. Col 239 ln 5 – 11) of the smart transaction (Fig. 57 a block trade order of a digital asset (e .g., BTC) Col 234 ln 67) such as a “smart transaction” consists of verifying that total input values and total output values are identical (In Step S6006, if the request is verified the transaction is published in the Security Token database of the blockchain reflecting a debit against Alice's token holdings and a corresponding credit to Bob's token holdings (less any applicable fees). Col 37 ln 20 - 25) after completion of execution of all the calls of the smart contracts. (calls from ERC20Proxy 6410, ERC20Impl 6420, and ERC20Store 6430, respectively Col 31 ln 4 – 19), (Custodian 6450 Col 31 ln 20 – 25), (Fig. 68 e.g., smart contract address 6805A Col 96 ln 31) (smart contract address 6807 A Col 96 ln 32) (calls to one or more other smart contracts having their own smart contract addresses Col 96 ln 36 - 37)
Conclusion
9. The prior art made of record and not relied upon is considered pertinent to
applicant's disclosure.
Li et al., (United States Patent Publication Number 20210234703) teaches “determining whether the output item to which the input item of the transaction information in the target data block is linked is already linked to an input item of transaction information in a data block recorded on the blockchain before the target data block is recorded on the blockchain, and determining that the verification result is 'Not Passed' (that is, not verified) when the output item to which the input item of the transaction information in the target data block is linked is already linked to the input item of the transaction information in the data block recorded on the blockchain before the target data block is recorded on the blockchain; otherwise, the verification result is ' Passed' (that is, verified). [0147]”
10. Any inquiry concerning this communication or earlier communications from the
examiner should be directed to Kweku Halm whose telephone number is (469) 295-
9144. The examiner can normally be reached on 7:30AM - 5:30PM Mon - Thur. If
attempts to reach the examiner by telephone are unsuccessful, the examiner's
supervisor, Sanjiv Shah can be reached on (571) 272-4098. 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).
/KWEKU WILLIAM HALM/Examiner, Art Unit 2166
/SANJIV SHAH/Supervisory Patent Examiner, Art Unit 2166