DETAILED ACTION
Examiner objects to claims 1, 9, and 13 for minor informalities.
Claims 5-8, 10, and 15 rejected under 35 USC § 112(b) as indefinite.
Claim 11 rejected under 35 USC § 112(d) as an improper dependent claim.
Claims 1-6, 9-17, and 19-20 rejected under 35 USC § 103 as obvious.
Claims 7, 8, and 18 objected to as allowable dependent claims.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
Claims 1, 9, and 13 objected to because of the following informalities:
Claims 1 and 13 recite a step to “trace, by a machine learning (ML) engine … a predefined path.” The broadest reasonable interpretation of claims 1 and 13 is that the ML engine only performs the tracing step, and is not used in the capturing, storing, and outcome determining steps. This interpretation causes issues because it does not make sense to use machine learning to only trace a predefined path. Consider amending the claims to clarify where the ML is actually used.
System claim 9 is dependent on dependent claim 8. Corresponding method claim 19 is dependent on independent claim 13. The subject matter in claim 8 doesn’t pertain to claim 9. Consider amending system claim 9 to be dependent on independent claim 1. Examiner assumes claim 9 as actually dependent on claim 1.
Appropriate correction is required.
Claim Rejections – 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 5-8 and 10 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.
Claims 5-8
Claims 5-8 recite “the ExtInt variation,” “the IntInt variation,” “the ExtExt variation,” and “the IntExt variation.” Unclear or uncertain references to an element in the same or subsequent claim make the claim indefinite. MPEP 2173.05(e). These limitations are uncertain references because they do not have proper antecedent basis. Claims 5-8 are dependent on claims 1 and 3, and they do not establish any variations. Examiner assumes that claims 5-8 are actually dependent on claim 4, which would provide the proper antecedent basis.
Claim 10
Claim 10 recites “manage, the variations.” Unclear or uncertain references to an element in the same or subsequent claim make the claim indefinite. MPEP 2173.05(e). This limitation is an uncertain reference because they do not have proper antecedent basis. Claim 10 is dependent on claim 1, and it does not establish any variations. Examiner assumes that claim 10 is actually dependent on claim 4, which would provide the proper antecedent basis.
Claim 15
The phrase "wherein an information about state can be a combination of both a current value of each state value" renders the claim indefinite because it is unclear whether the limitation(s) following the phrase “can be” are part of the claimed invention. See MPEP § 2173.05(d). It is confusing as to whether the intended scope of the information about a state is limited to “a combination of both a current value of each state variable, and an incremental state transition if each state variable underwent a transition during a state transition” is required or optional. Accordingly, claim 15 is indefinite.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claim 11
Claim 11 is rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends. Claim 11 depends on itself. Examiner assumes claim 11 is dependent on claim 1. Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
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-3 and 12-15 are rejected under 35 U.S.C. 103 as being unpatentable over Kramer, U.S. PG-Publication No. 2020/0204350 A1, Fang et al., U.S. PG-Publication No. 2022/0067738 A1.
Claim 1
Kramer discloses a state management system (110) for facilitating configurability in blockchain based transactions. ¶ 0001: Kramer implements “a state machine within the structure of blockchain transaction processing,” including trustless, deterministic, and concurrent state machines used with smart-contract transactions. ¶ 0345: State machines operate through states that change according to a state-transition matrix and are implemented using blockchain transactions.
Kramer discloses the system comprising: one or more processors coupled to one or more computing devices (104) in a network (106). ¶ 0003: The blockchain network comprises multiple blockchain nodes implemented in hardware, software, or both; nodes create, propagate, read, and evaluate transactions and communicate with other nodes.
Kramer discloses wherein the one or more processors (202) are further coupled with a memory (204). ¶ 0004: Blocks and transactions are data structures in computer memory, readable by computer processes and transmissible as data. ¶¶ 0018-0021: Nodes execute locking and unlocking scripts using transaction data.
Kramer wherein said memory stores instructions which when executed by the one or more processors (202) causes the system (110) to perform instructions. ¶ 0346: Locking and unlocking scripts specify constraints, inputs, state values, and state-transition operations executed by blockchain nodes. ¶ 0364: A processor executes the described pseudocode to extract state information, determine the next state, and validate the transaction.
Kramer discloses receive a set of data packets from a computing device (104). ¶ 0341: “The system receives a unlocking transaction.” The unlocking script places the serialized previous transaction end embedded inputs on the processing stack. ¶ 0003: A blockchain transaction is an input message encoding a structured collection of field values and conditions.”
Kramer discloses the set of data packets comprising one or more transactions. ¶ 0341: The received unlocking transaction includes the serialized previous transaction and transaction inputs. ¶ 0346: The scripts access fields of the unlocking transaction and previous transaction.
Kramer discloses in any or a combination of one or more incremental blockchain transitions. ¶ 0348: Each state transition is handled by a path of blockchain-transaction outputs, and a transition occurs when an unlocking transaction unlocks a previous output. ¶ 0353: Unlocking transaction outputs correspond to state transitions in the state diagram.
Kramer discloses and one or more end to end blockchain transaction from an initial end to end blockchain state (E2E-BState) to an end end-to-end blockchain state (E2E-BState). ¶ 0332: A previous transaction begins in state S1 and transitions to S2 or S3. ¶ 0334: The state-machine process replicates through successive transactions until a termination condition is fulfilled. ¶ 0341: Fulfillment of the termination condition ends state-machine propagation. ¶ 0347: One exemplary complete route is S1-S2-S3-S4-S8-S12 (i.e., and end-to-end blockchain transaction).
Kramer discloses wherein the one or more transactions pertain to one or more state variables. ¶ 0330: “The current state is represented as a parameter embedded in a transaction,” and the next-state value is embedded in the unlocking transaction. ¶ 0342: The next state may include “a state variable and other state-related data.”
Kramer discloses extract a first set of attributes from the received set of data packets. ¶ 0342: The system extracts the current state from the serialized previous transaction and obtains the input values from the unlocking script. ¶ 0364: The processor extracts the prior locking script, current state, transition matrix, optional input, and output index.
Kramer discloses the first set of attributes corresponding to one or more paths in a state transition graph starting from the initial end to end blockchain state to the end end-to-end blockchain state. ¶ 0333: The extracted first state and input are evaluated using state rules that identify possible next states. ¶ 0346: The state transition matrix (i.e., state transition graph) defines flow conditions and calculates the next state from the current state and other inputs. ¶ 0347: The state transition matrix expressly identifies multiple possible routes, conditions, barriers, and a merger.
Kramer discloses trace … a predefined path based on the extracted first set of attributes. ¶ 0333: The first state and input determine the appropriate second state from the state rules. ¶ 0342: The system applies state rules to determine the next state.
Kramer discloses such that the predefined path is secure. ¶ 0331: Inputs from a determined source provide a secure, deterministic transition. ¶ 0342: A script mismatch causes validation failure; matching scripts and a permitted next state allow validation. ¶ 0364: If the transition matrices or calculates next state do not match, the transaction is rejected.
Kramer discloses and any or a combination of the incremental blockchain transitions and the end-to-end blockchain state transitions are configurable. ¶ 0333: State rules may be conditional and parameterized by current state and inputs. ¶ 0346: A transition matrix defines the state machine’s flow conditions and operations. ¶ 0353: Valid-transaction rules may be hardcoded or supplied later as parameters. ¶¶ 0349-0351: Paths may be forked, cloned, merged or executed concurrently.
Kramer discloses capture and store, one or more changes to the state variables obtained after tracing each state transition. ¶ 0330: “The current state is represented as a parameter embedded in a transaction,” and “the next state value [is] embedded in the unlocking transaction.” ¶ 0332: A previous transaction is in the first state S1, while “the next state, S2 … is encoded in … the unlocking transaction.” ¶ 0361: The previous transaction contains <Current State><Transition Matrix>, while the unlocking transaction container <Next State><Transition Matrix>. ¶ 0342: The system extracts the current state and inputs, “applies the set of state rules to determine … the next state,” and verifies that the next state is embedded in the unlocking transaction. ¶ 0364: The processor determines the next state from the extracted current state, transition matrix, optional input, and output index, and compares it with the next state encoded in the transaction output.
Kramer discloses capturing and storing changes in the any or a combination of incremental transitions and end to end transaction from the initial E2E-BState to the end E2E-BState in a database. ¶ 0348: “each transition [is] handled by a single path of transaction outputs,” with a transition occurring when an unlocking transaction unlocks a previous transaction output. ¶ 0353: Blockchain transaction outputs represent states, and unlocking those outputs “corresponds to state transitions of the state diagram.” ¶ 0332: A previous transaction begins in a first state S1, and the state rules offer S2 or S3 as possible next states. ¶ 0347: The transition graph includes a complete route beginning with initial state S1: “S1-S2-S3-S4-S8-S12.” ¶ 0334: The linked-transaction process “may replicate until the termination condition is fulfilled.” ¶ 0341: When the termination condition is fulfilled, the “state machine transitions … end.”
Kramer discloses determine an outcome associated with the one or more changes to the state variables for each state transition in the any or a combination of incremental transitions and end to end transaction from the initial E2E-BState to the end E2E-BState. ¶ 0342: The current state and inputs determine the next state; the system verifies the next-state variable and then determines that the transaction is valid. ¶ 0364: A mismatch between the calculated and encoded next states causes failure, if the constraints are met, “the script passes.” ¶ 0020: Script execution produces “TRUE” or “FALSE.” ¶ 0021: A TRUE result causes the node to verify the transaction as valid. ¶ 0348: Each transaction is handled through a path of transaction outputs. ¶ 0364: For each output, the processor extracts the relevant scripts and state, determines the next state, and returns failure or passage.
Kramer does not expressly disclose trace by a machine learning (ML) engine operatively coupled to the one or more processors, a predefined path based on the extracted first set of attributes.
Fang teaches “a system and method … to effectively and accurately trace money flow between entities … from data stored in a transaction database, using artificial intelligence and machine learning” (Fang ¶ 0031).
Fang discloses trace by a machine learning (ML) engine1 operatively coupled to the one or more processors, a predefined path based on the extracted first set of attributes. ¶ 0253: The auto-tracing module “employ[s] machine learning and artificial intelligence to trace a path from a source to a destination.” The algorithm traces “based on blockchain addresses or based on blockchain transactions.” ¶ 0252: Inputs include the starting address, flow direction, transaction volume, start and end times, maximum hops, tracing constraints, transaction filters, and address-clustering labels. ¶ 0268: AI graph-search algorithms “automatically select the best candidate paths to expand based on auto tracing results.” ¶ 0003: An AI graph-search algorithm is applied to a blockchain-transaction flow “to determine an auto-traced path.”
Fang discloses such that the predefined path is secure. ¶ 0031: AI and ML trace transaction paths for anti-money-laundering, cybersecurity, blockchain-forensics, and fraud-detection purposes. ¶ 0038: ML predicts behavioral categories for addresses based on transaction history to detect sophisticated money-laundering paths. ¶ 0039: ML produces real-time predictions and high-risk scores used to identify and block suspicious blockchain transactions.
Fang discloses capture and store one or more changes to the state variables obtained after tracing each state transition … in a database. ¶ 0249: The tracing architecture includes a BEI label database 1406, transaction database 1408, auto-tracing system 1412, and result graph 1414. ¶ 0250: Blockchain transaction data is processed through ETL and “stored in a transaction database 1408”; ML-derived address labels are stored in BEI label database 1406. Both databases provide inputs to auto tracing. ¶ 0251: The transaction and label databases may be in-memory, key-value, or distributed-columnar databases supporting large transaction and entity datasets. ¶ 0254: After tracing, the auto-tracing system outputs results graph 1414 showing the transactions traced from source to destination.
Fang discloses one or more changes to the state variables obtained after tracing each state transition in the any or a combination of incremental transitions and end to end transaction from the initial E2E-BState to the end E2E-BState in a database. ¶ 0003: The selected flow contains a source address, intermediate addresses, a destination addresses, and intermediate transactions transferring assets between the source and destination. ¶ 0253: ML and AI trace the path “from a source to a destination.” ¶ 0254: The result graph visualizes transactions traced from source to destination.
Fang discloses determine an outcome associated with the one or more changes to the state variables for each state transition in the any or a combination of incremental transitions and end to end transaction from the initial E2E-BState to the end E2E-BState. ¶ 0042: An ML risk-classification engine converts blockchain data into a behavior category; and an ML regression engine assigns a risk score. A high-risk result blocks a blockchain transaction, freezes assets, or suspends an account; a normal result approves the transaction. ¶ 0050: The ML output includes a risk score, reasons for the prediction, and a suspicious transaction summary. ¶ 0068: ML analyzes extracted blockchain data to create classified-risk data and assign risk scores. ¶ 0071: The classified data and score determine whether a transaction is blocked, frozen, suspended, or approved. ¶ 0038: ML predicts address behavior “based on transaction history.” ¶ 0003: Intelligence labels are applied to the source, intermediate, and destination addresses along the traced transaction (i.e., end-to-end transaction).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the blockchain state-machine system of KRAMER to incorporate the machine-learning and artificial-intelligence path-tracing and outcome-determination functionality taught by FANG. One of ordinary skill in the art would be motivated to integrate FANG’s ML/AI path-tracing and outcome-determination functionality into KRAMER, with a reasonable expectation of success, in order to perform more comprehensive and accurate searches of complex blockchain-transaction paths, including sophisticated paths that manual searches may fail to detect (Fang, ¶ 0038).
Claim 2
Kramer discloses wherein the state variables pertain to one or more parameters of a transaction. ¶ 0330: “the current state is represented as a parameter in a transaction,” including within the locking script of a transaction output; the next-state value is likewise embedded in the unlocking transaction. ¶ 0332: The current state S1 may be embedded in a transaction’s lock-time field or locking script, while next state S2 is encoded in the locking script of an unlocking-transaction output. ¶ 0346: A locking script may require transaction data including serialized transaction fields, “a current state value,” external input, and a state-transition matrix used to calculate the next state. ¶ 0361: A previous transaction’s locking script may contain <Current State><Transition Matrix><other script>, while unlocking transaction contains <Next State><Transition Matrix><other script>. ¶ 0362: A state-machine state may alternatively be stored in a transaction field, such as the lock-time field or another unused transaction field.
Claim 3
Kramer discloses wherein an information about a state. ¶ 0346: A blockchain transaction supplies a current-state value, transaction inputs, and a state-transition matrix specifying how to calculate the next state.
Kramer discloses wherein the information about a state is a combination of both a current value of each state variable. ¶ 0330: “the current state is represented as a parameter embedded in a transaction,” such as in the locking script of a transaction output. ¶ 0342: The system “extracts the current state” from the serialized previous transaction before applying the state-transition rules.
Kramer discloses wherein the information about a state is an incremental state transition if each state variable underwent a transition during a state transition. ¶ 0332: A previous transaction encodes first state S1, and the unlocking transaction encodes next state S2 “to effect a state transition.” ¶ 0348: “each transition [is] handled by a single path of transaction outputs,” and a state transition occurs when an unlocking transaction unlocks a previous transaction output. ¶ 0342: The system determines the next state from the current state and inputs and then verifies that the determined next-state variable is embedded in the unlocking transaction. ¶ 0361: The previous transaction contains <Current State><Transition Matrix> while the unlocking transaction contains <Next State><Transition Matrix>. ¶ 0364: The processor extracts the previous transaction’s current state, determines the next state, and checks the determined state against the next state encoded in the unlocking transaction output (i.e., combination of current value and transition information).
Claim 12
Kramer discloses wherein the one or more processor causes to orchestrate an end-to-end processing of one or more incremental tasks associated with the one or more transactions. ¶ 0348: A smart contract may execute in “multiple concurrent steps,” with different contract fragments executed independently and asynchronously. ¶ 0359: “subtasks can become useful for enabling faster, concurrent, smart contracts.” Separate transaction threads provide concurrent execution of the subtasks. ¶ 0348: Each state transition is handled through blockchain-transaction outputs, and a transition occurs when an unlocking transaction unlocks a previous output. ¶ 0334: The linked transaction process replicates through successive state changes “until the termination condition is fulfilled.” ¶ 0349: A smart contract may fork from one state into multiple state machines executing separate paths. ¶ 0351: Different paths execute concurrently and later merge (i.e., orchestration). ¶ 0388: Two or more smart contracts may execute in parallel and may be required to pass through a common unlocking transaction. A barrier prevents one transition until another transition occurs. ¶ 0392: The system extracts the states and inputs for multiple state machines and checks barriers applicable to both transitions. ¶¶ 0377-0386: Multiple concurrent state-machine paths may merge into a shared next state. ¶¶ 0388-0395: Parallel transactions and barriers synchronize interdependent state transitions.
Claims 13-15
Claims 13-15 are rejected utilizing the rationale for claims 1-3; the claims are directed to a method performed by the system.
Claims 4-6, 9-10, 16-17, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Kramer, U.S. PG-Publication No. 2020/0204350 A1, Fang et al., U.S. PG-Publication No. 2022/0067738 A1, further in view of Kulkarni et al., U.S. PG-Publication No. 2022/0084013 A1.
Claim 4
Kulkarni teaches a system for “maintaining decentralized authorization for requested transactions on a distributed computing system in communication with off-chain centralized components” (Kulkarni, ¶ 0008).
Kulkarni discloses wherein a plurality of options is provided to store the information about the state that is either internal or external to the system. ¶ 0035: The transaction mediating system may use state information recorded outside the blockchain network—identified as “external state information”—or state information stored on the distributed ledger—identified as “internal state information.” ¶ 0050: External state information is not recorded on the blockchain ledger, whereas internal state information is stored on the ledger and directly accessible to blockchain smart contracts. ¶ 0098: The transaction mediating system validates or rejects user input using predetermined conditions, and in some embodiments, “additional external state information” that is accessible to the digital asset system but is not included in the user input.
Kulkarni discloses the plurality of options including variations comprising an External-Internal (ExtInt) variation, an Internal-internal (IntInt) variation, an External-external (ExtExt) variation, and an Internal-External (IntExt) variation for the end-to-end state and the incremental state transition management. ¶ 0051: In one option, the blockchain maintains wallet balances as internal state on its distributed ledger, and the resulting transaction is “fully blockchain-contained” (i.e., Internal-internal variation). ¶ 0052: In another option, a smart contract depends upon external state information processed outside the blockchain and updates its internal state in response to the externally originating transaction (i.e., External-internal variation). ¶ 0135: A new wallet address is stored in data storage accessible to the external digital asset system and is also stored in association with the user in an on-chain data structure.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the blockchain state-management functionality of KRAMER-FANG to incorporate KULKARNI’s internal and external state-management options, including the ExtInt and IntInt variations. One of ordinary skill in the art would be motivated to integrate KULKARNI’s internal and external state-management options into KRAMER-FANG, with a reasonable expectation of success, in order to incorporate off-network constraints and external state into blockchain transactions when needed (Kulkarni, ¶ 0054), while allowing fully blockchain-contained transactions to retain secure, transparent and decentralized execution (Id. at ¶¶ 0043, 0051).
Claim 5
Kulkarni discloses wherein in the ExtInt variation, the one or more processors manage the end-to-end state external to the system (110). ¶ 0052: Smart-contract execution may depend upon external state information that is not present on or stored in the blockchain ledger. An intermediating system processes or analyzes that external state information for the smart contract. ¶ 0055: The external transaction state may include a user’s citizenship, a fiat-currently balance in an off-chain bank account, occurrence of an off-chain event, or achievement of “a particular off-chain state.” ¶ 0056: The mediating party verifies off-chain assets, locks or restricts those assets, and withdraws or transfers the user’s off-chain funds before authorizing the blockchain transaction.
Kulkarni discloses wherein the incremental state transitions are managed internal to the system. ¶ 0052: A smart contract may “update its internal state in response to a transaction that came from outside of the blockchain network.” ¶ 0060: After the external state and off-chain rules are verified, smart contracts complete validation of the transaction, resulting in a change to internal state information, such as updated wallet balances recorded on the distributed ledger.
Claim 6
Kulkarni discloses wherein in the IntInt variation, the one or more processors manage both the end-to-end state and the incremental state transitions internal to the system (110). ¶ 0051: The blockchain maintains internal state information including wallet balances, on its distributed ledger. The disclosed transfer operation is “fully blockchain-contained” and uses the internal state and incoming transaction payload to determine whether to proceed. ¶ 0048: The blockchain virtual machine transfers tokens between addresses by performing computational operations and recording the resulting changes of state on the blockchain ledger. ¶ 0089: Smart-contract actions produce changes to internal state information, including updates to digital-asset balances recorded on the distributed ledger.
Claim 9
Kulkarni discloses wherein the one more processor further causes the system to:
manage, the one or more state variables external to the system (110) in a stateless manner. ¶ 0035: The transaction mediating system uses “external state information” recorded outside the blockchain network. The mediating system need not execute the transaction itself but conditionally determines whether the transaction is eligible for blockchain execution. ¶ 0052: Smart-contract execution may depend on external state information that is neither present on nor stored in the blockchain ledger and is instead processed by an intermediating system.
Kulkarni discloses centrally distribute, the one or more state variables are state variables in the system (110). ¶ 0008: Kulkarni maintains decentralized authorization on a distributed computing system operating “in communication with off-chain centralized components.” ¶ 0034: A transaction-mediating system facilitates, limits, and controls transactions under predetermined rules before the transactions are injected into the blockchain network.
Kulkarni discloses distribute equally the one or more state variables among the one or more computing devices associated with the system (110). ¶ 0041: A distributed blockchain operates on multiple geographically separated nodes, and “[i]n a typical implementation, each instance maintains a copy of the blockchain.” ¶ 0043: The blockchain virtual machine maintains a “self-consistent, singular global state” across all nodes operating the virtual machine.
Kulkarni discloses store the one or state variables in a single computing device. ¶ 0036: Copies of “all or part” of the distributed ledger may exist at various individual nodes in the computer network. ¶ 0041: A node is an instance of blockchain-processing code executed on a computer, and each instance maintains a copy of the blockchain that it treats as authoritative after validation.
Kulkarni discloses manage, the one or more state variables in one or more computing devices (peers). ¶ 0041: Blockchain instances communicate “through a peer-to-peer network” to maintain blockchain integrity and obtain state updates, including new transactions and blocks. ¶ 0036: Each computer supports one or more computational nodes that communicate with nodes on other computers to “support and manage a distributed ledger.”
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the blockchain state-management functionality of KRAMER-FANG to incorporate KULKARNI’s external, centralized, distributed, single-node, and peer-based state-management arrangements. One of ordinary skill in the art would be motivated to integrate KULKARNI’s alternative state-management arrangements into KRAMER-FANG, with a reasonable expectation of success, in order to incorporate off-network constraints into blockchain transactions when needed (Kulkarni, ¶ 0054) while distributing state among peer nodes to maintain blockchain integrity and resist unauthorized manipulation by any individual party (Id. at ¶ 0041).
Claim 10
Kulkarni discloses wherein the one or more processor further causes the system (110) to manage, the variations based on a level of pre-determined trust in the one or more computing devices associated with the system (110). ¶ 0145: The transaction-mediating system applies a “predefined rule-set” to determine whether a transaction requires the digital asset system’s additional signature. Transactions involving off-chain events or external state information may require the additional trusted-system signature, whereas other transactions may proceed without it. ¶ 0148: Each participating party may use “a computer system trusted and controlled by a respective party” to initiate the transaction. The disclosed computers include issuer, payment-processor and network-manager computers. ¶ 0062: Transactions may require multiple mediating parties to agree, or may permit selection among several mediating parties, such as accepting a transaction when one or three possible mediating parties signs it. ¶ 0060: For constrained transactions, the transaction-mediating system verifies compliance with off-chain rules and signs the transaction with its private mediating key before submitting it for internal blockchain authentication and execution.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the blockchain state-management functionality of KRAMER-FANG to incorporate KULKARNI’s management of state-processing variations according to predetermined trust in participating computing devices. One of ordinary skill in the art would be motivated to integrate KULKARNI’s trust-based management into KRAMER-FANG, with a reasonable expectation of success, in order to ensure that only properly credentialed users and trusted mediating systems authorize transactions involving external state information before those transactions are submitted to the blockchain for execution (Kulkarni, ¶¶ 0035, 0060, 0145).
Claim 16
Claim 16 is rejected utilizing the rationale for Claim 4; the claim is directed to a method performed by the system.
Claim 17
Claim 17 is rejected utilizing the combined rationales for claims 5 and 6; the claim is directed to a method performed by the system.
Claim 19
Claim 19 is rejected utilizing the rationale for claim 9; the claim is directed to a method performed by the system.
Claims 11 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Kramer, U.S. PG-Publication No. 2020/0204350 A1, Fang et al., U.S. PG-Publication No. 2022/0067738 A1, further in view of Kanza et al., U.S. PG-Publication No. 2020/0014529 A1.
Claim 11
Kramer discloses wherein the one more processor further causes the system to: transition a state variable from a centralized management module to a concurrently distributed management module associated with the one or more processors and vice versa. ¶ 0348: A state-machine transition ordinarily follows “a single path of transaction outputs.” Kramer then explains that blockchain transaction inputs and outputs permits concurrent state processing in which different contract fragments execute independently and asynchronously. ¶ 0349: A smart control beginning in state S1 may be forked into two state machines—one in state S2 and another in sate S5—running in parallel. ¶ 0358: One previous transaction produces at least two outputs requiring separate subsequent transactions, thereby allowing the resulting states “to be executed independently and possibly concurrently.” ¶ 0359: Although one state machine is normally in only one state at a time, concurrency is provided through “separate threads of transactions”; the state machine is forked by creating multiple transaction locking scripts from the current state. ¶ 0378: Multiple concurrently operating smart contracts or state machines may subsequently “be merged to form a single smart contract via its corresponding state machine.”
Kramer does not expressly disclose manage the state transfers ownership of a state variable to another computing device; and transfer the ownership of a state variable up and down a hierarchical chain of computing devices.
Kanza teaches a location-based blockchain system that transfers digital assets between wallets associated with different user devices, including transfers ascending to parent nodes and descending to child nodes within a hierarchy of independently managed blockchains (Kanza, ¶¶ 0009, 0041, 0052-0053).
Kanza discloses manage the state transfers ownership of a state variable to another computing device. ¶ 0009: A certified blockchain transaction includes “a transfer of an asset from a first wallet associated with the user device toa second wallet associated with a second user device.” The asset may include cryptocurrency, real-estate, or supply-chain assets, data, digital assets, or specific property rights. ¶ 0053: A transaction is expressed as t=(x→y, m), and the transaction following it is added to the blockchain associated with the recipient wallet.
Kanza discloses transfer the ownership of a state variable up and down a hierarchical chain of computing devices. ¶ 0041: Transactions are associated with different nodes in “a hierarchy of blockchains,” and each sub-blockchain is independently managed while transactions and blocks may be processed in parallel. ¶ 0052: An “ascending transfer” moves an asset from a wallet to node v to a wallet in the parent of node v, while a “descending transfer” moves the asset from a wallet at node v to a wallet in a child of v. ¶ 0053: A non-local transaction is translated into “a sequence of transfers along the shortest path” through the hierarchy, illustrated by transfers that ascend through parent nodes and then descend through child nodes to the destination wallet.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the blockchain state-management system of KRAMER-FANG to incorporate KANZA’s transfer of ownership between user devices and through parent and child node of a hierarchical blockchain. One of ordinary skill in the art would have been motivated to integrate KANZA’s hierarchical ownership-transfer mechanism into KRAMER-FANG, with a reasonable expectation of success, in order to increase blockchain scalability and security by partitioning transactions among independently managed sub-blockchains and permitting nonconflicting transactions and blocks to be processed in parallel (Kanza, ¶¶ 0024, 0041).
Claim 20
Claim 20 is rejected utilizing the rationale for claim 11; the claim is directed to a method performed by the system.
Allowable Subject Matter
Claims 7-8 and 18 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. Examiner notes that claims 7-8 subject to rejections under 35 USC §112 as indefinite; but would be allowable if rewritten in independent form including all of the limitations of the base claim and assumed intervening claims 1, 2, and 4.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See Broady et al., U.S. PG-Publication No. 2021/0326815 A1. Brody teaches a blockchain-based asset-management system that stores smart-contract state information between a distributed ledger and an off-chain database, records and tracks changes to state variables such as ownership, location and configuration, and organizes the associated asset information in a hierarchical hash-linked data structure (Brody, ¶¶ 0012-0017, 0040, 0050-0055).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FRANK D MILLS whose telephone number is (571)270-3194. The examiner can normally be reached M-F 9-5:30 CT.
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, KEVIN YOUNG can be reached at (571)270-3180. 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.
/FRANK D MILLS/Primary Examiner, Art Unit 2194 July 31, 2026
1 Examiner notes that the broadest reasonable interpretation of the claim is that only the “tracing” step uses machine learning. For purposes of expediting prosecution, Examiner relies on Fang to teach using machine learning for the capturing, storing, and outcome determination steps as well.
Prosecution Insights