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 .
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 05/19/2026 has been entered.
The following is a non-final office action in response to the request for continued examination of 05/19/2026.
Status of Claims
Claims 1-20, as originally filed 04/20/2026, are pending and have been examined on the merits (claims 1, 11, and 20 being independent). Claims 1, 11, and 20 have been amended.
Response to Arguments
Applicant’s arguments and amendments filed 04/20/2026 have been fully considered but they are not persuasive.
With regard to the rejections of the claims under 35 USC 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. Further as noted in the citation above the prior art and the amendments are addressed by the rejections cited under 35 USC 103.
Applicant’s arguments: (see Applicant’s remarks, pages 8-10)
(1) Applicant’s arguments that “Even under the broadest reasonable interpretation standard, claim terms must be read in light of the specification. The specification is unambiguous on this point: it describes "subsystems SS1, SS2, SS3 of the vendor V' as internal components operating within the vendor's own environment, with Channel B forming "a second private network between the vendor V and the subsystems SSl, SS2, SS3." ¶ [0035]. The subsystems are internal to the vendor - they are not outside trading partners.” (see remarks, page 9-10), are not found persuasive.
In response of the arguments (1), Examiner fails to see the “subsystems SS1, SS2, SS3 of the vendor V” are internal components operating within the vendor as reading in view of the specification or the recited claims because that subject matter is not properly described in the specification, and it is not clear whether the subsystems are internal components or external components. For example, the subsystems can be separated entities in a group (e.g., the vendor V) or affiliated entities in a group (e.g., an OEM) or both. Therefore, Examiner is not clear how to interpret the amended claim “internal subsystem” which is not properly described in the specification. Finally, there is no evidence that the subsystems are internal components, but the subsystems can be external entities, internal entities, or both.
(2) Applicant’s arguments that “Panikkar's entities are the opposite of this. The Supplier, SLC, and Factory are outside trading partners that happen to be affiliated with the OEM through a supply chain relationship. Panikkar itself uses the word "affiliated" to describe factories that share a channel (i.e. "affiliated factories that collaborate on manufacturing an order can share the same channel" [0069]), which confirms that even closely affiliated entities are treated as separate external participants, not as internal subsystems of a single first system” (see remarks, page 9-10), are not found persuasive.
In response of the arguments (2), Examiner considers that the affiliated entities can be external entities, internal entities, or both. As cited “affiliated factories that collaborate on manufacturing an order can share the same channel” in ¶ [0069], the affiliated factories can be internals entities such as A entity, B entity, and C entity that work together and share the same channel as required in the specification [0035] that describes the subsystems SS1, SS2, SS3 that share the same channel B. As such, Applicant’s arguments are not persuasive.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention.
As the recited claim in independent claims 1, 11, and 20, “internal subsystem”, the subject matter is not properly described in the application as filed, and provide an explanation of your position. The recited amendment as highlighted above is not clear as to how the “internal subsystem” is to be interpreted because the claimed limitation is not described in the application with sufficient detail such that one skilled in the art can reasonably conclude that the inventor had possession of the claimed invention at the time of filing.
Dependent claims (2-12 and 13-19) stand rejected also, under 35 U.S.C. 112(a) by virtue of their dependency on a rejected claim.
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 a first channel in a private network between a first system and a second system; (Saket: See column 5, lines 15-20: discloses “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.”)
receiving a first function over the first channel; (Saket: See column 4, lines 51-56: discloses “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 first endorsement of the first function from each of the first system and the second system; (Saket: See column 8, lines 20-23: discloses “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: discloses “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 a second function related to the first function over the second channel; (Saket: See column 4, lines 51-55: discloses “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.”, and Notes: Examiner considers that separate smart contract discloses “a second function” or “the first function” and separate channels disclose “the second channel.”)
receiving 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: discloses “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 a second channel in the private network between the first system and at least one internal subsystem of the first system; (Panikkar: See paragraph [0069] discloses “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”, “a subset of blockchain nodes”, and “affiliated factories that collaborate on manufacturing an order can share the same channel.” disclose the amended claim “at least one internal subsystem of the first system”, and also Examiner considers that the affiliated factories can be external entities, internal entities, or both.)
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 internal subsystem of the first system. (Panikkar: See paragraphs [0069] discloses “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] discloses “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], and Notes: Examiner considers the cited above “subset of one or more supply entities”, “a subset of blockchain nodes”, and “affiliated factories that collaborate on manufacturing an order can share the same channel.” disclose the amended claim “at least one internal subsystem of the first system”, and also Examiner considers that the affiliated factories can be external entities, internal entities, or both.)
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: discloses “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: discloses “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: discloses “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: discloses “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: discloses “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: discloses “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: discloses “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] discloses “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: discloses “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: discloses “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: discloses “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.
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 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
July 23, 2026
/BENNETT M SIGMOND/Supervisory Patent Examiner, Art Unit 3694
Prosecution Insights