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 5/8/2026 have been fully considered
35 USC § 102 & 35 USC § 103:
Regarding Applicant’s Argument (pages: 7-11): Examiner’s response:- Applicant’s arguments with respect to the rejection(s) of under 35 USC § 102/103 have been fully considered, upon further consideration, a new ground(s) of rejection is made in view of US 20200250176 A1 Padmanabhan; Prithvi Krishnan (hereinafter Pad).The examiner believes amendments directed towards parameters/factors involved in the enforcement mechanism and governance information will help push over the current prior art and push the application towards allowance. If the applicant would like further guidance for overcoming the prior art(s), please call the examiner at 571-272-5212.
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.
The factual inquiries 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-2,4-11, 14-18 and 20-21 are rejected under 35 U.S.C. 103 as being unpatentable over US 20190340269 A1; Biernat; Tim S. et al. (hereinafter Biernat) and US 20200250176 A1 Padmanabhan; Prithvi Krishnan (hereinafter Pad).
Regarding claim 1, Biernat teaches A system comprising: a memory storing a plurality of interlinked blockchains comprising a core blockchain and a first blockchain; (Biernat [FIG.13 & 18] show the memory storing a plurality of interlinked blockchains comprising a core blockchain and a first blockchain; [121] The blockchain-enabled industrial controller 1210 (or another blockchain-enabled industrial device 1102) that controls the industrial assets in Production Area 3 can link the blockchains generated by ... [123] further elaborates on the plurality of blockchains linked [FIG.7] elaborates on the core) and at least one processor coupled to the memory configured to: create, in the first blockchain via a linking block, a first entity, a second entity, a behavior comprising a task, and a relationship comprising the behavior, the first entity, and the second entity; (Biernat [0052] A distributed ledger 402 of all these changes is maintained by all entities 406 (or nodes) that participate in the platform. If all entities 406 apply the changes to their own copy of the data then the copies remain consistent across the entities 406 without the need for a single golden copy. Each entity maintains a copy of the ledger 402, which represents a continuous chain of transaction blocks 404, hence the term “blockchain.” When a transaction is performed on the data by one of the entities 406, all entities 406 process the transaction and make a determination regarding the validity of the transaction. [0053] A blockchain consists of a data structure that orders blocks and links the blocks cryptographically, thereby acting as an immutable, verifiable, distributed ledger. Blockchains require no central authority; instead, trust is established and enforced cryptographically, with participating nodes (e.g., devices associated with entities 406) acting as a consortium and voting on the validity of a block using a consensus mechanism to manage the distributed ledger. FIG. 5 is a graphic illustrating a blockchain architecture. Blockchains are a linked hierarchical list 502 of transaction blocks 404, where chains of related, linked transaction blocks 404 within the hierarchy (e.g., chain 504) stem from an initial genesis block 506. Each block 404 has a cryptographic identity, which is calculated by the header data 508 in the block. Each block 404 contains the hash of the previous block in the chain. [0071] In some embodiments, device configuration application 1208 can allow users to configure blockchains to be generated by a blockchain-enabled device 1102 (e.g., controller 1210 or another type of industrial device) using unified modeling language (UML) diagrams or other interfaces for creating linkages and defining hierarchies.[0089] The blockchain systems 1704 can be owned by, or may represent, entities representing different disciplines within the manufacturing, supply, distribution, and/or retail chain, including but not limited to engineering and product development, product manufacturing, product testing, shipping, technical support, business and accounting, etc.[113] to generating private blockchains 1304b that record proprietary manufacturing data generated in connection with the fabrication of the sub-assemblies, blockchain-enabled industrial devices 1102 at the supplier entities 1902 can generate public blockchains 1304a that record information regarding manufacture of the sub-assemblies permitted to be shared with the manufacturing entity 1904.[121-123] elaborates on utilization of linking blocks [FIG.13 & 18] show overall flow of system which includes creation/storage of entities and relationship.) and linking a second blockchain to the first blockchain via a linking block located on the first blockchain, wherein the second blockchain records transactions for the relationship, (Biernat [FIG.13] shows the creation of a plurality of blockchains that are all linked together for corresponding transactions that are being recorded [0091] an MES system can perform the blockchain creation and management functions for multiple monitored devices and systems within the plant. These proxy systems can synchronize blockchains from different sources, certify which chains are trusted, and perform other such blockchain management functions [0097] The OEM's blockchain-enabled industrial devices 1102 can also be configured to generate public blockchains 1304a that record publicly shared transaction data that can be accessed and viewed by other devices that participate in the blockchain ecosystem, including devices associated with the customer manufacturing entity [0119] industrial blockchains can render their associated transaction data available to all entities and devices that make up the blockchain ecosystem. Blockchain-enabled industrial devices 1102 can also support semi-public industrial blockchains that allow transaction data to be shared only with a specified subset of all entities within the industrial blockchain ecosystem (e.g., as in the OEM and sub-assembly supplier examples described above, in which the public blockchains are only made accessible to the relevant OEM or supplier). Similarly, private blockchains 1304b that only share transaction data among devices [FIG.17&18] elaborates on linked blockchains created and maintained) wherein the first blockchain comprises an enforcement mechanism to complete the task. (Biernat [0016] FIG. 9 is a generalized diagram illustrating implementation of smart contracts within a blockchain-driven system.[0054] FIG. 6 is a diagram illustrating a general architecture of an example blockchain. Data 610 associated with the block's transactions is hashed, and the collection of transaction data 610 and their associated hashes 608 create a Merkle tree 606 of hashes 608 (only two items of data 610 are shown in FIG. 6 for clarity; however, a block 404 may be associated with more than two transactions). [0060] implementing and enforcing smart contracts, which define rules or agreements between participants in the blockchain network. FIG. 9 is a generalized diagram illustrating implementation of smart contracts within a blockchain-driven system. In general, smart contracts are sets of logic 902 that execute on the blockchain and generate new types of transactions in accordance with rules defined by the logic. The smart contract logic 902 is executed by the participants of the blockchain. When a smart contract transaction 904 is generated, the logic 902 executes on the transaction 904 and may create several new transactions 906 designed to satisfy the contract [0079] programmatic entities that build blocks based on Merkle tree information for gathered transactions—in connection with consortium-based validation of blocks of transactions.) … governance information that is static and immutable (Biernat [0053] A blockchain consists of a data structure that orders blocks and links the blocks cryptographically, thereby acting as an immutable, verifiable, distributed ledger. Blockchains require no central authority; instead, trust is established and enforced cryptographically, with participating nodes (e.g., devices associated with entities 406) acting as a consortium and voting on the validity of a block using a consensus mechanism to manage the distributed ledger. FIG. 5 is a graphic illustrating a blockchain architecture. Blockchains are a linked hierarchical list 502 of transaction blocks 404, where chains of related, linked transaction blocks 404 within the hierarchy (e.g., chain 504) stem from an initial genesis block 506. Each block 404 has a cryptographic identity, which is calculated by the header data 508 in the block. Each block 404 contains the hash of the previous block in the chain. [0054] FIG. 6 is a diagram illustrating a general architecture of an example blockchain. Data 610 associated with the block's transactions is hashed, and the collection of transaction data 610 and their associated hashes 608 create a Merkle tree .... [0127] Systems that support aggregation of component part blockchains into aggregate blockchains associated with a sub-assembly or final assembled product, as described above, can also leverage these aggregate assembly blockchains in connection with warranty returns. For example, a manufacturing entity that produces and ships a sub-assembly or assembled product can store, as immutable composite blockchains, assembly information identifying the various component parts that were used in the assembled product. This assembly information can include some or all of the provenance and/or part characteristic data described above. )
Biernat lacks explicitly and orderly teaching all of the enforcement mechanism being located at a location in the first blockchain and wherein the first entity, the second entity, the behavior, the relationship, and the enforcement mechanism collectively represent for governance information that is static and immutable and wherein the governance information constrains how the transactions are recorded in the second blockchain. However Pad teaches the enforcement mechanism being located at a location in the first blockchain (Pad [188] written into the blockchain must be in compliance with the defined metadata for such information associated with the application. Such compliance may be enforced by the smart contracts depicted here within the blockchain at the blockchain services interface 190. [230] transaction type stores a “related entity” as metadata within the blockchain having a transaction type of either “metadata” if it shares the same type as normal metadata or having a transaction type of “related entity” if separate. Still further, a “stored record” transaction type may be utilized to store a record having multiple distinct data elements embedded therein, typically which will be defined by metadata specified by an application developer.[0231] For instance, when a block or transaction within a block having a particular transaction type corresponding to transactions utilizing a declared smart action is to be added to the blockchain, the consensus protocol type to be used to commit the block or transaction therein to the blockchain is PoS, when a block or transaction therein with a particular asset having the type “document” is to be added to the blockchain, the consensus protocol type...[450] insert into a corresponding blockchain transaction to update or add the data associated with the new application at the blockchain; and issuing an acknowledgement to the user device confirming successful processing of the SQL statement against the materialized view pursuant to the corresponding blockchain transaction being accepted by consensus to the blockchain and successfully updating or adding the data associated with the new application at the blockchain.[562-569] elaborate on the enforcement mechanism being located at a location in the first blockchain [FIG.4A & 21] show the enforcement mechanism being located at a location in the first blockchain) and wherein the first entity, the second entity, the behavior, the relationship, and the enforcement mechanism collectively represent for governance information that is static and immutable. (Pad [0075] A blockchain is a continuously growing list of records, grouped in blocks, which are linked together and secured using cryptography. Each block typically contains a hash pointer as a link to a previous block, a timestamp and transaction data. By design, blockchains are inherently resistant to modification of the data. A blockchain system essentially is an open, distributed ledger that records transactions between two parties in an efficient and verifiable manner, which is also immutable and permanent. [151] and in which SQL queries requesting read-only access are processed against the materialized view by translating the read-only SQL queries into a shared ledger transaction to retrieve the requested data from the shared ledger. [448] in which SQL queries requesting read-only access are processed against the materialized view by translating the read-only SQL queries into a blockchain transaction to retrieve the requested data associated with the new application from the blockchain. [FIG.1C & 4A] show corresponding visual on the enforcement mechanism collectively represent for governance information that is static and immutable) and wherein the governance information constrains how the transactions are recorded in the second blockchain. (Pad [503] the structure has the benefit of greatly simplifying queries originating from any of the accessible cloud platforms 186 which may utilize standard SQL without having to identify the blockchain or construct more complex blockchain transactions to retrieve the data, as the replication of the data to the materialized view 920 is performed automatically by the smart contract triggers. According to such embodiments, SQL commands which update, create, or delete records are not permitted for execution against the materialized view, however, such SQL commands which update, create, or delete records will be accepted and translated to the apex translation engine and Apex code interface 454 (shown at FIG. 4B) into native blockchain executable compliant code to perform the equivalent action of an SQL update, create, or delete command, but as a blockchain transaction which is then transacted against the blockchain, submitted for consensus, and then accepted onto the blockchain assuming voting or consensus is successful. Note also that a smart contract will execute to validate the transaction against the blockchain to enforce data compliance with the defined metadata persisted at the blockchain. [0639] Problematically, each of the different blockchain platforms have different smart contract requirements for executing such business rules, resulting in different syntaxes, different permissible conditions and criteria and different mechanisms by which to deploy any created rules to the respective blockchain.[0646] Normally, the creation of such business rules requires specialized syntax to be developed by a programmer for execution via a blockchain platform's smart contract execution engine, with such syntax being different for different blockchain platforms. However, in the event that the metadata rules user or blockchain administrator utilizes the Blockchain Metadata Definition Manager 196 provided by the host organization's suite of blockchain services, then the blockchain administrator need only define the rule via the GUIs, associating them with particular declared applications or specific types of transactions (or all transactions), and then, once the submitted rule is approved by the blockchain network's consensus mechanism, the defined rule will be executed automatically by host organization's blockchain services interface and associated smart contract execution and management engines.[639-644] elaborate on the matter [FIG.4A&4B] show and wherein the governance information constrains how the transactions are recorded in the second blockchain.) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to take all prior methods and make the addition of Pad in order to efficiently help create a more secure and enhanced blockchain integrated system (Pad [0010] using an electronic ledger replication system known as a blockchain. Bitcoin solves the problem of implementing decentralized digital cash, but its security model limits its efficiency and throughput, its design only supports a single asset, and the platform provides only limited support for custom programs that determine asset movement, sometimes called smart contracts, without any mechanism by which to customize the underlying functions or the associated smart contracts. [0012] The present state of the art may therefore benefit from the systems, methods, and apparatuses for improving upon, modifying, and expanding upon blockchain and related distributed ledger technologies by providing means for systems, methods, and apparatuses for distributing a metadata driven application to customers and non-customers of a host organization using Distributed Ledger Technology (DLT) in conjunction with a cloud based computing environment as is described herein.[0040] FIG. 12 depicts a flow diagram illustrating a method for implementing efficient storage and validation of data and metadata within a blockchain using Distributed Ledger Technology (DLT), in accordance with described embodiments;[503] the structure has the benefit of greatly simplifying queries originating from any of the accessible cloud platforms 186 which may utilize standard SQL without having to identify the blockchain or construct more complex blockchain transactions to retrieve the data, as the replication of the data to the materialized view 920 is performed automatically by the smart contract triggers. According to such embodiments, SQL commands which update, create, or delete records are not permitted for execution against the materialized view, however, such SQL commands which update, create, or delete records will be accepted and translated to the apex translation engine and Apex code interface 454 (shown at FIG. 4B) into native blockchain executable compliant code to perform the equivalent action of an SQL update, create, or delete command, but as a blockchain transaction which is then transacted against the blockchain, submitted for consensus, and then accepted onto the blockchain assuming voting or consensus is successful. Note also that a smart contract will execute to validate the transaction against the blockchain to enforce data compliance with the defined metadata persisted at the blockchain.)
Corresponding system claim 16 is rejected similarly as claim 1 above.
Corresponding product claim 20 is rejected similarly as claim 1 above. Additional Limitations: computer readable medium capable of reading and executing instructions (Biernat [FIG.11 in conjunction with FIG. 24] shows the system with corresponding memory and processors capable of reading and executing instructions)
Regarding claim 2, Biernat and Pad teach The system of claim 1, the at least one processor further configured to: record a transaction between the first entity and the second entity in the second blockchain by adding a record block to the second blockchain, the record block comprising a result of the task. (Biernat [0052] all entities work to keep the data model's transactions ordered and consistent. Blocks 404 of changes to the data are recorded as a transaction [0058] Merkle tree for the gathered transactions and compete to build a valid block out of the Merkle tree. The first miner 802 to create a block is rewarded. The block is then validated by the other entities 406 based on the hashes. If valid, the block is added to the blockchain 808 [0065] ...blockchain instructions that create blocks representing transactions received or executed by the blockchain-enabled industrial device 1102, add the blocks to industrial blockchains maintained on the device 1102, and update the device's blockchain ledger [76-79] elaborate on adding a record block to the second blockchain corresponding to a transaction between plurality of entities)
Corresponding system claim 17 is rejected similarly as claim 2 above.
Regarding claim 4, Biernat and Pad teach The system of claim 1, wherein a location of the enforcement mechanism in the first blockchain is a first location in the plurality of interlinked blockchains, and wherein the enforcement mechanism references a second location in the plurality of interlinked blockchains that comprises a reference enforcement mechanism that completes the task. (Pad [0168] With such embodiments, a materialized view may be provided for every one of the authorized network participants (e.g., founders and partners) which then permits SQL transactions to be processed against the materialized view from the perspective of such participants, with the host organization providing the necessary translation from the received SQL statements to the necessary shared ledger transaction commands, be a blockchain, DLT data store, or even another relational database store. [0199] a mechanism by which declared smart actions for assets, tokens, value, or payload entries from one blockchain may be securely used within a completely separate blockchain via a pre-defined exchange or conversion scheme, and yet, be permissibly moved back to the original chain, if necessary. By convention, the original blockchain is referred to as the main chain or the primary blockchain, whereas any additional blockchains which allow users to transact within them utilizing the tokens, values, or payload of the main chain are referred to as sidechains. For instance, there may be a private blockchain with a defined linkage to a public blockchain, thus allowing tokens, value, or payload data to be securely moved between the public blockchain and the private blockchain. [333] recorded transactions which is described above, with the added addition that once the playback is complete, all metadata 489 and the records from the temporary view at the database system 130 of the host organization is then written onto a restored blockchain 440 or written to a new blockchain repository, thus creating new assets on the blockchain within which the records [574-576 & 585-586] elaborate on wherein a location of the enforcement mechanism in the first blockchain is a first location in the plurality of interlinked blockchains, and wherein the enforcement mechanism references a second location in the plurality of interlinked blockchains that comprises a reference enforcement mechanism that completes the task.[FIG.3A &FIG.4A] shows corresponding visual)
Regarding claim 5, Biernat and Pad teach The system of claim 1, wherein the enforcement mechanism provides immutability and transparency in method and operation, (Biernat [0053] A blockchain consists of a data structure that orders blocks and links the blocks cryptographically, thereby acting as an immutable, verifiable, distributed ledger. Blockchains require no central authority; instead, trust is established and enforced cryptographically, with participating nodes (e.g., devices associated with entities 406) acting as a consortium and voting on the validity of a block using a consensus mechanism to manage the distributed ledger. FIG. 5 is a graphic illustrating a blockchain architecture. Blockchains are a linked hierarchical list 502 of transaction blocks 404, where chains of related, linked transaction blocks 404 within the hierarchy (e.g., chain 504) stem from an initial genesis block 506. Each block 404 has a cryptographic identity, which is calculated by the header data 508 in the block. Each block 404 contains the hash of the previous block in the chain. [0054] FIG. 6 is a diagram illustrating a general architecture of an example blockchain. Data 610 associated with the block's transactions is hashed, and the collection of transaction data 610 and their associated hashes 608 create a Merkle tree .... [0127] Systems that support aggregation of component part blockchains into aggregate blockchains associated with a sub-assembly or final assembled product, as described above, can also leverage these aggregate assembly blockchains in connection with warranty returns. For example, a manufacturing entity that produces and ships a sub-assembly or assembled product can store, as immutable composite blockchains, assembly information identifying the various component parts that were used in the assembled product. This assembly information can include some or all of the provenance and/or part characteristic data described above ) and wherein the enforcement mechanism comprises a smart contract, an append-only structure, a blockchain transaction, a journaling protocol, a cryptographic assurance, a non-volatile protocol, or a circuit-controlled protocol. (Biernat [0016] FIG. 9 is a generalized diagram illustrating implementation of smart contracts within a blockchain-driven system.[0054] FIG. 6 is a diagram illustrating a general architecture of an example blockchain. Data 610 associated with the block's transactions is hashed, and the collection of transaction data 610 and their associated hashes 608 create a Merkle tree 606 of hashes 608 (only two items of data 610 are shown in FIG. 6 for clarity; however, a block 404 may be associated with more than two transactions). [0060] implementing and enforcing smart contracts, which define rules or agreements between participants in the blockchain network. FIG. 9 is a generalized diagram illustrating implementation of smart contracts within a blockchain-driven system. In general, smart contracts are sets of logic 902 that execute on the blockchain and generate new types of transactions in accordance with rules defined by the logic. The smart contract logic 902 is executed by the participants of the blockchain. When a smart contract transaction 904 is generated, the logic 902 executes on the transaction 904 and may create several new transactions 906 designed to satisfy the contract [0079] programmatic entities that build blocks based on Merkle tree information for gathered transactions—in connection with consortium-based validation of blocks of transactions.)
Regarding claim 6, Biernat and Pad teach The system of claim 1, wherein the second blockchain inherits the enforcement mechanism from the first blockchain. (Biernat [0054] FIG. 6 is a diagram illustrating a general architecture of an example blockchain. Data 610 associated with the block's transactions is hashed, and the collection of transaction data 610 and their associated hashes 608 create a Merkle tree 606 of hashes 608 (only two items of data 610 are shown in FIG. 6 for clarity; however, a block 404 may be associated with more than two transactions). In the illustrated example, each data item 610a and 610b is hashed to yield two corresponding hash values 608a and 608b. These two hashes 608a and 608b are combined into another hash value 602 at the next higher level in the Merkle tree hierarchy. Hash values at a given level of the Merkle tree may be combined with other hash values on that level to yield hash values at the next higher level until the top of the Merkle tree hierarchy is reached [0065] Hashing component 1108 can be configured to hash transaction data and generate Merkle trees in accordance with a blockchain instruction. Instruction execution component 1110 can be configured to execute industrial blockchain instructions that create blocks representing transactions received or executed by the blockchain-enabled industrial device [0079] blockchain engine ... configured to hash transaction data and generate Merkle trees in accordance with the transaction instruction 1402. Since new blocks leverage the hash of the previous block in the chain to generate the hash for the new block, blockchain engine 1128 can also receive the previous hash 1406 of the previous block in the chain. If the previous block comprises transactions that were generated by the controller 1210 itself, the previous hash 1406 may have been generated by the blockchain engine 1128 itself when the previous block was generated....)
Regarding claim 7, Biernat and Pad teach The system of claim 1, wherein the second blockchain further comprises a genesis block, a header block comprising a link to the first blockchain, (Biernat [0053] FIG. 5 is a graphic illustrating a blockchain architecture. Blockchains are a linked hierarchical list 502 of transaction blocks 404, where chains of related, linked transaction blocks 404 within the hierarchy (e.g., chain 504) stem from an initial genesis block 506. Each block 404 has a cryptographic identity, which is calculated by the header data 508 in the block. Each block 404 contains the hash of the previous block in the chain.) a block that stores the enforcement mechanism, and one or more record blocks, wherein the block that stores the enforcement mechanism precedes the one or more record blocks. (Biernat [0055] The Merkle tree 606 is stored separately from the block 404, and only the root fingerprint 612 (the top hash) is stored in the block 404. Each block 404 also contains a hash 604 of the content of the immediately preceding block in the chain. For each block 404, the Merkle tree of hashes 608 and the hash 604 of the previous block in the chain are used to create the hash 602 for the block. The data 610 is stored in the Merkle tree 606 separately from the block 404, with the root fingerprint 612 being the only part of the Merkle tree 606 stored in the block 404. This nesting of cryptographic hash values yields...[0088] blockchain information to verify that the recipe is from a trusted source before executing, and to verify that the controller itself has been authorized to execute the recipe. Distribution and use of the recipe data can be subject to a smart contract implemented [0105] In response to determining that information stored in the public ledger satisfies a criterion (e.g., a criterion defined in a smart contract) indicating that the OEM is contractually obliged to perform a component replacement or other maintenance action on the machine (e.g., in response to execution of a defined number of machine cycles, when the accumulated machine run time exceeds a defined number of operating hours, when the machine has produced a defined number of parts, etc.), the block chain engine in the industrial controller signs, on behalf of the owner, a verifiable and contractually binding component replacement order as a transaction in the public blockchain. [0107] In addition to the information recorded in the public blockchain ledger as described above, the machine's control devices also maintain a private blockchain ledger (e.g., private blockchains 1304b in FIG. 19) comprising data that can be accessed only by the manufacturing entity. This can include smart contracts [138] The devices 1102 can record this identity and status information for all devices within the plant model blockchain, yielding a Merkle tree of hashes in which each element of the tree represents an item of equipment. This plant model blockchain can record, for each device, such information as...)
Regarding claim 8, Biernat and Pad teach The system of claim 1, the at least one processor further configured to: create a mirrored blockchain to record the transactions between the first entity and the second entity. (Biernat [0051] Blockchain-based platforms can provide access to data from multiple parties in a decentralized manner, in contrast to platforms that share data using a centralized model. FIG. 3 is a graphic illustrating a centralized model for accessing and modifying data. According to this centralized model, there is a single “golden copy” 302 of the data being viewed and acted upon by one or more entities 304 (e.g., systems running applications that leverage the data represented by the golden copy 302, client devices operated by respective users, etc.). Any of the entities 304 can copy data maintained on the golden copy [0052] By contrast, blockchain-driven platforms decentralize the data model, eliminating the need to maintain a golden copy 302 or distributing the multiple coordinated versions of the truth. FIG. 4 is a graphic illustrating a decentralized model. In a decentralized model, all entities 406 that interact with the data have a copy of the data, and all entities work to keep the data model's transactions ordered and consistent. Blocks 404 of changes to the data are recorded as a transaction. A distributed ledger 402 of all these changes is maintained by all entities 406 (or nodes) that participate in the platform. If all entities 406 apply the changes to their own copy of the data then the copies remain consistent across the entities 406 without the need for a single golden copy. Each entity maintains a copy of the ledger 402, which represents a continuous chain of transaction blocks 404, hence the term “blockchain.” When a transaction is performed on the data by one of the entities 406, all entities 406 process the transaction and make a determination regarding the validity of the transaction. If a consensus among the entities 406 is reached regarding the transaction's validity, each entity updates its copy of the ledger 402 accordingly. [81-86] further elaborate on the matter)
Regarding claim 9, Biernat and Pad teach The system of claim 8, the at least one processor further configured to: record a transaction between the first entity and the second entity in both the second blockchain and the mirrored blockchain by adding a first record block to the second blockchain (Biernat [0052] all entities work to keep the data model's transactions ordered and consistent. Blocks 404 of changes to the data are recorded as a transaction [0058] Merkle tree for the gathered transactions and compete to build a valid block out of the Merkle tree. The first miner 802 to create a block is rewarded. The block is then validated by the other entities 406 based on the hashes. If valid, the block is added to the blockchain 808 [0065] ...blockchain instructions that create blocks representing transactions received or executed by the blockchain-enabled industrial device 1102, add the blocks to industrial blockchains maintained on the device 1102, and update the device's blockchain ledger [76-79] elaborate on adding a record block to the second blockchain corresponding to a transaction between plurality of entities) and a second record block to the mirrored blockchain, wherein the first record block and the second record block comprise a result of the task, and wherein the first record block and second record block are congruent. (Biernat [0051] Blockchain-based platforms can provide access to data from multiple parties in a decentralized manner, in contrast to platforms that share data using a centralized model. FIG. 3 is a graphic illustrating a centralized model for accessing and modifying data. According to this centralized model, there is a single “golden copy” 302 of the data being viewed and acted upon by one or more entities 304 (e.g., systems running applications that leverage the data represented by the golden copy 302, client devices operated by respective users, etc.). Any of the entities 304 can copy data maintained on the golden copy [0052] By contrast, blockchain-driven platforms decentralize the data model, eliminating the need to maintain a golden copy 302 or distributing the multiple coordinated versions of the truth. FIG. 4 is a graphic illustrating a decentralized model. In a decentralized model, all entities 406 that interact with the data have a copy of the data, and all entities work to keep the data model's transactions ordered and consistent. Blocks 404 of changes to the data are recorded as a transaction. A distributed ledger 402 of all these changes is maintained by all entities 406 (or nodes) that participate in the platform. If all entities 406 apply the changes to their own copy of the data then the copies remain consistent across the entities 406 without the need for a single golden copy. Each entity maintains a copy of the ledger 402, which represents a continuous chain of transaction blocks 404, hence the term “blockchain.” When a transaction is performed on the data by one of the entities 406, all entities 406 process the transaction and make a determination regarding the validity of the transaction. If a consensus among the entities 406 is reached regarding the transaction's validity, each entity updates its copy of the ledger 402 accordingly. [81-86] further elaborate on the matter)
Corresponding system claim 18 is rejected similarly as claim 9 above.
Regarding claim 10, Biernat and Pad teach The system of claim 1, wherein the core blockchain comprises one or more linking blocks and logic that specifies a condition to create an additional blockchain. (Biernat [0053] A blockchain consists of a data structure that orders blocks and links the blocks cryptographically, thereby acting as an immutable, verifiable, distributed ledger. Blockchains require no central authority; instead, trust is established and enforced cryptographically, with participating nodes (e.g., devices associated with entities 406) acting as a consortium and voting on the validity of a block using a consensus mechanism to manage the distributed ledger. FIG. 5 is a graphic illustrating a blockchain architecture. Blockchains are a linked hierarchical list 502 of transaction blocks 404, where chains of related, linked transaction blocks 404 within the hierarchy (e.g., chain 504) stem from an initial genesis block 506. Each block 404 has a cryptographic identity, which is calculated by the header data 508 in the block. Each block 404 contains the hash of the previous block in the chain. [0100] one or more systems within the blockchain ecosystem (e.g. system 2106 described below in connection with FIG. 21, or another system) can automatically initiate procedures for verifiably purchasing and delivering the replacement component (e.g., generating a purchase order, submitting the order to a vendor, scheduling an on-site visit by the OEM to replace the component, etc.). Similar to techniques described above in connection with FIG. 8, some embodiments of blockchain-enabled industrial devices 1102 may require submission of processing “fees” (e.g., Ether or “gas”) in exchange for execution of smart contract logic on relevant transactions. [0142] Since the industrial blockchain paradigm records transactions originating at one industrial asset or device in a decentralized manner across multiple blockchain-enabled devices, each participating industrial device has a degree of visibility into the operation of other devices or systems by virtue of the distributed ledgers 1126 shared across the devices. In some embodiments, blockchain-enabled industrial devices 1102 can incorporate information in this distributed ledger 1126 into the device's control strategy. For example, as noted above, the blockchain-enabled industrial controller 1210 depicted in FIG. 18 executes a control program 1204 (e.g., a ladder logic program or other type of control program) in connection with monitoring and controlling an industrial machine, system, or process 1320 via I/O 1308. Since industrial controller 1210 supports blockchain functionality, the controller 1210 maintains one or more blockchain ledgers 1126 corresponding to public and/or private industrial blockchains 1304 that record transactions (e.g., industrial events, manufacturing and supply chain activities, etc.) within the blockchain system and/or ecosystem within which the controller 1210 participates. Each ledger 1126 records not only transactions that originate on the controller 1210 or its associated controlled process 1320, but also validated transactions (received as transaction data 1324 or ledger deltas) that originate at other devices or systems that participate in the blockchain system)
Regarding claim 11, Biernat and Pad teach The system of claim 1, the at least one processor further configured to: record a network of nodes in a graph database, wherein a first node in the network of nodes represents the first entity, a second node in the network of nodes represents the second entity, a third node in the network of nodes represents a location in the plurality of blockchains, and a fourth node in the network of nodes represents the behavior. (Biernat [0056] FIG. 7 is a diagram illustrating a generalized architecture of a blockchain platform. The core blockchain functionality 702 (the blockchain creation and management features described above) is implemented on a network 704 of participating devices or nodes [FIG.18] shows visual of network of nodes with different representations [80-82] further elaborate on the matter)
Regarding claim 14, Biernat and Pad teach The system of claim 1, wherein the first entity is a human actor, an account, an object, a token, a group, a process, a computer, an artificial intelligence construct, an avatar representing an actor or action, or an expression or function comprising actions. (Biernat [0058] FIG. 8 is a generalized diagram illustrating creation of blocks and validation of blocks via consensus-based validation. Single transactions 804 performed by entities 406 (participants in the blockchain network) are gathered into blocks 806 by programmatic components executing on the entities 406 referred to as “miners” 802. Miners 802 possess the entire Merkle tree for the gathered transactions and compete to build a valid block out of the Merkle tree. The first miner 802 to create a block is rewarded. The block is then validated by the other entities 406 based on the hashes. If valid, the block is added to the blockchain 808. [0069] other entities that participate in the blockchain (e.g., other controllers or industrial devices within the plant, outside entities that participate in a supply or manufacturing chain such as OEMs or part suppliers, etc.), supplier entities [110-115] elaborates on all the different types of entities involved)
Regarding claim 15, Biernat and Pad teach The system of claim 1, the at least one processor further configured to create, in the first blockchain, a third entity, a second behavior comprising a second task, and a second relationship between the third entity and a relationship entity corresponding to the relationship; (Biernat [0052] A distributed ledger 402 of all these changes is maintained by all entities 406 (or nodes) that participate in the platform. If all entities 406 apply the changes to their own copy of the data then the copies remain consistent across the entities 406 without the need for a single golden copy. Each entity maintains a copy of the ledger 402, which represents a continuous chain of transaction blocks 404, hence the term “blockchain.” When a transaction is performed on the data by one of the entities 406, all entities 406 process the transaction and make a determination regarding the validity of the transaction. [0089] The blockchain systems 1704 can be owned by, or may represent, entities representing different disciplines within the manufacturing, supply, distribution, and/or retail chain, including but not limited to engineering and product development, product manufacturing, product testing, shipping, technical support, business and accounting, etc.[113] to generating private blockchains 1304b that record proprietary manufacturing data generated in connection with the fabrication of the sub-assemblies, blockchain-enabled industrial devices 1102 at the supplier entities 1902 can generate public blockchains 1304a that record information regarding manufacture of the sub-assemblies permitted to be shared with the manufacturing entity 1904. [FIG.13 & 18] show overall flow of system which includes creation/storage of entities and relationship.) and create a third blockchain linked to the first blockchain that records transactions for the second relationship. (Biernat [FIG.13] shows the creation of a plurality of blockchains that are all linked together for corresponding transactions that are being recorded [0091] an MES system can perform the blockchain creation and management functions for multiple monitored devices and systems within the plant. These proxy systems can synchronize blockchains from different sources, certify which chains are trusted, and perform other such blockchain management functions [0097] The OEM's blockchain-enabled industrial devices 1102 can also be configured to generate public blockchains 1304a that record publicly shared transaction data that can be accessed and viewed by other devices that participate in the blockchain ecosystem, including devices associated with the customer manufacturing entity [0119] industrial blockchains can render their associated transaction data available to all entities and devices that make up the blockchain ecosystem. Blockchain-enabled industrial devices 1102 can also support semi-public industrial blockchains that allow transaction data to be shared only with a specified subset of all entities within the industrial blockchain ecosystem (e.g., as in the OEM and sub-assembly supplier examples described above, in which the public blockchains are only made accessible to the relevant OEM or supplier). Similarly, private blockchains 1304b that only share transaction data among devices [FIG.17&18] elaborates on linked blockchains created and maintained)
Regarding claim 21, Biernat and Pad teach The non-transitory computer-readable device of claim 20, the operations further comprising: recording a transaction between the first entity and the second entity in the second blockchain by adding a record block to the second blockchain, the record block comprising a result of the task. The non-transitory computer-readable device of claim 20, the operations further comprising:recording a transaction between the first entity and the second entity in the second blockchain by adding a record block to the second blockchain, the record block comprising a result of the task.
Claims 12,13, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Biernat in view of Pad and US 20230092365 A1; Ricotta; Frank J. et al. (hereinafter Ricotta).
Regarding claim 12, Biernat and Pad teach The system of claim 11, the at least one processor further configured to: Biernat lacks explicitly and orderly teaching generate a graph query to retrieve one or more relationships involving the first entity in the plurality of interlinked blockchains; and run the graph query against the graph database to retrieve a query result. However Ricotta teaches generate a graph query to retrieve one or more relationships involving the first entity in the plurality of interlinked blockchains; and run the graph query against the graph database to retrieve a query result. (Ricotta [0157] Upon receiving input indicative of a query, the graph module 1112 may employ another algorithm to search the corresponding graph database to determine whether a matching...[0166] a graph model, while also supporting querying capabilities that are analytics, direct, or graph based. Normally, the world state is deployed in conjunction with the nodes of the computational architecture. For the nodes, a graph database may be chosen as the storage medium since it allows for transactional and analytical queries in addition to graph queries. Graph databases also represent real-world information more natively to how it really is (and thus are well suited for ML and AI). The graph database may be designed, structured, or otherwise employed to support the creation of graphs as further discussed below.[0206] Another notable benefit of the computational architecture is that modeling “proven” data into graph models allows ML and AI algorithms to gain deeper insights. For example, an algorithm may be able to query across owned and consented data through a single application programming interface (API), even though the data itself may be housed across different nodes or networks, without needing to aggregate and reformat the data. The data that is queried may contain both the data itself and all of the underlying context (e.g., ownership, history, source, verification, relationships). This means that the algorithm (i) can operate more efficiently by running a single query across tens, hundreds, or thousands of nodes or networks, (ii) can operate on real-time data rather than static (and potentially outdated) data, and (iii) can gain additional context that makes the analyses more meaningful. [FIG.11] shows visual) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to take all prior methods and make the addition of Ricotta in order to gain deeper insights on data and efficiently traversing the data in order to create a more enhanced system and output. (Ricotta [0097] In contrast, the approach introduced here for storing data “on chain” with the use of document storage engines produce consistent storage behavior and provide the ability to query data much like a traditional database or datastore. As further discussed below, the data can vary for the “asset” or raw data that a smart data object encompasses. As part of a smart data object, the relationships of that smart data object to other smart data objects can be “fused” within the cryptographically sealed data structure. Efforts were previously made to produce graphs post-persistence in an effort to improve visualization of the underlying data. Conversely, the computational architecture introduced herein can utilize graph theory—and therefore, graph data structures—to persist data in a manner that is more faithful to real-world modeling [0206] Another notable benefit of the computational architecture is that modeling “proven” data into graph models allows ML and AI algorithms to gain deeper insights. For example, an algorithm may be able to query across owned and consented data through a single application programming interface (API), even though the data itself may be housed across different nodes or networks, without needing to aggregate and reformat the data. The data that is queried may contain both the data itself and all of the underlying context (e.g., ownership, history, source, verification, relationships). This means that the algorithm (i) can operate more efficiently by running a single query across tens, hundreds, or thousands of nodes or networks, (ii) can operate on real-time data rather than static (and potentially outdated) data, and (iii) can gain additional context that makes the analyses more meaningful. [FIG.11] shows visual)
Corresponding system claim 19 is rejected similarly as claim 12 above.
Regarding claim 13, Biernat and Pad teach The system of claim 11, Biernat lacks explicitly teaching the at least one processor further configured to: generate a graph query to retrieve one or more transaction locations in the plurality of interlinked blockchains where the first entity participated in a transaction; and run the graph query against the graph database to retrieve a query result. However Ricotta teaches the at least one processor further configured to: generate a graph query to retrieve one or more transaction locations in the plurality of interlinked blockchains where the first entity participated in a transaction; and run the graph query against the graph database to retrieve a query result. (Ricotta [0157] Upon receiving input indicative of a query, the graph module 1112 may employ another algorithm to search the corresponding graph database to determine whether a matching...[0166] a graph model, while also supporting querying capabilities that are analytics, direct, or graph based. Normally, the world state is deployed in conjunction with the nodes of the computational architecture. For the nodes, a graph database may be chosen as the storage medium since it allows for transactional and analytical queries in addition to graph queries. Graph databases also represent real-world information more natively to how it really is (and thus are well suited for ML and AI). The graph database may be designed, structured, or otherwise employed to support the creation of graphs as further discussed below.[0206] Another notable benefit of the computational architecture is that modeling “proven” data into graph models allows ML and AI algorithms to gain deeper insights. For example, an algorithm may be able to query across owned and consented data through a single application programming interface (API), even though the data itself may be housed across different nodes or networks, without needing to aggregate and reformat the data. The data that is queried may contain both the data itself and all of the underlying context (e.g., ownership, history, source, verification, relationships). This means that the algorithm (i) can operate more efficiently by running a single query across tens, hundreds, or thousands of nodes or networks, (ii) can operate on real-time data rather than static (and potentially outdated) data, and (iii) can gain additional context that makes the analyses more meaningful. [FIG.11] shows visual) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to take all prior methods and make the addition of Ricotta in order to gain deeper insights on data and efficiently traversing the data in order to create a more enhanced system and output (Ricotta [0097] In contrast, the approach introduced here for storing data “on chain” with the use of document storage engines produce consistent storage behavior and provide the ability to query data much like a traditional database or datastore. As further discussed below, the data can vary for the “asset” or raw data that a smart data object encompasses. As part of a smart data object, the relationships of that smart data object to other smart data objects can be “fused” within the cryptographically sealed data structure. Efforts were previously made to produce graphs post-persistence in an effort to improve visualization of the underlying data. Conversely, the computational architecture introduced herein can utilize graph theory—and therefore, graph data structures—to persist data in a manner that is more faithful to real-world modeling [0206] Another notable benefit of the computational architecture is that modeling “proven” data into graph models allows ML and AI algorithms to gain deeper insights. For example, an algorithm may be able to query across owned and consented data through a single application programming interface (API), even though the data itself may be housed across different nodes or networks, without needing to aggregate and reformat the data. The data that is queried may contain both the data itself and all of the underlying context (e.g., ownership, history, source, verification, relationships). This means that the algorithm (i) can operate more efficiently by running a single query across tens, hundreds, or thousands of nodes or networks, (ii) can operate on real-time data rather than static (and potentially outdated) data, and (iii) can gain additional context that makes the analyses more meaningful. [FIG.11] shows visual)
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
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 nonprovisional extension fee (37 CFR 1.17(a)) 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARYAN D TOUGHIRY whose telephone number is (571)272-5212. The examiner can normally be reached Monday - Friday, 9 am - 5 pm.
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, Aleksandr Kerzhner can be reached at (571) 270-1760. 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.
/ARYAN D TOUGHIRY/Examiner, Art Unit 2165
/ALEKSANDR KERZHNER/Supervisory Patent Examiner, Art Unit 2165
Prosecution Insights