DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 9/24/2025 has been entered.
Response to Arguments
Applicant's arguments filed 9/24/2025 have been fully considered
35 USC § 102 & 35 USC § 103:
Regarding Applicant’s Argument (pages: 7-11): Examiner’s response:- In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). The examiner points to primary prior art Biernat to teach new amendment "via a linking block located on the first blockchain, wherein the second blockchain" (see Biernat paragraph 53, 121-123, and corresponding new claim mapping below). The examiner points to secondary prior art Gnan to teach additional new amendment of "the enforcement mechanism being located at a location in the first blockchain" (See Gnan paragraph 402,408, FIG. 23-24 and corresponding new claim mapping below). It is important to note that under Broadest reasonable interpretation (BRI) the cryptographic hashing in paragraph 402 and smart contract implementation in paragraph 408 are forms of “enforcement mechanisms” as per the instant applications specification paragraph 34 “an enforcement mechanism (e.g., smart contract, an append-only structure, a blockchain transaction, a journaling protocol, a cryptographic assurance, a non-volatile protocol, a circuit-controlled protocol, function, procedure, etc.)”. Henceforth the new claim limitations are rendered obvious over Biernat in view of Gnan.
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) in view of US 20230360779 A1; GNANASAMBANDAM; NATHAN et al. (hereinafter Gnan)
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 create a second blockchain linked 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.) … the second blockchain 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 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 governance information However Gnan teaches the enforcement mechanism being located at a location in the first blockchain (Gnan [0402] a cryptographic hash value (e.g., a hashed address) that serves as a pointer to a memory location at which the particular information is to be stored in the distributed file system. The cryptographic hash value may be stored in the blockchain as part of the record indicating that the care plan of the medical professional has been stored. By using the distributed file system for data storage, the network of nodes improves in scalability, conserves processing and/or network resources by being able to perform faster queries, conserves memory resources that might otherwise be used to attempt to store data on the blockchain, and/or the like. [0408] The information input to the smart contract may include credential information of the other user, the blockchain identifier associated with the medical professional, another type of identifier of the medical professional, payment information, and/or the like. In some embodiments, the payment information may include cryptocurrency of the other user, approval to deduct cryptocurrency from an account of the other user, an identifier for a virtual wallet used to store the other user's cryptocurrency, and/or the like. [FIG.23,24, and FIG.33E] show the enforcement mechanisms being located in specific locations in the DLS/blockchain system)
and wherein the first entity, the second entity, the behavior, the relationship, and the enforcement mechanism collectively represent governance information (Gnan [0048] techniques for managing content (e.g., evidence-based guideline, knowledge representations, clinical studies, clinical processes, clinical techniques, care plans, etc.) using a blockchain. A blockchain may refer to an immutable ledger for storing records of transactions. [0049] The cognitive intelligence platform integrates and consolidates data/information from various sources and entities and provides a population health management service. In some embodiments, at least some of the data/information from the various sources and entities may be stored in the blockchain. The blockchain may be maintained by a distributed network of nodes. In some embodiments, a consensus protocol may be used by the nodes to determine whether to allow transactions to be performed and groups the transactions into records that are stored as blocks of the blockchain. [0055] A medical personnel entity may use the application to store documents on the distributed ledger. For example, a medical personnel entity may use the application to submit a transaction request to perform an operation on the distributed ledger. The operation may include storing content (e.g., knowledge representation, care plan, etc.) on the distributed ledger. One or more rules of the distributed ledger may be executed prior to allowing the operation to be performed. The rules may be logic implemented in computer instructions of a rules engine, a smart contract, and/or the like. One of the rules may determine whether the medical personnel entity that submitted the transaction request is associated with valid authorization information (e.g., medical degree, medical license number). Another rule may determine whether the content includes any portions that are new relative to other content stored on the distributed ledger. For example, the rule may prevent duplicated knowledge from being added to the distributed ledger. That is, at least a portion of the content being added may be required to be new and unique and not disclosed by other content on the distributed ledger.[0443] determining, using an incentives function of a smart contract and information included in the transaction request, whether a quantity of electronic currency associated with a user that caused the transaction request to be submitted satisfies a threshold quantity of electronic currency needed to perform the one or more operations, and [0444] determining whether to allow the one or more operations to be performed based on determining whether the quantity of electronic currency associated with the user satisfies the threshold quantity of electronic currency. [64-67 & 335-339] elaborate on the matter [FIG.23] shows a corresponding visual of wherein the first entity, the second entity, the behavior, the relationship, and the enforcement mechanism collectively represent governance information) 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 Gnan's block chaining methods in order to create a more efficient system (Gnan [0051] The distributed ledger may provide a verifiable trace of proof that the content stored on the distributed ledger is associated with entities having authorized credentials (e.g., medical license) to facilitate more efficient verification of the information, among other things. The distributed ledger may provide a secure chain of record that is used to enhance the efficiency and/or security of the knowledge management process in the healthcare ecosystem. An objective process of administering and managing clinical knowledge can be achieved using the distributed ledger in disclosed embodiments. A user's experience using a computer may be improved using the disclosed embodiments by verifying the source of content in a secure manner, such that the user is confident that the content is trustworthy because it was written by a medical personnel entity having valid authorization information, has been recently updated by a medical personnel entity having valid authorization information, and/or was vetted by other medical personnel entities having valid authorization information. Further, network, processor, and/or memory resources may be reduced using the disclosed techniques by the distributed ledger returning ranked content that is (i) written by a medical personnel entity having a stellar reputation, (ii) viewed by a threshold number of medical personnel entities, and/or (iii) verified as being valid by a threshold number of medical personnel entities because the user may select content initially presented based on one or more of these factors without performing additional searches.[0055] A medical personnel entity may use the application to store documents on the distributed ledger. For example, a medical personnel entity may use the application to submit a transaction request to perform an operation on the distributed ledger. The operation may include storing content (e.g., knowledge representation, care plan, etc.) on the distributed ledger. One or more rules of the distributed ledger may be executed prior to allowing the operation to be performed. The rules may be logic implemented in computer instructions of a rule’s engine, a smart contract, and/or the like. One of the rules may determine whether the medical personnel entity that submitted the transaction request is associated with valid authorization information (e.g., medical degree, medical license number). Another rule may determine whether the content includes any portions that are new relative to other content stored on the distributed ledger. For example, the rule may prevent duplicated knowledge from being added to the distributed ledger. That is, at least a portion of the content being added may be required to be new and unique and not disclosed by other content on the distributed ledger. FIG.23] shows a corresponding visual of wherein the first entity, the second entity, the behavior, the relationship, and the enforcement mechanism collectively represent governance information)
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 Gnan 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 Gnan 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. (Gnan [0311] In some embodiments, the transactions relating to registering an entity may store identifying information pertaining to an entity, such as an identity, address, social security number, driver's license number, and/or the like. Records 2408 of these transactions may store authorization information, such as license numbers (NPIs) for physicians, license numbers for pharmacists, license numbers for pharmacies to dispense medicine, and/or the like.[0372] FIG. 33A illustrates a registration procedure that allows the medical professional to register for access to the distributed ledger. In some embodiments, and as shown by reference number 3302, the medical professional may interact with an interface of user device 104-1 to register for access to the distributed ledger. For example, the medical professional may input certain credential information that may be used to authorize and/or authenticate transactions.[0402] To use the distributed file system to store particular information (e.g., care plan information, credential information, and/or the like), the cognitive intelligence platform 102 may use a content addressing technique (or a similar type of hash technique) to process information included in the transaction request, which may generate a cryptographic hash value (e.g., a hashed address) that serves as a pointer to a memory location at which the particular information is to be stored in the distributed file system. The cryptographic hash value may be stored in the blockchain as part of the record indicating that the care plan of the medical professional has been stored. By using the distributed file system for data storage, the network of nodes improves in scalability, conserves processing and/or network resources by being able to perform faster queries, conserves memory resources that might otherwise be used to attempt to store data on the blockchain, and/or the like. [415-421] 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.33A-E] shows the corresponding visual)
Regarding claim 5, Biernat and Gnan 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 Gnan 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 Gnan 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 Gnan 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 Gnan 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 Gnan 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 Gnan 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 Gnan 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 Gnan 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 Gnan 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. (Gnan [378] the cognitive intelligence platform 102 may generate and add a record of the transaction to the distributed ledger. For example, the cognitive intelligence platform 102 may generate a record indicating that the medical professional has been granted access to the distributed ledger and may add the record to the distributed ledger. The cognitive intelligence platform 102 may add the record by storing the record as a block in a blockchain associated with the medical professional. [396] the cognitive intelligence platform may generate and add a record of the transaction to the distributed ledger. For example, the cognitive intelligence platform 102 may add, to the distributed ledger, a record that includes transaction type information indicating the type of transaction request that was made, time information indicating a time during which the transaction request was made and/or granted, the care plan information, and/or the like. The cognitive intelligence platform 102 may add the record to the distributed ledger by storing the record as a block in the blockchain (e.g., as a second block in the blockchain). The second block may be cryptographically linked to the first block in a manner described elsewhere herein. [430-434 &308-315] elaborate on 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 [FIG.33A-E] shows the corresponding visual)
Claims 12,13, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Biernat in view of US 20230092365 A1; Ricotta; Frank J. et al. (hereinafter Ricotta).
Regarding claim 12, Biernat and Gnan 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 Gnan 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
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