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 .
Status of Claims
This action is in reply to the amendment filed 12/08/2025.
Claims 1, 11, and 20 have been amended. Claims 1-20 are pending and have been examined on the merits (claims 1, 11, and 20 being independent).
The amendment filed 12/08/2025 to the claims has been entered.
Response to Arguments
Applicant’s arguments and amendments filed 12/08/2025 have been fully considered.
With regard to the rejections of claims 1-20 under 35 U.S.C. 103, Applicant’s arguments and amendments have been considered but are not persuasive and Examiner respectfully disagrees. Examiner notes that Applicant is arguing newly amended claim language. In consideration of Applicant’s arguments and amendments of independent claims 1, 11, and 20, clarifying citations with regard the Saket in view of Panikkar references have been made to the 35 USC § 103 rejection above (see Panikkar [0005], [0040], and [0069]). Applicant seems to be interpreting the claim language more narrowly/specifically than what is recited. As such, Applicant’s arguments are not persuasive.
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 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 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.
In the rejections below, where claims are currently amended, this is indicated by underlining.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Saket et al. (hereinafter Saket), US Patent Number 11,769,156 B2 in view of Panikkar et al. (hereinafter Panikkar), US Publication Number 2023/0012566 A1.
Regarding claim 1:
Saket discloses the following:
A computer-implemented method comprising: (Saket: See column 1, line 65 through column 2, line 6)
providing (reads on “A channel is a set of blockchain peers which share a distributed ledger corresponding to the channel and which is accessible to only its peers.”) a first channel in a private network between a first system and a second system; (Saket: See column 5, lines 15-20)
receiving (reads on “separate smart contract corresponding to separate channels and certain subsets of the fields of the data record 'R', are created and shared with a set of data consumers”) a first function over the first channel; (Saket: See column 4, lines 51-56: “Multiple smart contracts may be created and allotted to certain portions of a data record 'R', those data portions being different for each smart contract or the same. For example, separate smart contract corresponding to separate channels and certain subsets of the fields of the data record 'R', are created and shared with a set of data consumers.”)
receiving (reads on “a group of smart contracts 228, which are identified and endorsed by one or more of the blockchain peer nodes 201”) a first endorsement of the first function from each of the first system and the second system; (Saket: See column 8, lines 20-23: “The set of smart contracts may be setup as a group of smart contracts 228, which are identified and endorsed by one or more of the blockchain peer nodes 201.”)
generating a first distributed ledger including the first function and the first endorsement, wherein the first distributed ledger is available only to the first system and the second system; (Saket: See column 4, lines 9-22: “A ledger is a sequenced, tamper-resistant record of all state transitions of a blockchain. State transitions may result from chaincode invocations (i.e., transactions) submitted by participating parties (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). A transaction may result in a set of asset key-value pairs being committed to the ledger as one or more operands, such as creates, updates, deletes, and the like. The ledger includes a blockchain (also referred to as a chain) which is used to store an immutable, sequenced record in blocks. The ledger also includes a state database which maintains a current state of the blockchain. There is typically one ledger per channel. Each peer node maintains a copy of the ledger for each channel of which they are a member.”, and Notes: as cited, the ledger can be accessible to only a member.)
deploying (reads on “separate smart contract corresponding to separate channels”) a second function related to the first function over the second channel; (Saket: See column 4, lines 51-55: “Multiple smart contracts may be created and allotted to certain portions of a data record 'R', those data portions being different for each smart contract or the same. For example, separate smart contract corresponding to separate channels and certain subsets of the fields of the data record 'R', are created and shared with a set of data consumers.”)
receiving (reads on “a group of smart contracts 228, which are identified and endorsed by one or more of the blockchain peer nodes 201”) a second endorsement of the second function from the first system and the at least one subsystem; and (Saket: See column 8, lines 20-23: “The set of smart contracts may be setup as a group of smart contracts 228, which are identified and endorsed by one or more of the blockchain peer nodes 201.”)
Saket does not explicitly disclose the following, however Panikkar further teaches:
providing (reads on “the OEM blockchain node 1202 defining the channels” and “affiliated factories that collaborate on manufacturing an order can share the same channel”) a second channel in the private network (reads on “private and restricted access to participants to the blockchain”) between the first system and at least one subsystem of the first system (reads on “a blockchain for access by entities in the supply chain comprising at least a subset of one or more supply entities, one or more material distribution entities, and one or more manufacturing entities.”); (Panikkar: See paragraphs [0005] “An initial transaction is generated representing a forecasted demand for material needed to manufacture equipment via a supply chain. The initial transaction is added to a blockchain for access by entities in the supply chain comprising at least a subset of one or more supply entities, one or more material distribution entities, and one or more manufacturing entities.”, [0040] “while all the blockchain nodes typically participate in the consensus protocol, a subset of blockchain nodes can participate in various embodiments. Also, while each blockchain node maintains a local updated copy of the blockchain, in illustrative embodiments, only OEM block chain nodes are given a full view (i.e., full access) to all transactions in the blockchain”, and [0069] “the blockchain architecture uses private and restricted access to participants to the blockchain, e.g., the factory can see their order data, but within different factories they should not see orders of others, and the same is true with respect to vendors and customers. ….. The channel MSP defines the relationship between the identities of channel members and the enforcement of channel level policies. Thus, for example, the OEM blockchain node 1202 (as MSP) specifies that each of Supplier/SLC/Factory blockchain nodes 1204/ 1206/1208 respectively should see only their data. This is accomplished by the OEM blockchain node 1202 defining the channels and chain code. In some embodiments, affiliated factories that collaborate on manufacturing an order can share the same channel.”, and notes: Examiner considers the cited above “subset of one or more supply entities” and “a subset of blockchain nodes” disclose the amended claim “the first system and at least one subsystem of the first system”.)
generating a second distributed ledger including the second function and the second endorsement, wherein the second distributed ledger is available only to the first system and the at least one subsystem of the first system. (Panikkar: See paragraphs [0069] “the blockchain architecture uses private and restricted access to participants to the blockchain, e.g., the factory can see their order data, but within different factories they should not see orders of others, and the same is true with respect to vendors and customers. the OEM blockchain node 1202 (as MSP) specifies that each of Supplier/SLC/Factory blockchain nodes 1204/1206/1208 respectively should see only their data. This is accomplished by the OEM blockchain node 1202 defining the channels and chain code. In some embodiments, affiliated factories that collaborate on manufacturing an order can share the same channel” and [0070] “in OEM blockchain node 1202, an endorse peer is responsible for the certificate authority (CA) verification, rules and identity, and it executes the respective chain code (e.g., a smart contract) and approves transactions. Then, the transaction is then sent to an ordering peer and updated in the blockchain through the respective channel.” and see also [0005] and [0040], notes: Examiner considers the cited above “subset of one or more supply entities” and “a subset of blockchain nodes” disclose the amended claim “the first system and at least one subsystem of the first system”)
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify a data record to be included in a blockchain, creating a group of smart contracts to enable access to the data record to data consumers with access to the blockchain of Saket to include the blockchain architecture that uses private and restricted access to participants to the blockchain, e.g., the factory can see their order data, but within different factories they should not see orders of others, as taught by Panikkar, in order to provide more secure business transactions. (See Panikkar, [0069-0070])
Regarding claim 2:
Saket discloses the following:
The method of claim 1 further comprising:
deploying a third function related to the second function over the first channel; (Saket: See column 4, lines 51-55: “Multiple smart contracts may be created and allotted to certain portions of a data record 'R', those data portions being different for each smart contract or the same. For example, separate smart contract corresponding to separate channels and certain subsets of the fields of the data record 'R', are created and shared with a set of data consumers.”)
receiving a third endorsement of the third function from the first system and the second system; and (Saket: See column 8, lines 20-23: “The set of smart contracts may be setup as a group of smart contracts 228, which are identified and endorsed by one or more of the blockchain peer nodes 201.”)
appending the first distributed ledger with the third function and the third endorsement. (Saket: See column 7, lines 1-18: “The blockchain configuration may include one or applications 224 which are linked to application programming interfaces (APIs) 222 to access and execute stored program/application code 220 (e.g., chaincode, smart contracts, etc.) which can be created according to a customized configuration sought by participants and can maintain their own state, control 15their own assets, and receive external information. This can be deployed as a transaction and installed, via appending to the distributed ledger, on all blockchain nodes 204-210.”)
Regarding claim 3:
Saket discloses the following:
The method of claim 1 wherein the first distributed ledger (reads on “There is typically one ledger per channel. Each peer node maintains a copy of the ledger for each channel of which they are a member.”) is stored at the first system and the second system. (Saket: See column 4, lines 9-22: “A ledger is a sequenced, tamper-resistant record of all state transitions of a blockchain. State transitions may result from chaincode invocations (i.e., transactions) submitted by participating parties (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). A transaction may result in a set of asset key-value pairs being committed to the ledger as one or more operands, such as creates, updates, deletes, and the like. The ledger includes a blockchain (also referred to as a chain) which is used to store an immutable, sequenced record in blocks. The ledger also includes a state database which maintains a current state of the blockchain. There is typically one ledger per channel. Each peer node maintains a copy of the ledger for each channel of which they are a member.”, and Notes: as cited, one ledger per channel and that is, a second ledger for the second channel.)
Regarding claim 4:
Saket discloses the following:
The method of claim 1 wherein the second distributed ledger (reads on “There is typically one ledger per channel. Each peer node maintains a copy of the ledger for each channel of which they are a member.”) is stored at the first system and the at least one subsystem. (Saket: See column 4, lines 9-22: “A ledger is a sequenced, tamper-resistant record of all state transitions of a blockchain. State transitions may result from chaincode invocations (i.e., transactions) submitted by participating parties (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). A transaction may result in a set of asset key-value pairs being committed to the ledger as one or more operands, such as creates, updates, deletes, and the like. The ledger includes a blockchain (also referred to as a chain) which is used to store an immutable, sequenced record in blocks. The ledger also includes a state database which maintains a current state of the blockchain. There is typically one ledger per channel. Each peer node maintains a copy of the ledger for each channel of which they are a member.”, and Notes: as cited, one ledger per channel and that is, a second ledger for the second channel.)
Regarding claim 5:
Saket discloses the following:
The method of claim 1 wherein the first function and the second function each include smart contracts. (Saket: See column 4, lines 51-60: “Multiple smart contracts may be created and allotted to certain portions of a data record 'R', those data portions being different for each smart contract or the same. For example, separate smart contract corresponding to separate channels and certain subsets of the fields of the data record 'R', are created and shared with a set of data consumers.”)
Regarding claim 6:
Saket discloses the following:
The method of claim 1 wherein the private network includes a blockchain network. (Saket: See column 10, lines 8-15: “In this example, the blockchain user 302 connects to the network through a peer node 308. Before proceeding with any transactions, the peer node 308 retrieves the user's enrollment and transaction certificates from the certificate authority 318. In some cases, blockchain users must possess these digital certificates in order to transact on the permissioned blockchain network 310.”)
Regarding claim 7:
Saket does not explicitly disclose the following, however Panikkar further teaches:
The method of claim 1 wherein the first system and the at least one subsystem comprise a business-to-business ecosystem. (Panikkar: See paragraph [0065] “Supplier 1 then initiates the transaction to an SLC (e.g., designated APCC) and ships the material to the SLC. Block 1102 in the set of block transactions 1100 of FIG. 11 is generated and added to the blockchain to show the shipment. The OEM can update on-hand inventory as expected inventory. Again, with traditional B2B communication, this visibility is not possible.”)
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify a data record to be included in a blockchain, creating a group of smart contracts to enable access to the data record to data consumers with access to the blockchain of Saket to include the blockchain architecture that uses private and restricted access to participants to the blockchain, e.g., the factory can see their order data, but within different factories they should not see orders of others, as taught by Panikkar, in order to provide more secure business transactions. (See Panikkar, [0069-0070])
Regarding claim 8:
Saket discloses the following:
The method of claim 7 wherein the first system comprises a customer interface. (Saket: See column 9, lines 52-60: “the blockchain user 302 may submit a transaction to the permissioned blockchain network 310. In this example, the transaction can be a deploy, invoke or query, and may be issued through a client-side application leveraging an SDK, directly through a REST API”)
Regarding claim 9:
Saket discloses the following:
The method of claim 1 further comprising providing a third channel between a third system and the first system, wherein the third channel is isolated from the first channel. (Saket: See column 5, lines 14-49: “A channel is a set of blockchain peers which share a distributed ledger corresponding to the channel and which is accessible to only its peers. A channel may have several smart contracts instantiated on it which modify the shared ledger. A separate blockchain of transactions is maintained for each channel by its peers…. Since the different endorsed transaction proposals in the endorsed group-invoke proposal may correspond to different channels, they are distributed into blocks of their respective channels.”)
Regarding claim 10:
Saket discloses the following:
The method of claim 1 further comprising encrypting the first function. (Saket: See column 7, lines 58-66: “Data written to the blockchain can be public and/or can be encrypted and maintained as private.”)
Regarding claims 11 and 20: it is similar scope to claim 1, and thus it is rejected under similar rationale.
Regarding claim 12: it is similar scope to claim 2, and thus it is rejected under similar rationale.
Regarding claim 13: it is similar scope to claims 3 and 4, and thus it is rejected under similar rationale.
Regarding claim 14: it is similar scope to claim 5, and thus it is rejected under similar rationale.
Regarding claim 15: it is similar scope to claim 6, and thus it is rejected under similar rationale.
Regarding claim 16: it is similar scope to claim 7, and thus it is rejected under similar rationale.
Regarding claim 17: it is similar scope to claim 8, and thus it is rejected under similar rationale.
Regarding claim 18: it is similar scope to claim 9, and thus it is rejected under similar rationale.
Regarding claim 19: it is similar scope to claim 10, and thus it is rejected under similar rationale.
Conclusion
The prior art made of record but not relied upon herein but pertinent to Applicant’s disclosure is listed in the enclosed PTO-892.
THIS ACTION IS MADE FINAL. 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 extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YONG S PARK whose telephone number is (571)272-8349. The examiner can normally be reached on M-F 9:00-5:00 PM, EST.
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, Bennett M. Sigmond can be reached on (303)297-4411. 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.
/YONGSIK PARK/Examiner, Art Unit 3694
February 17, 2026
/BENNETT M SIGMOND/Supervisory Patent Examiner, Art Unit 3694