DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013 is being examined under the AIA first inventor to file provisions.
Status of Claims
The following is a Non-Final Office Action in response to Applicant’s amendments filed on 12/10/2025.
a. Claims 1, 4, 6, 8, 11, 13, 15, 16 are amended
b. Claims 17-20 are new
Overall, Claims 1-20 are pending and have been considered below.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 1-20 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites the limitation “… an industrial supply chain as a service blockchain … submit the transactions to peer nodes a Supply-Chain-as-a-Service (SCaaS) blockchain for validation … issuing a Connection Failed Non-Fungible Token (CF-NFT) to partner peer nodes of the SCaaS blockchain.” Claim 1 recites “industrial supply chain as a service blockchain” and later on claim 1 further recites “Supply-Chain-as-a-Service (SCaaS) blockchain”; and claim 1 recites “peer nodes”, then later claim 1 further recites “partner peer nodes”. In these instances one of skill in the art would be confused if there are two different supply chain as a service blockchain and if there two different peer nodes. For the purpose of compact prosecution, the examiner has considered the recited claim limitation as the same blockchain and same peer nodes.
Claims 8, 16 recites similar limitations to claim 1, and thus are rejected for the same reason as above.
The remainder of the claims are rejected by virtue of dependency.
The reference is provided for the purpose of compact prosecution.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The examiner notes that the previous office action did not reject the claims over the prior art. However, upon further consideration following an updated search, the following rejection is being made.
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 text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
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 non-obviousness.
Claims 1, 8, 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over Chidambaram (US 20200099531 A1), in view of Wei (US 20210326876 A1), in further view of Tran (US 20240388504 A1).
Regarding Claims 1, 8, 16. Chidambaram discloses:
A method, comprising: establishing a Proxy Remote Blockchain Node (PRBP) between a Local Sensor Fusion Blockchain (LSFBC) network and an industrial supply chain as a service blockchain, [see at least Figs. 1-2, 6, (0044) diagram showing physical parties in a supply chain associated with an example use case being registered to the blockchain network and being assigned a digital identity, in accordance with certain example embodiments; (0045) IoT enabled package 106 communicating with the blockchain cloud 104, in accordance with certain example embodiments. (0060) The Internet-of-Things (IoT) may be thought of as being a network of physical devices and items embedded with, or otherwise being connected to, electronics, software, sensors, actuators, and connectivity, which enables these objects to connect to each other and/or external systems and exchange data. A blockchain is a continuously growing list of records, called blocks, that are linked and secured cryptographically. (0065) IoT and blockchain technologies are used to address the authentication, data provenance, trust, security, and/or other technical issues underlying the supply chain management issues associated with the example use case. FIG. 1 is a diagram showing actual, physical parties in a supply chain associated with an example use case being registered to the blockchain network and being assigned a digital identity, in accordance with certain example embodiments. More particularly, in this example use case, the parties include a manufacturing factory 102a, a shipping company 102b, a warehouse storage company 102c, a logistics company 102d, and pharmacies or other shops 102e. (0074) as the goods are transported from the manufacturer with IoT-enabled package, the IoT-enabled package sends sensor data to the blockchain cloud 104 via the blockchain component 506 of the integration server 502. The product is tracked through the various touch points, and the blockchain cloud 104 is updated accordingly]
submit the transactions to peer nodes of a Supply-Chain-as-a-Service (SCaaS) blockchain for validation to participate in a distributed workflow of the SCaaS blockchain; and [see at least (0060) Certain example embodiments described herein relate to techniques for securing and automating process management systems using distributed Internet-of-Things (IoT) sensors and distributed ledgers of digital transactions (e.g., blockchains) relating to the distributed processes being managed. (0065) IoT and blockchain technologies are used to address the authentication, data provenance, trust, security, and/or other technical issues underlying the supply chain management issues associated with the example use case. FIG. 1 is a diagram showing actual, physical parties in a supply chain associated with an example use case being registered to the blockchain network and being assigned a digital identity, in accordance with certain example embodiments. More particularly, in this example use case, the parties include a manufacturing factory 102 a, a shipping company 102 b, a warehouse storage company 102 c, a logistics company 102 d, and pharmacies or other shops 102 e.]
The Chidambaram reference discloses a local blockchain between IoT sensors that communicates with a supply chain blockchain environment, however, Chidambaram does not disclose:
wherein the PRBP is connected to a remote blockchain node of the LSFBC network and
configured to receive transactions from the remote blockchain node and
for the PRBP detecting a connection failure for the remote blockchain node,
issuing a Connection Failed Non-Fungible Token (CF-NFT) to partner peer nodes of the SCaaS blockchain.
Wei discloses:
wherein the PRBP is connected to a remote blockchain node of the LSFBC network and [see at least (0050) when receiving an external data access request initiated by the blockchain node device, the cross-chain proxy server can access a target blockchain network or a remote server, so as to send data to the target blockchain network or the remote server and/or return an access result to the blockchain node device.]
configured to receive transactions from the remote blockchain node and [see at least (0034) The smart network card 21 can also filter received transactions. Specifically, the smart network card 21 can include a storage module 211 and a filtering module 212 shown in FIG. 3.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Chidambaram to include the features of Wei. A person a having the ordinary skill in the art would have been motivated to improve cross-chain access and transaction validation in a distributed blockchain supply-chain system. Yun discloses transaction processing form an industrial asset supply chain. Wei teaches cross-proxy server configure to access a blockchain network. Because both Chidambaram as well as Wei are implemented through field of processing blockchain transaction and both references addresses secure data exchange among blockchain network, it would have been obvious to incorporate Wei’s cross-chain proxy in to Chidambaram’s supply-chain blockchain system to communicate with blockchain networks. Moreover, since the features disclosed by Chidambaram as well as Wei would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Chidambaram/Wei.
The combination of Chidambaram in view of Wei discloses remote proxy blockchain, however, the above combination of Chidambaram, Wei does not disclose:
for the PRBP detecting a connection failure for the remote blockchain node,
issuing a Connection Failed Non-Fungible Token (CF-NFT) to partner peer nodes of the SCaaS blockchain.
Tran discloses:
for the PRBP detecting a connection failure for the remote blockchain node, [see at least (0024) the central server 140 may receive a flag 160 that identifies a failed network zone 120[1] which comprises particular network equipment 152 that have lost network connectivity in a network 100.]
issuing a Connection Failed Non-Fungible Token (CF-NFT) to partner peer nodes of the SCaaS blockchain. [see at least (0026) The central server 140 may generate a first non-fungible token 132 based on the configuration information 162 associated with the particular network equipment 152 in the failed network zone 120[1].]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Chidambaram, Wei to include the features of Tran. A person a having the ordinary skill in the art would have been motivated to improve continuity of blockchain enabled supply chain transaction when network loses connectivity. Chidambaram, Wei discloses blockchain enabled transaction processing. Tran teaches detecting failed network zone. Because both Chidambaram, Wei as well as Tran are implemented through field of blockchain system and both references addresses reliable exchange or recovery of data across distributed network. Moreover, since the features disclosed by Chidambaram, Wei as well as Tran would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Chidambaram, Wei/Tran.
Regarding Claim 17. Chidambaram, Wei, Tran discloses the claim limitations of claim 1. Tran further discloses:
wherein the CF-NFT stores an immutable reference comprising a token identifier, a creation timestamp equivalent to a start time of the connection failure, and a list of attributes at a remote site to be tracked for a total duration of the connection failure. [see at least (0045) the central server 140 may aggregate the first non-fungible token 132, the second non-fungible token 134 and the third non-fungible token 136 to generate a primary non-fungible token 138 associated with the network equipment 152 in the failed network zone 120[1]. These non-fungible tokens are cryptographically unique tokens that are linked to corresponding information associated with the particular network equipment 152 in the failed zone 120[1].
Note: The above combination of Chidambaram, Wei, Tran does not expressly disclose a token identifier, a creation timestamp equivalent to a start time of the connection failure, and a list of attributes at a remote site to be tracked for a total duration of the connection failure. However this limitation represents non-functional descriptive material and does not affect how the claimed method functions (i.e., the descriptive material does not have any claim function in the claimed method; see MPEP 2106.01). A “wherein” clause does not function to actively limit the claim language. Therefore, the claim element is considered, but given no patentable weight. (MPEP 2111.05). The reference is provided for the purpose of compact prosecution.
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Chidambaram, Wei, Tran to include the additional features of Tran. A person a having the ordinary skill in the art would have been motivated to improve continuity of blockchain enabled supply chain transaction when network loses connectivity. Chidambaram, Wei, Tran discloses blockchain enabled transaction processing. Tran further teaches detecting failed network zone. Because both Chidambaram, Wei as well as Tran are implemented through field of blockchain system and both references addresses reliable exchange or recovery of data across distributed network. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claim 18. Chidambaram, Wei, Tran discloses the claim limitations of claim 1. Chidambaram further discloses:
… for submission to the SCaaS blockchain. [see at least (0065) IoT and blockchain technologies are used to address the authentication, data provenance, trust, security, and/or other technical issues underlying the supply chain management issues associated with the example use case. FIG. 1 is a diagram showing actual, physical parties in a supply chain associated with an example use case being registered to the blockchain network and being assigned a digital identity, in accordance with certain example embodiments.]
Wei further discloses:
… the PRBP requesting verification of transactions from peer nodes of the LSFBC network to resolve Byzantine peer issues and Sybil attacks at the LSFBC network, … [see at least (0028) The smart network card 21 is configured to perform transaction consensus with other nodes in a blockchain network to which the blockchain node device belongs, and upload the transaction that passed the consensus to the central processing unit 22. (0032) the smart network card 21 can perform transaction consensus with other nodes in the blockchain network to which the blockchain node device belongs, and upload the transaction that passed the consensus to the central processing unit 22. That is, the function of transaction consensus that was in the central processing unit 22 is offloaded to the smart network card 21. (0063) The blockchain nodes included in the blockchain network in this embodiment can adopt a proof of work (POW) mechanism to perform transaction consensus, or adopt a Practical Byzantine Fault Tolerance (PBFT) mechanism to perform transaction consensus, which is not limited in the present disclosure.]
wherein only transactions verified by more than a threshold of the peer nodes are accepted [see at least (0007) the smart network card is configured to perform transaction consensus with other nodes in a blockchain network to which the blockchain node device belongs, and upload the transaction that passed the consensus to the central processing unit;]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Chidambaram, Wei, Tran to include the additional features of Wei. A person a having the ordinary skill in the art would have been motivated to improve cross-chain access and transaction validation in a distributed blockchain supply-chain system. Yun, Wei, Tran discloses transaction processing form an industrial asset supply chain. Wei further teaches cross-proxy server configure to access a blockchain network. Because both Chidambaram, Wei, Tran as well as Wei are implemented through field of processing blockchain transaction and both references addresses secure data exchange among blockchain network, it would have been obvious to incorporate Wei’s cross-chain proxy in to Chidambaram’s supply-chain blockchain system to communicate with blockchain networks. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Tran further discloses:
for reconnection of the remote blockchain node, [see at least (0026) The central server 140 may generate a first non-fungible token 132 based on the configuration information 162 associated with the particular network equipment 152 in the failed network zone 120[1]. The first non-fungible token 132 may be configured to authenticate or verify authentication of the flag 160 associated with the configuration information 162 and the particular network equipment 152 in the failed network zone 120[1].]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Chidambaram, Wei, Tran to include the additional features of Tran. A person a having the ordinary skill in the art would have been motivated to improve continuity of blockchain enabled supply chain transaction when network loses connectivity. Chidambaram, Wei, Tran discloses blockchain enabled transaction processing. Tran further teaches detecting failed network zone. Because both Chidambaram, Wei as well as Tran are implemented through field of blockchain system and both references addresses reliable exchange or recovery of data across distributed network. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claim 19. Chidambaram, Wei, Tran discloses the claim limitations of claim 1. Wei further discloses:
wherein the PRBP applies a Bloom filter to check for presence of transactions submitted by the remote blockchain node in distributed ledgers of peer nodes of the LSFBC network. [see at least (0034) The smart network card 21 can also filter received transactions. Specifically, the smart network card 21 can include a storage module 211 and a filtering module 212 shown in FIG. 3. The storage module 211 is configured to record a transaction filtering rule; the filtering module 212 is electrically connected to the storage module 211 and is configured to read the transaction filtering rule recorded in the storage module 211, and perform filtering after parsing the received transactions based on the transaction filtering rule, so that the filtered transaction participates in the transaction consensus.]
Note: The above combination of Chidambaram, Wei, Tran does not expressly disclose wherein the PRBP applies a Bloom filter to check for presence of transactions submitted by the remote blockchain node in distributed ledgers of peer nodes of the LSFBC network. However this limitation represents non-functional descriptive material and does not affect how the claimed method functions (i.e., the descriptive material does not have any claim function in the claimed method; see MPEP 2106.01). A “wherein” clause does not function to actively limit the claim language. Therefore, the claim element is considered, but given no patentable weight. (MPEP 2111.05). The reference is provided for the purpose of compact prosecution.
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Chidambaram, Wei, Tran to include the additional features of Wei. A person a having the ordinary skill in the art would have been motivated to improve cross-chain access and transaction validation in a distributed blockchain supply-chain system. Yun, Wei, Tran discloses transaction processing form an industrial asset supply chain. Wei further teaches cross-proxy server configure to access a blockchain network. Because both Chidambaram, Wei, Tran as well as Wei are implemented through field of processing blockchain transaction and both references addresses secure data exchange among blockchain network, it would have been obvious to incorporate Wei’s cross-chain proxy in to Chidambaram’s supply-chain blockchain system to communicate with blockchain networks. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claim 20. Chidambaram, Wei, Tran discloses the claim limitations of claim 1. Wei further discloses:
achieving eventual consistency for sensor fusion transactions from the LSFBC network not under governance by a consortium of the SCaaS blockchain, [see at least (0068) may enable a decentralized verification and corresponding remittance to a supplier based upon the date of receipt of goods or services, the date of assembly, deployment, commissioning, and/or use. This decentralized verification and remittance may then be used to securitize the payment stream of pay-on-use contractual arrangements, enabling an alignment of the physical and information flow of material and services through a supply chain with the corresponding financial flow of that supply chain.]
wherein the LSFBC network continues to operate with a single truth of operations available in a distributed ledger of the LSFBC [see at least (0069) Embodiments may be associated with any type of distributed transaction ledger having a de-centralized consensus-based network that supports smart contracts, digital assets, record repositories, and/or cryptographic security. For example, FIG. 14 is a distributed transaction ledger reference architecture 1400 according to some embodiments. The architecture 1400 includes ledger services and an event stream 1410 that may contain network security service information (e.g., from a supply chain platform).]
wherein transactions generated … are synchronized with the SCaaS blockchain [see at least (0068) Thus, embodiments may enable a decentralized verification and corresponding remittance to a supplier based upon the date of receipt of goods or services, the date of assembly, deployment, commissioning, and/or use. This decentralized verification and remittance may then be used to securitize the payment stream of pay-on-use contractual arrangements, enabling an alignment of the physical and information flow of material and services through a supply chain with the corresponding financial flow of that supply chain.]
Tran further discloses:
… network during the connection failure, and [see at least (0043) At operation 218, the central server 140 may reestablish the network connectivity for at least a portion of the particular network equipment 152 in the failed network zone 120[1] based at least in part upon information associated with the primary non-fungible token 138.]
…during the connection failure … after reconnection. [see at least (0021) reestablish the network connectivity for at least a portion of the particular network equipment 152 in the failed network zone 120[1]. The operation of the disclosed system 100 is described in FIG. 2 below.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Chidambaram, Wei, Tran to include the additional features of Tran. A person a having the ordinary skill in the art would have been motivated to improve continuity of blockchain enabled supply chain transaction when network loses connectivity. Chidambaram, Wei, Tran discloses blockchain enabled transaction processing. Tran further teaches detecting failed network zone. Because both Chidambaram, Wei as well as Tran are implemented through field of blockchain system and both references addresses reliable exchange or recovery of data across distributed network. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Claims 2-7, 9-15 are rejected under 35 U.S.C. 103 as being unpatentable over Chidambaram, in view of Wei, in further view of Tran, as applied to claims [1, 8, 16] above, in further view of Gomez (US 20090222399 A1).
Regarding Claims 2, 9, 15. Chidambaram, Wei, Tran discloses the claim limitations of claims 1, 8. Chidambaram further discloses:
… and a state of verifications to be conducted by the PRBP for transactions submitted by the remote blockchain … [see at least (0094) The IoT data sent in the new protocol standard is more secure, as it has a digital signature. This enables the original message to be verified in the blockchain IoT component 904, for example, e.g., to determine whether there has been any tampering with the data during transit from the IoT device to the cloud or otherwise. (0108) Once the secure IoT data (which is signed and includes the hash value of the original data) reaches the blockchain IoT component 904, the decryption component 1804 thereon begins executing. The signed data is decrypted with the public key, and the IoT data hash and decrypted data is verified to determine whether it is original or has been tampered with. After verification of the IoT data, the blockchain IoT component 904 sends it to the blockchain 920 for the smart contract to start executing on it. The IoT data has the smart contract identifier that needs to be executed and, thus, the blockchain 920 is able to locate and execute the correct smart contract 922. ]
… the PRBP requesting, the state of verifications … … [see at least (0094) The IoT data sent in the new protocol standard is more secure, as it has a digital signature. This enables the original message to be verified in the blockchain IoT component 904, for example, e.g., to determine whether there has been any tampering with the data during transit from the IoT device to the cloud or otherwise. (0108) Once the secure IoT data (which is signed and includes the hash value of the original data) reaches the blockchain IoT component 904, the decryption component 1804 thereon begins executing. The signed data is decrypted with the public key, and the IoT data hash and decrypted data is verified to determine whether it is original or has been tampered with. After verification of the IoT data, the blockchain IoT component 904 sends it to the blockchain 920 for the smart contract to start executing on it. The IoT data has the smart contract identifier that needs to be executed and, thus, the blockchain 920 is able to locate and execute the correct smart contract 922. ]
… submitting, from the PRBP … SCaaS blockchain [see at least (0065) IoT and blockchain technologies are used to address the authentication, data provenance, trust, security, and/or other technical issues underlying the supply chain management issues associated with the example use case. FIG. 1 is a diagram showing actual, physical parties in a supply chain associated with an example use case being registered to the blockchain network and being assigned a digital identity, in accordance with certain example embodiments.]
Wei further discloses:
receiving, from the remote blockchain node, missed events of interests [see at least (0028) The smart network card 21 is configured to perform transaction consensus with other nodes in a blockchain network to which the blockchain node device belongs, and upload the transaction that passed the consensus to the central processing unit 22. (0050) when receiving an external data access request initiated by the blockchain node device, the cross-chain proxy server can access a target blockchain network or a remote server, so as to send data to the target blockchain network or the remote server and/or return an access result to the blockchain node device.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Chidambaram, Wei, Tran to include the additional features of Wei. A person a having the ordinary skill in the art would have been motivated to improve cross-chain access and transaction validation in a distributed blockchain supply-chain system. Yun, Wei, Tran discloses transaction processing form an industrial asset supply chain. Wei further teaches cross-proxy server configure to access a blockchain network. Because both Chidambaram, Wei, Tran as well as Wei are implemented through field of processing blockchain transaction and both references addresses secure data exchange among blockchain network, it would have been obvious to incorporate Wei’s cross-chain proxy in to Chidambaram’s supply-chain blockchain system to communicate with blockchain networks. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Tran further discloses:
wherein the CF-NFT comprises a reference for a disconnect time, a duration of the connection failure, node after the remote blockchain reconnects, [see at least (0031) The center server 140 may reestablish the network connectivity for at least a portion of the particular network equipment 152 based at least in part upon the information associated with the primary non-fungible token 138. The information of the primary non-fungible token 138 may be configured to provide the network connectivity to the particular network equipment 152 and enable the particular network equipment 152 to communicate with the central server 140 and other network equipment in the network 110.]
wherein the method further comprises:… for a reconnection of the remote blockchain node: [see at least (0031) The center server 140 may reestablish the network connectivity for at least a portion of the particular network equipment 152 based at least in part upon the information associated with the primary non-fungible token 138. The information of the primary non-fungible token 138 may be configured to provide the network connectivity to the particular network equipment 152 and enable the particular network equipment 152 to communicate with the central server 140 and other network equipment in the network 110.]
through transmission of the CF- NFT to the peer nodes of LSFBC network as a query; [see at least (0033) FIG. 2 illustrates an example flow of a method 200 for reestablishing network connectivity for particular network equipment in a failed network zone 120[1] in the system 110.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Chidambaram, Wei, Tran to include the additional features of Tran. A person a having the ordinary skill in the art would have been motivated to improve continuity of blockchain enabled supply chain transaction when network loses connectivity. Chidambaram, Wei, Tran discloses blockchain enabled transaction processing. Tran further teaches detecting failed network zone. Because both Chidambaram, Wei as well as Tran are implemented through field of blockchain system and both references addresses reliable exchange or recovery of data across distributed network. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
The combination of Chidambaram in view of Wei in further view Tran discloses supply chain, however, the above combination of Chidambaram, Wei, Tran does not disclose:
… and a local trust level at LSFBC to the PRBP;
… associated with each of the missed events of interest from peer nodes of the LSFBC network …and
for the state of verifications of the each of the missed events of interest from the peer nodes meeting a threshold for acceptance, … the each of the missed events of interest to the meeting the threshold of acceptance.
wherein the PRBP applies a Bloom filter to check for presence of the missed events of interest in distributed ledgers of the peer nodes of the LSFBC network.
However, Gomez discloses:
… and a local trust level at LSFBC to the PRBP; [see at least (0009) evaluating the aggregation trust value (AgTV) for sensor data aggregated from the at least one piece of sensor data by means of an operator φ⊕ depending on said at least one trust value φ (Ps i ,e) and at least one corresponding weighting value αi.]
… associated with each of the missed events of interest from peer nodes of the LSFBC network …and [see at least (0047) At middleware level, (sensor data) aggregation may provide software applications with a single collection of sensor data of interest for the software applications. In other words, sensor data aggregation may be an automated collection of sensor data without any modification or inference on the data.]
for the state of verifications of the each of the missed events of interest from the peer nodes meeting a threshold for acceptance, … the each of the missed events of interest to the meeting the threshold of acceptance. [see at least (0047) At middleware level, (sensor data) aggregation may provide software applications with a single collection of sensor data of interest for the software applications. In other words, sensor data aggregation may be an automated collection of sensor data without any modification or inference on the data.]
wherein the PRBP applies a Bloom filter to check for presence of the missed events of interest in distributed ledgers of the peer nodes of the LSFBC network. [see at least (0047) At middleware level, (sensor data) aggregation may provide software applications with a single collection of sensor data of interest for the software applications. In other words, sensor data aggregation may be an automated collection of sensor data without any modification or inference on the data.]
Note: The above combination of Chidambaram, Wei, Tran, Gomez does not expressly disclose wherein the PRBP applies a Bloom filter to check for presence of the missed events of interest in distributed ledgers of the peer nodes of the LSFBC network. However this limitation represents non-functional descriptive material and does not affect how the claimed method functions (i.e., the descriptive material does not have any claim function in the claimed method; see MPEP 2106.01). A “wherein” clause does not function to actively limit the claim language. Therefore, the claim element is considered, but given no patentable weight. (MPEP 2111.05). The reference is provided for the purpose of compact prosecution.
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Chidambaram, Wei, Tran to include the features of Gomez. A person a having the ordinary skill in the art would have been motivated to improve reliability of sensor derived transaction data. Chidambaram, Wei, Tran discloses processing blockchain based transaction. Gomez teaches evaluating trustworthiness of sensor data. Because both Chidambaram, Wei, Tran as well as Gomez are implemented through field of secure data processing and both references addresses improving the reliability of data. Moreover, since the features disclosed by Chidambaram, Wei, Tran as well as Gomez would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Chidambaram, Wei, Tran/Gomez.
Regarding Claims 3, 10. Chidambaram, Wei, Tran, Gomez discloses the claim limitations of claims 2, 9. Chidambaram further discloses:
wherein the remote blockchain continues to operate with single truth of its operations available in the LSFBC network during the connection failure with the PRBP [see at least (0065) IoT and blockchain technologies are used to address the authentication, data provenance, trust, security, and/or other technical issues underlying the supply chain management issues associated with the example use case. FIG. 1 is a diagram showing actual, physical parties in a supply chain associated with an example use case being registered to the blockchain network and being assigned a digital identity, in accordance with certain example embodiments.]
Tran further discloses:
wherein for a reconnection of the remote blockchain node, [see at least (0012) a system 100 that is configured to reestablish network connectivity for particular network equipment in a failed network zone 120[1] in a network 110]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Chidambaram, Wei, Tran, Gomez to include the additional features of Tran. A person a having the ordinary skill in the art would have been motivated to improve continuity of blockchain enabled supply chain transaction when network loses connectivity. Chidambaram, Wei, Tran, Gomez discloses blockchain enabled transaction processing. Tran further teaches detecting failed network zone. Because both Chidambaram, Wei, Gomez as well as Tran are implemented through field of blockchain system and both references addresses reliable exchange or recovery of data across distributed network. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Gomez further discloses:
the remote blockchain node sends missed batches of events of interest (EoI) and local trust level (LTL) to the PRBP. [see at least (0007) Thus, trustworthiness of sensor data acquired from a sensor node may be based on the trustworthiness of their sensor data attributes, wherein also an impact of sensor data attribute confidence or trust may be captured.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Chidambaram, Wei, Tran, Gomez to include the additional features of Gomez. A person a having the ordinary skill in the art would have been motivated to improve reliability of sensor derived transaction data. Chidambaram, Wei, Tran, Gomez discloses processing blockchain based transaction. Gomez teaches evaluating trustworthiness of sensor data. Because both Chidambaram, Wei, Tran, Gomez as well as Gomez are implemented through field of secure data processing and both references addresses improving the reliability of data. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claims 4, 11. Chidambaram, Wei, Tran discloses the claim limitations of claims 1, 8. Chidambaram further discloses:
… associated with the LSFBC network, … [(0069) n accordance with the smart contract 302, packages are transported with IoT-enabled edge devices, which include temperature sensors, as described in connection with FIG. 2. Each IoT-enabled edge device at least temporarily stores temperature readings and sends values to the blockchain cloud 104 (e.g., at predetermined intervals or times, whenever the network is available, etc.).]
… as Proof-of-Trust from a distributed ledger of the LSFBC network, … [(0114) Moreover, breaches may not be detected and intercepted in a timely manner. In addition, it is relatively straightforward to tamper with the temperature readings, given the number of manual processes involved. By contrast, with the new, secure and automated BPMS process, data from the IoT devices is maintained in the blockchain, which is immutable and can be authenticated. Thus, the data can be deemed trustworthy and accurate throughout the process, and proof of “who did what, when” can be provided in this trustable manner. There is no need for manual triggers of BPMS processes in at least some instances, as the IOT blockchain components are automatically triggered when there is a breach.]
… the distributed ledger comprising configurations and device trust data of peer nodes, … [see at least (0061) The breach event may in turn cause a return order BPMS process request or the like to be automatically started, along with other appropriate actions (e.g., notification to the other parties to the smart contract, penalty payment BPMS processing, etc.). The transactions are stored in immutable blockchain ledger, so parties trying to update the reported values will fail, thus creating security and trust among and between the parties. (0110) The mining node broadcasts the new block to peer nodes, as shown in FIG. 19. The new block will be validated and verified, and its transaction will be executed locally by peer nodes to be become an official block in their local blockchains. FIG. 20 shows the blocks being added.
The combination of Chidambaram in view of Wei in further view Tran discloses supply chain, however, the above combination of Chidambaram, Wei, Tran does not disclose:
executing a sensor fusion trust modelling at an aggregator and edge network (AEN)
the sensor fusion trust modelling configured to build a local trust level (LTL)
for sensor fusion data received from sensors associated with the LSFBC and
provide the LTL and events of interest to the remote blockchain node;
Gomez discloses:
executing a sensor fusion trust modelling at an aggregator and edge network (AEN) [see at least (0032) a trust model may be determined for sensor data processing in a sensor data life-cycle by computing appropriate trust values each of the participating entities has in the sensor data at or during a specific processing step of the life-cycle]
the sensor fusion trust modelling configured to build a local trust level (LTL) [see at least (0032) a trust model may be determined for sensor data processing in a sensor data life-cycle by computing appropriate trust values each of the participating entities has in the sensor data at or during a specific processing step of the life-cycle]
for sensor fusion data received from sensors associated with the LSFBC and [see at least (0010) evaluation a fusion trust value (FTV) may further include determining at least one trust value φ (Ps i ,e) of at least one piece of sensor data, and evaluating the fusion trust value (FTV) for sensor data fused from the at least one piece of sensor data using an operator depending on said at least one trust value φ (Ps i ,e) and at least one corresponding weighting value αi]
provide the LTL and events of interest to the remote blockchain node; [see at least (0010) evaluation a fusion trust value (FTV) may further include determining at least one trust value φ (Ps i ,e) of at least one piece of sensor data, and evaluating the fusion trust value (FTV) for sensor data fused from the at least one piece of sensor data using an operator depending on said at least one trust value φ (Ps i ,e) and at least one corresponding weighting value αi]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Chidambaram, Wei, Tran to include the features of Gomez. A person a having the ordinary skill in the art would have been motivated to improve reliability of sensor derived transaction data. Chidambaram, Wei, Tran discloses processing blockchain based transaction. Gomez teaches evaluating trustworthiness of sensor data. Because both Chidambaram, Wei, Tran as well as Gomez are implemented through field of secure data processing and both references addresses improving the reliability of data. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claims 5, 12. Chidambaram, Wei, Tran, Gomez discloses the claim limitations of claims 4, 11. Chidambaram further discloses:
for a local consensus occurring with the peer nodes of the LSFBC network, the remote blockchain nodes submits the output transactions to the PRBP. [(0077) Each party of a business process executed by a BPMS can be part of the consensus and, as a result, each party should have a copy each transaction. In this example use case, each of parties 102a-102e will have transactions listing temperature, transit, and other related details. If a party tries to update an existing transaction, the attempted modification would be identified by other mining nodes. The doctored transaction in some instances would be overwritten with the original value, thus maintaining the immutable digital ledger of the transportation events during the journey of the package 106. This approach creates the trust between the parties that agreed to the smart contract.]
Gomez further discloses:
wherein the sensor fusion trust modelling of the AEN are configured to generate output transactions comprising event of interest (EoI) to be submitted to peer nodes of the LSFBC network, and [see at least (0032) a trust model may be determined for sensor data processing in a sensor data life-cycle by computing appropriate trust values each of the participating entities has in the sensor data at or during a specific processing step of the life-cycle]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Chidambaram, Wei, Tran, Gomez to include the additional features of Gomez. A person a having the ordinary skill in the art would have been motivated to improve reliability of sensor derived transaction data. Chidambaram, Wei, Tran, Gomez discloses processing blockchain based transaction. Gomez teaches evaluating trustworthiness of sensor data. Because both Chidambaram, Wei, Tran, Gomez as well as Gomez are implemented through field of secure data processing and both references addresses improving the reliability of data. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claims 6, 13. Chidambaram, Wei, Tran discloses the claim limitations of claims 1, 8. Chidambaram further discloses:
… receiving, from the remote blockchain node, events of interest … [(0102) The blockchain IoT component 904 receives the IoT data, and it triggers its related smart contract in blockchain 920. In this example, the first device group 1002′ calls the first smart contract 1 922a, and the second device group calls the third smart contract 922c.
submitting the events of interest to the peer nodes of SCaaS blockchain for the trust in the remote blockchain being established. [(0065) IoT and blockchain technologies are used to address the authentication, data provenance, trust, security, and/or other technical issues underlying the supply chain management issues associated with the example use case. FIG. 1 is a diagram showing actual, physical parties in a supply chain associated with an example use case being registered to the blockchain network and being assigned a digital identity, in accordance with certain example embodiments. More particularly, in this example use case, the parties include a manufacturing factory 102a, a shipping company 102b, a warehouse storage company 102c, a logistics company 102d, and pharmacies or other shops 102e.]
Wei further discloses:
for the PRBP being established and connected to the remote blockchain node: [see at least (0050) when receiving an external data access request initiated by the blockchain node device, the cross-chain proxy server can access a target blockchain network or a remote server, so as to send data to the target blockchain network or the remote server and/or return an access result to the blockchain node device]
by the PRBP by requesting presence of the events of interest from peer nodes of the LSFBC network and receiving confirmation from more than a threshold of the peer nodes of the LSFBC network; and [see at least (0063) The blockchain nodes included in the blockchain network in this embodiment can adopt a proof of work (POW) mechanism to perform transaction consensus, or adopt a Practical Byzantine Fault Tolerance (PBFT) mechanism to perform transaction consensus, which is not limited in the present disclosure.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Chidambaram, Wei, Tran to include the additional features of Wei. A person a having the ordinary skill in the art would have been motivated to improve cross-chain access and transaction validation in a distributed blockchain supply-chain system. Yun, Wei, Tran discloses transaction processing form an industrial asset supply chain. Wei further teaches cross-proxy server configure to access a blockchain network. Because both Chidambaram, Wei, Tran as well as Wei are implemented through field of processing blockchain transaction and both references addresses secure data exchange among blockchain network, it would have been obvious to incorporate Wei’s cross-chain proxy in to Chidambaram’s supply-chain blockchain system to communicate with blockchain networks. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
The combination of Chidambaram in view of Wei in further view Tran discloses supply chain, however, the above combination of Chidambaram, Wei, Tran does not disclose:
…and a local trust level at LSFBC;
… establishing trust in the remote blockchain node …
Gomez discloses:
…and a local trust level at LSFBC; [see at least (0007) evaluating an acquisition trust value (ATV) may further include determining at least one trust value φ (Pa i ,e) of at least one sensor data attribute of the sensor data acquired from the at least one sensor node, and evaluating the acquisition trust value (ATV) of the sensor data by means of an operator φacqu depending on said at least one trust value φ (Pa i ,e) and at least one corresponding weighting value αi.]
… establishing trust in the remote blockchain node … [see at least (0007) evaluating an acquisition trust value (ATV) may further include determining at least one trust value φ (Pa i ,e) of at least one sensor data attribute of the sensor data acquired from the at least one sensor node, and evaluating the acquisition trust value (ATV) of the sensor data by means of an operator φacqu depending on said at least one trust value φ (Pa i ,e) and at least one corresponding weighting value αi.]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Chidambaram, Wei, Tran to include the features of Gomez. A person a having the ordinary skill in the art would have been motivated to improve reliability of sensor derived transaction data. Chidambaram, Wei, Tran discloses processing blockchain based transaction. Gomez teaches evaluating trustworthiness of sensor data. Because both Chidambaram, Wei, Tran as well as Gomez are implemented through field of secure data processing and both references addresses improving the reliability of data. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claim 7. Chidambaram, Wei, Tran, Gomez discloses the claim limitations of claim 6. Gomez further discloses:
Wherein for a local trust level of the LSFBC falls below a threshold, refusing events of interest from the LSFBC for a period of time. [see at least (0031) Trust or trustworthiness in such a sensor data life-cycle may be then evaluated (assessed, determined or computed) by computing corresponding trust values in each of the processing steps of the sensor data life-cycle. The corresponding trust value (i.e. ATV, DTV, PTV) may then express or specify an expectation probability of a corresponding entity that the sensor data is true (and thus trustworthy enough to be used).]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Chidambaram, Wei, Tran, Gomez to include the additional features of Gomez. A person a having the ordinary skill in the art would have been motivated to improve reliability of sensor derived transaction data. Chidambaram, Wei, Tran, Gomez discloses processing blockchain based transaction. Gomez teaches evaluating trustworthiness of sensor data. Because both Chidambaram, Wei, Tran, Gomez as well as Gomez are implemented through field of secure data processing and both references addresses improving the reliability of data. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Regarding Claim 14. Chidambaram, Wei, Tran, discloses the claim limitations of claim 8. The combination of Chidambaram in view of Wei in further view Tran discloses supply chain, however, the above combination of Chidambaram, Wei, Tran does not disclose:
wherein for a local trust level of the LSFBC falls below a threshold, refusing events of interest from the LSFBC for a period of time.
Nonetheless, Gomez discloses:
wherein for a local trust level of the LSFBC falls below a threshold, refusing events of interest from the LSFBC for a period of time. [see at least (0031) Trust or trustworthiness in such a sensor data life-cycle may be then evaluated (assessed, determined or computed) by computing corresponding trust values in each of the processing steps of the sensor data life-cycle. The corresponding trust value (i.e. ATV, DTV, PTV) may then express or specify an expectation probability of a corresponding entity that the sensor data is true (and thus trustworthy enough to be used).]
In addition, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the features of Chidambaram, Wei, Tran to include the features of Gomez. A person a having the ordinary skill in the art would have been motivated to improve reliability of sensor derived transaction data. Chidambaram, Wei, Tran discloses processing blockchain based transaction. Gomez teaches evaluating trustworthiness of sensor data. Because both Chidambaram, Wei, Tran as well as Gomez are implemented through field of secure data processing and both references addresses improving the reliability of data. Moreover, since the subject matter is merely a combination of old features, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art before the effective filing date would have recognized that the results of the combination were predictable.
Response to Amendments/Arguments
With respect to Applicant’s Remarks as to the claim rejection.
Applicant submits: “The Office Action objects to claim 15 because of certain informalities. Applicant has amended the claims in a manner believed fully responsive to the Examiner's objection. Therefore, Applicant respectfully requests the Examiner to reconsider and withdraw this objection.”
Examiner response: Notwithstanding applicant’s remarks, the objection has been reconsidered in view of the amendments, and has been withdrawn.
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 112(a).
Applicant submits: “The Examiner has alleged that claims 1-16 are rejected under 35 U.S.C. § 112(a) as failing to comply with the written description requirement. Specifically, the Examiner asserts that claims 1, 8, 16 are rejected for reciting "network and configured to participate in a ..." without specifying what "participate" means, claims 4, 11 are rejected for reciting "configured to compute a local trust level" without specifying how to compute the trust level, and claims 6, 16 are rejected for reciting "establishing trust in the remote" without specifying what "establishing a trust" means. Office Action, pages 11-12.” Examiner response: After further consideration, the 112(a) claim rejection has been withdrawn.
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 101.
Applicant submits: “The Examiner has alleged that "Claims 1-16 are rejected under 35 USC 101 because the claimed invention is not directed to patent eligible subject matter. The claimed matter is directed to a judicial exception, i.e. an abstract idea, not integrated into a practical application, and without significantly more." Office Action, page 3. However, this rejection is respectfully traversed. The amended claims are directed to patent-eligible subject matter as they recite specific technological improvements to blockchain networks that solve concrete technical problems in distributed systems, as stated below.”
Examiner: Notwithstanding applicant’s remarks, the rejection has been reconsidered in view of the amendments, and has been withdrawn.
Relevant Prior Art Not Relied Upon
The prior art made of record and not relied upon which, however, is considered pertinent to applicant's disclosure:
US 20190347656 A1 Lu; Xuming et al. BLOCKCHAIN MEMBER MANAGEMENT DATA PROCESSING METHODS, APPARATUSES, SERVERS, AND SYSTEMS - A blockchain technology (BT), also referred to as a distributed ledger technology, is an Internet database technology. The blockchain technology features decentralization, openness, transparency, tamper-resistance of data, etc. Currently, the blockchain technology has been applied to various fields in economy and society, for example, financial services, supply chain management, culture and entertainment, real estate, medical care, and electronic commerce, in addition to digital currencies. A plurality of users or user groups in a blockchain can create a consortium blockchain based on the features of the blockchain technology, to satisfy service development demands of these users or groups. For example, a consortium blockchain is created and includes four blockchain nodes: payment application A, medical service B, movie ticket application C, and taxi hailing application D. In the consortium blockchain, a plurality of preselected nodes in the blockchain are usually designated as ledger nodes for members in a specific group and the limited number of third parties, and generation of each block can be determined by the preselected nodes. These preselected nodes can be generated through voting by using a consensus mechanism. The consensus mechanism can include a mechanism that all blockchain nodes reach an agreement on block information, to ensure that the latest block is accurately added to the blockchain, and blockchain information stored in the nodes is consistent. Current mainstream consensus methods mainly include proof of work, proof of stake, a combination of proof of work and proof of stake, delegated proof of stake, a ripple consensus protocol, etc.
US 20240249275 A1 Basu; Saswata et al. GROUP SIGNATURES FOR A SMART WALLET ON A BLOCKCHAIN PLATFORM - [0022] By design, a blockchain is resistant to modification of its data. This is because once recorded, the data in any given block cannot be altered retroactively without alteration of all subsequent blocks. For use as a distributed ledger, a blockchain is typically managed by a peer-to-peer network collectively adhering to a protocol for inter-node communication and validating new blocks. Although blockchain records are not unalterable, blockchains may be considered secure by design and exemplify a distributed computing system with high Byzantine fault tolerance. A Byzantine fault is a condition of a computer system, particularly distributed computing systems, where components may fail and there is imperfect information on whether a component has failed. The blockchain has been described as “an open, distributed ledger that can record transactions between two parties efficiently and in a verifiable and permanent way.”
US 20200267543 A1 Byers; Charles Calvin et al. SENSOR FUSION FOR TRUSTWORTHY DEVICE IDENTIFICATION AND MONITORING - Presented herein are methodologies to on-board and monitor Internet of Things (IoT) devices on a network. The methodology includes receiving at a server, from a plurality of IoT devices communicating over a network, data representative of external environmental factors being experienced by individual ones of the plurality of IoT devices at a predetermined location; generating, using machine learning, an aggregated model of the external environmental factors at the predetermined location; receiving, at the server, a communication indicative that a new IoT device seeks to join the network at the predetermined location; receiving, from the new IoT device, data representative of external environmental factors being experienced by the new IoT device; determining whether there is a discrepancy between the external environmental factors of the new IoT device and the aggregated model; and when there is such a discrepancy, prohibiting the new IoT device from joining the network.
US 20210150477 A1 Shrinivasan; Yedendra et al. AUTOMATED CONFLICT RESOLUTION - An example operation may include one or more of setting, by a first node, a cut-off time for a resolution of an update to a service contract received from at least one node of a plurality of second nodes over a blockchain, acquiring, by the first node, resolution parameters from a blockchain ledger, and executing a smart contract to resolve the service contract based on the update to the service contract and the resolution parameters.
US 20210314396 A1 Basu; Saswata et al. STREAMING CONTENT VIA BLOCKCHAIN TECHNOLOGY - An approach is disclosed for streaming content to a client. A request is received to receive content suitable for access by a streaming application. The content is separated into chunks C (C1, C2, . . . , Cn). The chunks are uploaded to corresponding blobbers B (B1, B2, . . . , Bn). A first pipe is utilized by the blobbers B (B1, B2, . . . , Bn) to download the chunks C (C1, C2, . . . , Cn) into a buffer. A second pipe is utilized to convert the downloaded chunks C (C1, C2, . . . , Cn) from the buffer into a byte array A (A1, A2, . . . , An) and the byte array A (A1, A2, . . . , An) is sent to a plurality of streaming services.
US 11488099 B2 Koc; Ali et al. Supply-chain simulation - An example operation may include one or more of collecting, by a first node, a plurality of permissioned data inputs from a plurality of second nodes of a supply-chain, performing, by the first node, a granular simulation based on the permissioned data inputs to generate a plurality of key performance indicators (KPIs), and executing a smart contract to adjust order processes of the supply-chain based on the KPIs.
US 10817872 B2 Lin; Li Event processing method, apparatus and electronic device based on blockchain technology - One or more embodiments of the specification provide a method, apparatus, and non-transitory computer-readable storage medium for processing an event involving a plurality of users in a blockchain. The method is implementable by any user involved in the event, the method comprising: generating, by a computing device associated with a user of the event, descriptive information of the event; submitting the descriptive information to the blockchain, so that the descriptive information is synchronized to a computing device associated with another user of the event for the another user to verify the descriptive information and submit triggering information corresponding to the event to the blockchain after verifying the descriptive information; and submitting, by the computing device associated with the user, triggering information associated with the user corresponding to the event to the blockchain for the blockchain to process the event according to the descriptive information after verifying all triggering information submitted by the plurality of users.
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 MD S HYDER whose telephone number is (571)270-1820. The examiner can normally be reached Monday - Friday 8:30am - 6:00pm.
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, Patrick McAtee can be reached at (571) 272-7575. 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.
/M.S.H./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights