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 .
Response to Arguments
Applicant's arguments filed 03/23/2026 with respect to the rejection(s) of claim(s) 1-15 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made. See remarks on page 1-3.
The rejection of pending claims 1-20 under 35 U.S.C. 101 as directed to an abstract idea without significantly more, is withdrawn in view of MPEP 2106.04(d). See remarks on page 3-4.
Claim Rejections - 35 USC § 103
2. 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
3. Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Madisetti et al. (US 20190228409 A1), in view of Vaughn et al. (US 20190356471 A1), in view of Turgman et al. (US20200364813 A1), and further in view of Batra et al. (US 20190205884 A1), and further in view of Gunning et al. (US 11398911 B1).
4. Regarding claims 1, 10, and 19, Madisetti discloses a method for deploying a contract in a blockchain performed by a blockchain node (a blockchain node, comprising: at least one processor; and one or more memories coupled to the at least one processor and storing programming instructions for execution by the at least one processor to perform operations, a non-transitory, computer-readable medium storing one or more instructions executable by at least one processor to perform operations, (Para. 0175),
wherein the method comprises: receiving a first transaction for deploying a first contract, (Para. 0003, Blockchain is a distributed and public ledger which maintains records of all the transactions. A blockchain network is a truly peer-to-peer network and it does not require a trusted central authority or intermediaries to authenticate or to settle the transactions or to control the network infrastructure. Users can interact and transact with the blockchain networks through Externally Owned Account (EOAs), which are owned and controlled by the users. Each EOA has a balance (in certain units of a Cryptocurrency associated with the Blockchain network) associated with it. EOAs do not have any associated code. All transactions on a blockchain network are initiated by EOAs. These accounts can send transactions to other EOAs or contract accounts. Another type of accounts support by second generation programmable Blockchain platforms are the Contract Accounts. A Contract Account is created and owned by an EOA and is controlled by the associated contract code which is stored with the account. The contract code execution is triggered by transactions sent by EOAs or messages sent by other contracts.)
the code identifier and the first code are pre-stored in the blockchain, the first code comprises a first function for initializing a contract, and the second contract comprises a call to the first function, (Para. 0010, In current implementations of applications with linked smart contracts, one smart contract can send a transaction to another contract or reference public state variables of other contracts. However, such calls and variable references must be coded in the smart contract and the contract code once deployed cannot be changed. If one contract in a system of linked contracts must be changed then it would need re-deployment of all the other linked contracts as the code has to be changed. BBMF and GVNS technologies allow the seamless integration of scalable information exchange between the real-world and the systems of smart contracts and oracles, seamlessly and efficiently. Further, legacy blockchain-based code can be seamlessly upgraded and functionality modified through change in the BBMF framework through new mapping and distribution from older public state variables to new or redefined ones.; and Para. 0003, Blockchain is a distributed and public ledger which maintains records of all the transactions. A blockchain network is a truly peer-to-peer network and it does not require a trusted central authority or intermediaries to authenticate or to settle the transactions or to control the network infrastructure. Users can interact and transact with the blockchain networks through Externally Owned Account (EOAs), which are owned and controlled by the users. Each EOA has a balance (in certain units of a Cryptocurrency associated with the Blockchain network) associated with it. EOAs do not have any associated code. All transactions on a blockchain network are initiated by EOAs. These accounts can send transactions to other EOAs or contract accounts. Another type of accounts support by second generation programmable Blockchain platforms are the Contract Accounts. A Contract Account is created and owned by an EOA and is controlled by the associated contract code which is stored with the account. The contract code execution is triggered by transactions sent by EOAs or messages sent by other contracts.)
Madisetti does not explicitly disclose wherein the first transaction invokes a second contract.
However, Vaughn teaches wherein the first transaction invokes a second contract, (Para. 0023, A blockchain is a distributed system which includes multiple nodes that communicate with each other. A blockchain operates programs called chaincode (e.g., smart contracts, etc.), holds state and ledger data, and executes transactions. Some transactions are operations invoked on the chaincode. In general, blockchain transactions typically must be “endorsed” by certain blockchain members and only endorsed transactions may be committed to the blockhcain and have an effect on the state of the blockchain. Other transactions which are not endorsed are disregarded. There may exist one or more special chaincodes for management functions and parameters, collectively called system chaincodes.)
One of ordinary skill in the art would have recognized that applying the known technique of Vaughn to the known invention of Madisetti would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate contract features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the system to include wherein the first transaction invokes a second contract result in an improved invention because applying said technique will ensure that deploying contracts are more streamlined to reduce the workload, thus improving the overall performance of the invention.
Madisetti as modified does not explicitly disclose determining whether the second contract is a system contract before executing the first function based on the call in the second contract; obtaining the first function in the first code based on the code identifier when determining that the second contract is a system contract.
However, Vaughn teaches determining whether the second contract is a system contract before executing the first function based on the call in the second contract; obtaining the first function in the first code based on the code identifier when determining that the second contract is a system contract, (Para. 0023, A blockchain is a distributed system which includes multiple nodes that communicate with each other. A blockchain operates programs called chaincode (e.g., smart contracts, etc.), holds state and ledger data, and executes transactions. Some transactions are operations invoked on the chaincode. In general, blockchain transactions typically must be “endorsed” by certain blockchain members and only endorsed transactions may be committed to the blockhcain and have an effect on the state of the blockchain. Other transactions which are not endorsed are disregarded. There may exist one or more special chaincodes for management functions and parameters, collectively called system chaincodes.; and Para. 0027, The current state of the immutable ledger represents the latest values for all keys that are included in the chain transaction log. Because the current state represents the latest key values known to a channel, it is sometimes referred to as a world state. Chaincode invocations execute transactions against the current state data of the ledger. To make these chaincode interactions efficient, the latest values of the keys may be stored in a state database. The state database may be simply an indexed view into the chain's transaction log, it can therefore be regenerated from the chain at any time. The state database may automatically be recovered (or generated if needed) upon peer node startup, and before transactions are accepted.)
One of ordinary skill in the art would have recognized that applying the known technique of Vaughn to the known invention of Madisetti would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate contract features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the system to include determining whether the second contract is a system contract before executing the first function based on the call in the second contract; obtaining the first function in the first code based on the code identifier when determining that the second contract is a system contract result in an improved invention because applying said technique will ensure that deploying contracts are more streamlined to reduce the workload by initializing contracts that are invoked by other contracts, thus improving the overall performance of the invention.
Madisetti as modified does not explicitly disclose an incoming parameter for the second contract comprises a code identifier of a first code and a value of an immutable variable in the first code.
However, Turgman teaches an incoming parameter for the second contract comprises a code identifier of a first code and a value of an immutable variable in the first code, (Para. 0015, FIG. 5 shows an example GUI screen in which an immutable version of an agreed upon smart contract is shown in accordance with an example embodiment. Para. 0008, A user experience generator queries the smart contract itself to determine which representations are to be provided to each party via his respective user interface. For instance, the smart contract may comprise functions and/or user experience (UX) annotations that indicate to the user experience generator which user interface representations should be provided to a particular user based on at least one of the identity of the party and a state in which the smart contract is in.; and Para. 0111-0112, In one implementation of the foregoing method, said deploying comprises: replacing one or more variables of the smart contract with one or more user-specified parameters; compiling the smart contract with the user-specified parameters into a format suitable for the blockchain; and causing the compiled smart contract to be deployed to the blockchain for execution thereby. In another implementation of the foregoing method, said querying comprises: receiving, from the smart contract, an event notification that indicates that a state of the smart contract has changed; and querying a function of the smart contract that is configured to provide an indication as to whether the identified user is enabled to perform the action based on one or more inputs provided to the function; wherein said presenting comprises: responsive to the indication indicating that the identified user is enabled to perform the action, presenting the user interface representation.
One of ordinary skill in the art would have recognized that applying the known technique of Turgman to the known invention of Madisetti as modified would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate contract features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the system to include an incoming parameter for the second contract comprises a code identifier of a first code and a value of an immutable variable in the first code result in an improved invention because applying said technique will ensure that deploying contracts are more streamlined to reduce the workload by initializing contracts that are invoked by other contracts, thus improving the overall performance of the invention.
Madisetti as modified does not explicitly disclose storing state data of the first contract in the blockchain by executing the first function.
However, Batra teaches storing state data of the first contract in the blockchain by executing the first function, (Para. 0025, The ledger is a sequenced, tamper-resistant record of all state transitions of the blockchain. State transitions are a result of chaincode invocations (i.e., transactions) submitted by participating parties (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.) A transaction may result in a set of asset key-value pairs that are committed to the ledger as creates, updates, deletes, and the like. The ledger includes a blockchain (also referred to as a chain) which is used to store an immutable, sequenced record in blocks. The ledger also includes a state database which maintains a current state of the blockchain. There is typically one ledger per channel. Each peer node maintains a copy of the ledger for each channel of which they are a member.; and Para. 0025, The current state of the immutable ledger represents the latest values for all keys that are included in the chain transaction log. Because the current state represents the latest key values known to the channel, it is sometimes referred to as a world state. Chaincode invocations execute transactions against the current state data of the ledger. To make these chaincode interactions efficient, the latest values of the keys may be stored in the state database.)
One of ordinary skill in the art would have recognized that applying the known technique of Batra to the known invention of Madisetti as modified would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate contract features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the system to include storing state data of the first contract in the blockchain by executing the first function, wherein the state data of the first contract comprises the code identifier and the value of the immutable variable, and wherein the state data of the first contract is stored without storing executable contract code or a code hash associated with the first contract result in an improved invention because applying said technique will ensure that contracts are deployed with pre-stored codes to invoke initialization of the contracts, thus improving the overall performance of the invention.
Madisetti as modified does not explicitly disclose wherein the state data of the first contract comprises the code identifier and the value of the immutable variable, and wherein the state data of the first contract is stored without storing executable contract code or a code hash associated with the first contract.
However, Gunning teaches wherein the state data of the first contract comprises the code identifier and the value of the immutable variable, and wherein the state data of the first contract is stored without storing executable contract code or a code hash associated with the first contract, (Column 2/line 23, In some embodiments, the computer system is further configured to: receive instructions to perform a function on the first instance of the class object; process the function on the first instance to generate an updated state for the first instance; and record the updated state of the first instance or instructions to recreate the updated state of the first instance onto a blockchain ledger. In some embodiments, the computer system is further configured to: receive instructions to perform a function on the first instance of the class object; process the function on the first instance to generate an updated state for the first instance and a state for an instance of another class object; and record (1) the updated state of the first instance of the class object or instructions to recreate the updated state of the first instance of the class object and (2) the updated state of the instance of the other class object or instructions to recreate the updated state of the instance of the other class object onto a blockchain ledger.; and Column 20/line 61, Smart contracts disadvantageously have never been both class-based and strongly-typed, nor have they supported type introspection. This requires explanation because syntactically it might appear to be the opposite. At a low level, every time a smart contract is created on Ethereum using the CREATE opcode for example, a transaction is submitted to the blockchain with the complete code for that smart contract and all its dependencies. This alone should be an indicator because it suggests that two contract instances sharing the same contract class would have their code deployed twice, and any shared helper logic would be duplicated. The user creating the smart contract pays the blockchain fees twice and the previous contract code cannot be referenced to create the smart contract. This is equivalent to creating a class for every instance of an object and it is both inefficient and does not encourage strong types. Now Ethereum does have a way to check that code, but inspection is at the level of code, not types, which is insufficient since code may be made up of multiple types. Some higher-level smart contracting languages like Solidity allow programmers to reuse and extend contract classes though. However, this is mostly syntactic sugar and is not the same as strong typing. For example, when a contract extends another contract, the final contract code that is deployed on-chain is simply the combination of all of its parts rather than actually being an extension of an existing contract. There is no reference to the existing contract if it was already deployed. This means that when two smart contracts interact and one of them has an inheritance chain, the other smart contract cannot safely determine which contracts are part of that chain. On some blockchains, smart contract instances reference their contract code using a code hash. Two instances with the same code then would share the same code hash and one could argue that this is a form of strong typing. However, classes are not distinguished by its code, but by type. Two classes might have the same source code and even the same name and be considered different types according to the programming language. This is especially true in languages where classes are objects and may themselves change over time.)
One of ordinary skill in the art would have recognized that applying the known technique of Gunning to the known invention of Madisetti as modified would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate contract features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the system to include wherein the state data of the first contract comprises the code identifier and the value of the immutable variable, and wherein the state data of the first contract is stored without storing executable contract code or a code hash associated with the first contract result in an improved invention because applying said technique will ensure that contracts are deployed with pre-stored codes to invoke initialization of the contracts, thus improving the overall performance of the invention.
5. Regarding claims 2, 11, and 20, Madisetti does not explicitly disclose further comprising: determining that the first transaction fails to be executed when determining that the second contract is not a system contract.
However, Vaughn teaches further comprising: determining that the first transaction fails to be executed when determining that the second contract is not a system contract, (Para. 0023, A blockchain is a distributed system which includes multiple nodes that communicate with each other. A blockchain operates programs called chaincode (e.g., smart contracts, etc.), holds state and ledger data, and executes transactions. Some transactions are operations invoked on the chaincode. In general, blockchain transactions typically must be “endorsed” by certain blockchain members and only endorsed transactions may be committed to the blockhcain and have an effect on the state of the blockchain. Other transactions which are not endorsed are disregarded. There may exist one or more special chaincodes for management functions and parameters, collectively called system chaincodes.; and Para. 0030, In one example method of operation, a process for making dynamic customized changes to a blockchain network may include collecting metric information of recent transactions over a defined period of time. Information regarding the transactions may be identified and placed in a spreadsheet, graph or other data realization tool to identify the relationships in the network among members of the blockchain. One approach to identifying information may be a linear approach which is purely based on a number of transactions and a duration of those transactions. Another approach to analyzing the transactions may be a proportionality analysis which identifies a size of transactions (i.e., bytes) and a frequency of transactions over a period of time. Yet another approach may be a non-linear approach which is based on age of the blockchain, the transactions, recent changes to agreement terms for upcoming and recent transactions. Still yet a further example embodiment may include an explicit relationship, which is initiated by participants for more favorable or off-chain relationships. The analysis may be repeated every time a change in the membership to the blockchain occurs so as to remove and add new transactions. For example, a new peer member, a new type of blockchain transaction appearing in the transaction pool, and/or new client members contributing new transactions.)
One of ordinary skill in the art would have recognized that applying the known technique of Vaughn to the known invention of Madisetti would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate contract features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the system to include determining that the first transaction fails to be executed when determining that the second contract is not a system contract result in an improved invention because applying said technique will ensure that failed or invalid contracts are not activated, thus improving the overall performance of the invention.
Regarding claims 3 and 12, Madisetti discloses wherein the incoming parameter for the second contract further comprises a first contract address of the first contract, and wherein the storing state data of the first contract in the blockchain by executing the first function comprises: determining, by executing the first function, whether a state database comprises state data corresponding to the first contract address, and storing the state data of the first contract in the state database with the first contract address when the state database does not comprise the state data corresponding to the first contract address.
However, Vaughn teaches wherein the incoming parameter for the second contract further comprises a first contract address of the first contract, and wherein the storing state data of the first contract in the blockchain by executing the first function comprises: determining, by executing the first function, whether a state database comprises state data corresponding to the first contract address, and storing the state data of the first contract in the state database with the first contract address when the state database does not comprise the state data corresponding to the first contract address, (Para. 0025-0027, A ledger is a sequenced, tamper-resistant record of all state transitions of a blockchain. State transitions may result from chaincode invocations (i.e., transactions) submitted by participating parties (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). A transaction may result in a set of asset key-value pairs being committed to the ledger as one or more operands, such as creates, updates, deletes, and the like. The ledger includes a blockchain (also referred to as a chain) which is used to store an immutable, sequenced record in blocks. The ledger also includes a state database which maintains a current state of the blockchain. There is typically one ledger per channel. Each peer node maintains a copy of the ledger for each channel of which they are a member. A chain is a transaction log which is structured as hash-linked blocks, and each block contains a sequence of N transactions where N is equal to or greater than one. The block header includes a hash of the block's transactions, as well as a hash of the prior block's header. In this way, all transactions on the ledger may be sequenced and cryptographically linked together. Accordingly, it is not possible to tamper with the ledger data without breaking the hash links. A hash of a most recently added blockchain block represents every transaction on the chain that has come before it, making it possible to ensure that all peer nodes are in a consistent and trusted state. The chain may be stored on a peer node file system (i.e., local, attached storage, cloud, etc.), efficiently supporting the append-only nature of the blockchain workload. The current state of the immutable ledger represents the latest values for all keys that are included in the chain transaction log. Because the current state represents the latest key values known to a channel, it is sometimes referred to as a world state. Chaincode invocations execute transactions against the current state data of the ledger. To make these chaincode interactions efficient, the latest values of the keys may be stored in a state database. The state database may be simply an indexed view into the chain's transaction log, it can therefore be regenerated from the chain at any time. The state database may automatically be recovered (or generated if needed) upon peer node startup, and before transactions are accepted.)
One of ordinary skill in the art would have recognized that applying the known technique of Vaughn to the known invention of Madisetti would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate contract features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the system to include wherein the incoming parameter for the second contract further comprises a first contract address of the first contract, and wherein the storing state data of the first contract in the blockchain by executing the first function comprises: determining, by executing the first function, whether a state database comprises state data corresponding to the first contract address, and storing the state data of the first contract in the state database with the first contract address when the state database does not comprise the state data corresponding to the first contract address result in an improved invention because applying said technique will ensure that a stater database is created to store and mange state data, thus improving the overall performance of the invention.
7. Regarding claims 4 and 13, Madisetti does not explicitly disclose wherein the state data of the first contract comprises a first field for storing the code identifier.
However, Vaughn teaches wherein the state data of the first contract comprises a first field for storing the code identifier, (Para. 0023, A blockchain is a distributed system which includes multiple nodes that communicate with each other. A blockchain operates programs called chaincode (e.g., smart contracts, etc.), holds state and ledger data, and executes transactions. Some transactions are operations invoked on the chaincode. In general, blockchain transactions typically must be “endorsed” by certain blockchain members and only endorsed transactions may be committed to the blockchain and have an effect on the state of the blockchain.; and Para. 0037-0038, The smart contract may write data to the blockchain in the format of key-value pairs. Furthermore, the smart contract code can read the values stored in a blockchain and use them in application operations. The smart contract code can write the output of various logic operations into the blockchain. The code may be used to create a temporary data structure in a virtual machine or other computing platform. Data written to the blockchain can be public and/or can be encrypted and maintained as private. The temporary data that is used/generated by the smart contract is held in memory by the supplied execution environment, then deleted once the data needed for the blockchain is identified. A chaincode may include the code interpretation of a smart contract, with additional features. As described herein, the chaincode may be program code deployed on a computing network, where it is executed and validated by chain validators together during a consensus process. The chaincode receives a hash and retrieves from the blockchain a hash associated with the data template created by use of a previously stored feature extractor.)
One of ordinary skill in the art would have recognized that applying the known technique of Vaughn to the known invention of Madisetti would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate code identifier features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the system to include wherein the state data of the first contract comprises a first field for storing the code identifier result in an improved invention because applying said technique will ensure that the code identifier is stored to be reused, thus improving the overall user convenience of the invention.
8. Regarding claims 5 and 14, Madisetti as modified does not explicitly disclose wherein the state data of the first contract comprises a second field for storing the value of the immutable variable.
However, Turgman teaches wherein the state data of the first contract comprises a second field for storing the value of the immutable variable, (Para. 0049, After the smart contract has been deployed to blockchain network 112, the smart contract becomes immutable (i.e., the contract language and contract terms are no longer editable and are read-only). In accordance with an embodiment, the immutable version of the smart contract (shown as text 502) is displayed to all the parties to the smart contract (e.g., via GUI 116A, GUI 116B, etc.). For example, FIG. 5 shows an example GUI screen 500 in which an immutable version of the agreed upon smart contract is shown.; and Para. 0062, At this stage, smart contract 604 is in the pending state, as neither content provider nor consumer have signed the contract. Accordingly, the complimentary functions associated with smart contract methods for executing (i.e., signing) the contract may return a positive result and cause a user interface element to be rendered on both of GUI 116A and GUI 116A. For example, FIG. 7A is an example GUI screen 700A in which user interface elements are displayed to a service provider based on querying smart contract 604 on behalf of the service provider in accordance with an example embodiment, and FIG. 7B is an example GUI screen 700B in which user interface elements are displayed to a consumer based on querying smart contract 604 on behalf of the consumer in accordance with an example embodiment. As shown in FIGS. 7A and 7B, text 702 representing an immutable version of a smart contract 604 is provided via a GUI (e.g., GUI 116A and GUI 116B)).
One of ordinary skill in the art would have recognized that applying the known technique of Turgman to the known invention of Madisetti as modified would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate contract features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the system to include wherein the state data of the first contract comprises a second field for storing the value of the immutable variable result in an improved invention because applying said technique will ensure that values are stored correctly and securely, thus improving the overall security of the invention.
9. Regarding claims 6 and 15, Madisetti discloses comprising: receiving a second transaction for storing the first code, wherein the second transaction invokes the system contract, and wherein an incoming parameter for the system contract comprises the code identifier and the first code, and storing the code identifier and the first code in state data of the system contract based on the second transaction, (Para. 0003, Blockchain is a distributed and public ledger which maintains records of all the transactions. A blockchain network is a truly peer-to-peer network and it does not require a trusted central authority or intermediaries to authenticate or to settle the transactions or to control the network infrastructure. Users can interact and transact with the blockchain networks through Externally Owned Account (EOAs), which are owned and controlled by the users. Each EOA has a balance (in certain units of a Cryptocurrency associated with the Blockchain network) associated with it. EOAs do not have any associated code. All transactions on a blockchain network are initiated by EOAs. These accounts can send transactions to other EOAs or contract accounts. Another type of accounts support by second generation programmable Blockchain platforms are the Contract Accounts. A Contract Account is created and owned by an EOA and is controlled by the associated contract code which is stored with the account. The contract code execution is triggered by transactions sent by EOAs or messages sent by other contracts.; and Para. In current implementations of applications with linked smart contracts, one smart contract can send a transaction to another contract or reference public state variables of other contracts. However, such calls and variable references must be coded in the smart contract and the contract code once deployed cannot be changed. If one contract in a system of linked contracts must be changed then it would need re-deployment of all the other linked contracts as the code has to be changed.; and Para. 0022, a method of exchanging value across a blockchain network comprising receiving a first transaction smart contract, that may be a transaction, comprising a transaction amount global variable name request and a transaction amount, recording the first transaction to a second transaction smart contract on a first blockchain network, and registering the first transaction amount global variable name to a global variable name system, defining a transaction amount global variable. The method further comprises defining a value of the transaction amount global variable responsive to the transaction amount, receiving a second transaction smart contract, which may also be a financial transaction, comprising a second transaction global variable name request and a second transaction amount, and registering the second transaction global variable name request to the global variable name system, defining a second transaction global variable. The method further comprises defining a value of the second transaction global variable responsive to the second transaction amount, receiving a transaction notification comprising the second transaction global variable name and a transaction value, recording the transaction notification to the second smart contract, and updating the value of the second transaction global variable responsive to the transaction value.)
10. Regarding claims 7 and 16, Madisetti discloses further comprising: receiving a third transaction for updating the first code, wherein the third transaction invokes the system contract, and the incoming parameter for the system contract comprises an updated first code; and storing the updated first code in the state data of the system contract based on the third transaction, (Para. 0003, Blockchain is a distributed and public ledger which maintains records of all the transactions. A blockchain network is a truly peer-to-peer network and it does not require a trusted central authority or intermediaries to authenticate or to settle the transactions or to control the network infrastructure. Users can interact and transact with the blockchain networks through Externally Owned Account (EOAs), which are owned and controlled by the users. Each EOA has a balance (in certain units of a Cryptocurrency associated with the Blockchain network) associated with it. EOAs do not have any associated code. All transactions on a blockchain network are initiated by EOAs. These accounts can send transactions to other EOAs or contract accounts. Another type of accounts support by second generation programmable Blockchain platforms are the Contract Accounts. A Contract Account is created and owned by an EOA and is controlled by the associated contract code which is stored with the account. The contract code execution is triggered by transactions sent by EOAs or messages sent by other contracts.; and Para. 0010, Decentralized blockchain applications and smart contracts in second and third generation blockchain platforms such as Ethereum, Hyperledger, Neo, Lisk and EOS that rely on a large number of linked smart contracts interacting with each other can benefit from the proposed Bulletin Board Messaging Framework (BBMF) and the Global Variable Name System (GVNS) technologies. In current implementations of applications with linked smart contracts, one smart contract can send a transaction to another contract or reference public state variables of other contracts. However, such calls and variable references must be coded in the smart contract and the contract code once deployed cannot be changed. If one contract in a system of linked contracts must be changed then it would need re-deployment of all the other linked contracts as the code has to be changed.)
11. Regarding claims 8 and 17, Madisetti discloses further comprising: receiving a fourth transaction for invoking the first contract, reading the first code from the blockchain based on the code identifier, (Para. 0051-0060; and Para. 0115-0116, Additionally, security offers may be received and interpreted to determine their type (e.g. loan, offer, etc.) with the determined security offer type being recorded to the associated security offer smart contract. Similarly, security seller requests may be received and have their type determined, the determined security seller type being recorded to the associated security seller smart contract. Referring now to FIG. 22 an illustration of a lending pool generator for generating lending pool smart contracts is described in more detail. Each lender 1200, 1202, 1204 contributes 1206 to a lending pool with conditions including the amount of money to lend, duration of lending and expected returns. Lenders 1200, 1202, 1204 can have different conditions and may contribute to one or more lending pools. A lending pool smart contract generator 1208 is used to generate smart contracts 1210, 1212, 1214 which represent the lending pools. Referring now to FIG. 23 an illustration of a matching engine for matching borrowers to lending pools is described in more detail. Each borrower 1250, 1252, 1254, 1256 requests money with conditions including the amount of money to borrow, duration for which money is to be borrowed and acceptable rate of interest.; and Para. 0003, All transactions on a blockchain network are initiated by EOAs. These accounts can send transactions to other EOAs or contract accounts. Another type of accounts support by second generation programmable Blockchain platforms are the Contract Accounts. A Contract Account is created and owned by an EOA and is controlled by the associated contract code which is stored with the account. The contract code execution is triggered by transactions sent by EOAs or messages sent by other contracts.)
Madisetti does not explicitly disclose obtaining the code identifier and the value of the immutable variable from the state data of the first contract based on the fourth transaction
However, Vaughn teaches obtaining the code identifier and the value of the immutable variable from the state data of the first contract based on the fourth transaction, (Para. 0025, A ledger is a sequenced, tamper-resistant record of all state transitions of a blockchain. State transitions may result from chaincode invocations (i.e., transactions) submitted by participating parties (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). A transaction may result in a set of asset key-value pairs being committed to the ledger as one or more operands, such as creates, updates, deletes, and the like. The ledger includes a blockchain (also referred to as a chain) which is used to store an immutable, sequenced record in blocks. The ledger also includes a state database which maintains a current state of the blockchain. There is typically one ledger per channel. Each peer node maintains a copy of the ledger for each channel of which they are a member.; and Para. 0027, The current state of the immutable ledger represents the latest values for all keys that are included in the chain transaction log. Because the current state represents the latest key values known to a channel, it is sometimes referred to as a world state. Chaincode invocations execute transactions against the current state data of the ledger. To make these chaincode interactions efficient, the latest values of the keys may be stored in a state database. The state database may be simply an indexed view into the chain's transaction log, it can therefore be regenerated from the chain at any time. The state database may automatically be recovered (or generated if needed) upon peer node startup, and before transactions are accepted.)
One of ordinary skill in the art would have recognized that applying the known technique of Vaughn to the known invention of Madisetti would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate contract features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the system to include obtaining the code identifier and the value of the immutable variable from the state data of the first contract based on the fourth transaction result in an improved invention because applying said technique will ensure that deploying contracts are more streamlined to reduce the workload, thus improving the overall performance of the invention.
Madisetti does not explicitly disclose executing the first contract based on the first code and the value of the immutable variable.
However, Turgman teaches executing the first contract based on the first code and the value of the immutable variable, (Para. 0111-0112, In one implementation of the foregoing method, said deploying comprises: replacing one or more variables of the smart contract with one or more user-specified parameters; compiling the smart contract with the user-specified parameters into a format suitable for the blockchain; and causing the compiled smart contract to be deployed to the blockchain for execution thereby. In another implementation of the foregoing method, said querying comprises: receiving, from the smart contract, an event notification that indicates that a state of the smart contract has changed; and querying a function of the smart contract that is configured to provide an indication as to whether the identified user is enabled to perform the action based on one or more inputs provided to the function; wherein said presenting comprises: responsive to the indication indicating that the identified user is enabled to perform the action, presenting the user interface representation.)
One of ordinary skill in the art would have recognized that applying the known technique of Turgman to the known invention of Madisetti as modified would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate contract features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the system to include executing the first contract based on the first code and the value of the immutable variable result in an improved invention because applying said technique will ensure that deploying contracts are more streamlined to reduce the workload, thus improving the overall performance of the invention.
12. Regarding claims 9 and 18, Madisetti as modified does not explicitly disclose wherein the fourth transaction invokes the first function of the first contract, and wherein the executing the first contract based on the first code and the value of the immutable variable comprises: replacing an immutable variable in the first function with a value of a first variable to obtain a third code; and executing the third code.
However, Turgman teaches wherein the fourth transaction invokes the first function of the first contract, and wherein the executing the first contract based on the first code and the value of the immutable variable comprises: replacing an immutable variable in the first function with a value of a first variable to obtain a third code; and executing the third code, (Para. 0111-0113, In one implementation of the foregoing method, said deploying comprises: replacing one or more variables of the smart contract with one or more user-specified parameters; compiling the smart contract with the user-specified parameters into a format suitable for the blockchain; and causing the compiled smart contract to be deployed to the blockchain for execution thereby…said querying comprises: receiving, from the smart contract, an event notification that indicates that a state of the smart contract has changed; and querying a function of the smart contract that is configured to provide an indication as to whether the identified user is enabled to perform the action based on one or more inputs provided to the function; wherein said presenting comprises: responsive to the indication indicating that the identified user is enabled to perform the action, presenting the user interface representation.; and Para. 0039, A second file associated with a smart contract template may comprise the source code of the smart contract. The second file may be referred to as a source code file. The source code specifies a set of rules under which the parties to the smart contract agree to interact with each other. If and when the rules are met, the agreement is automatically enforced. The smart contract code facilitates, verifies, and enforces the negotiation or performance of the agreement. The source code may be written in a programming language suitable for compilation and execution by a virtual machine executing in blockchain network 112… during deployment of the smart contract to blockchain network 112, the data and/or variables may be replaced by the values specified for such data and/or variables during smart contract generation and/or compilation. It is noted that the usage of a definition file and/or source code for each smart contract template is just one possible implementation and that any number of files may be used for any given smart contract template.)
One of ordinary skill in the art would have recognized that applying the known technique of Turgman to the known invention of Madisetti as modified would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate contract features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the system to include wherein the fourth transaction invokes the first function of the first contract, and wherein the executing the first contract based on the first code and the value of the immutable variable comprises: replacing an immutable variable in the first function with a value of a first variable to obtain a third code; and executing the third code result in an improved invention because applying said technique will ensure that contracts have fixed values when executing the contract, thus improving the overall performance of the invention.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
System and method for managing a blockchain cloud service (US 10762079 B2) teaches a system and method for implementing a distributed ledger a blockchain cloud service. The blockchain cloud service can include nodes of the distributed ledger and a management console component. The management console component can include a web application running in a script runtime environment, a plurality of backend of APIs for communicating with various nodes of the blockchain cloud service, and a plurality of client APIs configured to be invoked by a client application. The plurality of client APIs uses one or more of the plurality of backend APIs in provisioning the distributed ledger as a blockchain cloud service, and in managing the managing the blockchain cloud service.
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
In addition to the foregoing, other aspects are described in the claims, drawings, and text. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Davida L. King whose telephone number is (571) 272-4724. The examiner can normally be reached M-F 8am-5pm.
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, Neha Patel can be reached on (571) 270-1492. 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.
/D.L.K./Examiner, Art Unit 3699
Prosecution Insights