DETAILED ACTION
Amendment submitted March 18, 2026 has been considered by examiner. Claims 13, 15-20, 22-25, 27-32 and 34-36 are pending.
Response to Arguments
Applicant's arguments filed March 18, 2026 have been fully considered but they are not persuasive.
The Applicant states that, “Neither Narendranathan nor Sepulveda describe performing blockchain transactions on the blockchain as claimed. Narendranathan implements the blockchain transactions independent of any use cases including requests that invoke multiple transactions to be executed on the blockchain. Sepulveda does not in any way suggest to one skilled in the art to modify Narendranathan to identify a type of the request from the client application and, based on the type of the request, forward the request and the input data to blockchain platform specific services for satisfying the request by "invoking, by a blockchain platform specific service layer, the blockchain platform specific services that are to be executed for completing the request by a blockchain platform specific chaincode that translates the request into blockchain transactions for execution on the blockchain platform" and "exposing predetermined representational state transfer (REST) APIs to the client application that the client application uses to access the blockchain transactions that interact with the blockchain platform in accordance with predetermined use case specific rules that implement logic for predetermined use cases of the blockchain specific platform.” The Examiner respectfully disagrees.
As to performing blockchain transaction on the blockchain, Narendranathan [0019] states “The blockchain may provide enhanced security because each block may hold individual transactions and the results of any blockchain executables.” That is interpreted as something, such as a transaction, was executed on the blockchain. Sepulveda [0042] states “The blockchain, or more specifically the smart contract on the blockchain, executes the transaction…” That is interpreted as executing a transaction on the blockchain.
As to identifying a particular request type, see at least Narendranathan [0018] identifying transaction types. Also, Narendranathan [0029] discloses translating requests, which is interpreted as identifying that the type of a request is to translate something into a particular format.
As to “exposing predetermined representational state transfer (REST) APIs to the client application that the client application uses to access the blockchain transactions that interact with the blockchain platform in accordance with predetermined use case specific rules that implement logic for predetermined use cases of the blockchain specific platform,” see at least Narendranathan [0029] and Sepulveda [0014].
Narendranathan [0029] discloses using an API to access information related to a blockchain; Sepulveda [0014] states “The blockchain is exposed via a representational state transfer (RESTful) service abstraction layer…” The reason to expose a blockchain via an API such as RESTful is to at least “to interact with the blockchain.” The interaction is for a particular use case.
As such, the previously cited prior art discloses the above argued features.
No further detailed and specific arguments are provided.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 13, 16-18, 20, 22-25, 29-30, 32 and 34-36 are rejected under 35 U.S.C. 103 as being unpatentable over Narendranathan et al (US Patent Application Publication 2022/0198458, hereinafter, Naren) in view of Sepulveda et al (US Patent Application Publication 2021/0042748).
Claim 13: Naren discloses a method for interfacing a client application to a blockchain platform that manages a blockchain, comprising:
receiving, by a service layer, a request from the client application to have a service performed that requires performance of blockchain transactions on the blockchain [0029, 0046]. [See at least a request to access blockchain transactions.]
collecting, by the service layer, input data in the request from the client application [0029]. [“API 216 and/or SDK 218 may be configured to translate requests received by identity management user interface 214 into a blockchain format using a blockchain…”]
identifying, by an application programming interface (API) layer, a type of the request from the client application [0029, 0046]. [“API 216 and/or SDK 218 may be configured to translate requests received by identity management user interface 214 into a blockchain format using a blockchain…”]
based on the type of the request, forwarding, by the API layer, the request and the input data to blockchain platform specific services for satisfying the request [0029]. [“API 216 and/or SDK 218 may be configured to translate requests received by identity management user interface 214 into a blockchain format using a blockchain…”]
invoking, by a blockchain platform specific service layer, the blockchain platform specific services that are to be executed for completing the request by a blockchain platform specific chaincode that translates the request into blockchain transactions for execution on the blockchain platform [0046]. [See at least translating data received from a transaction that interacts with a blockchain, “may be configured to translate data received from transaction engine 253 into a blockchain format…”]
Naren alone does not explicitly disclose the rest of the limitations.
However, Sepulveda discloses:
managing, by the blockchain platform specific chaincode, data operations for completing the request by executing the blockchain transactions on the blockchain platform [0042]. [See at least executing the transaction on the blockchain.]
returning results of execution of the blockchain transactions and input data on the blockchain platform to the blockchain platform specific service layer [0042]. [See at least “returns a confirmation after the transaction is completed in the blockchain.”]
returning, by the blockchain platform specific service layer, the results of execution of the blockchain transactions and input data on the blockchain platform to the service layer and through the service layer to the client application [0048]. [“After receiving the confirmation from the blockchain that the transaction is complete, the services layer system 102 updates the operational database 112 to reflect the transfer and displays a confirmation message in the user interface.”]
exposing predetermined representational state transfer (REST) APIs to the client application that the client application uses to access the blockchain transactions that interact with the blockchain platform in accordance with predetermined use case specific rules that implement logic for predetermined use cases of the blockchain specific platform [0014]. [Sepulveda states, “The blockchain is exposed via a representational state transfer (RESTful) service abstraction layer…” The reason to expose a blockchain via an API such as RESTful is to at least “to interact with the blockchain.” The interaction is for a particular use case.]
As such, it would have been obvious for one of ordinary skill in the art before the effective filing date to modify Naren with Sepulveda. One would have been motivated to do so in order to provide a confirmation of executed transactions in a particular environment such as a blockchain and to provide customizable functionality for users.
Claim 25: Naren discloses a non-transitory computer-readable medium having instructions stored thereon that when executed by one or more processors cause the one or more processors to implement a method for interfacing a client application to a blockchain platform that manages a blockchain, the instructions comprising:
first instructions for generating a service layer including an application programming interface (API) layer, the service layer receiving a request from the client application to have a service performed that requires performance of blockchain transactions on the blockchain and collecting input data in the request from the client application, and the API layer identifying a type of the request from the client application and, based on the type of the request, forwarding the request and the input data to blockchain specific services for satisfying the request [0046]. [See at least a request from an API for blockchain transactions.]
Naren alone does not explicitly disclose the rest of the limitations.
However, Sepulveda discloses:
second instructions for generating a blockchain platform specific service layer that receives the request and input data collected from the request to invoke the platform specific services that are to be executed for completing the request and returns results of execution of blockchain transactions for the platform specific services executed on the blockchain platform for completing the request to the service layer and through the service layer to the client application [0042]. [See at least executing the transaction on the blockchain; And see at least “returns a confirmation after the transaction is completed in the blockchain.”]
third instructions for generating a blockchain platform specific chaincode that translates the request into blockchain transactions for execution on the blockchain platform and manages data operations for completing the request by executing the blockchain transactions on the blockchain platform and returning results of execution of the blockchain transactions and input data on the blockchain platform to the blockchain platform specific service layer [0042, 0048]. [See at least executing the transaction on the blockchain; And see at least “After receiving the confirmation from the blockchain that the transaction is complete, the services layer system 102 updates the operational database 112 to reflect the transfer and displays a confirmation message in the user interface.”]
wherein the API layer exposes predetermined representational state transfer (REST) APIs to the client application that the client application uses to access the blockchain transactions that interact with the blockchain platform in accordance with predetermined use case specific rules that implement logic for predetermined use cases of the blockchain specific platform [0014]. [Sepulveda states, “The blockchain is exposed via a representational state transfer (RESTful) service abstraction layer…” The reason to expose a blockchain via an API such as RESTful is to at least “to interact with the blockchain.” The interaction is for a particular use case.]
As such, it would have been obvious for one of ordinary skill in the art before the effective filing date to modify Naren with Sepulveda. One would have been motivated to do so in order to provide a confirmation of executed transactions in a particular environment such as a blockchain and to provide customizable functionality for users.
Claim 16: Naren discloses the method of Claim 13 above, and Naren further discloses enabling multiple client applications to create and manage data on the blockchain platform using the API layer, service layer, and blockchain platform specific chaincode [0046].
Claims 17 and 29: Naren discloses the method and the medium of Claims 13 and 25 above, and Naren further discloses formatting input data collected from the request by the API layer validating the request from the client application, validating user details received in the request from the client application, checking permission for the user to perform the request from the client application, and preparing the request for submission to the blockchain platform [0029]. [See at least validation engine.]
Claims 18 and 30: Naren discloses the method and the medium of Claims 13 and 25 above, and Naren further discloses wherein the API layer, service layer, and blockchain platform specific chaincode are adapted to support three roles comprising a Platform Admin, a Tenant, and Core ASIK Participants, where the Platform Admin is responsible for enrolling client applications, a Tenant has an ID and resources allocated to it that can be used to perform create, read, update, and delete operations on the formatted input data, and the Core ASIK Participants have their own ID which is used to initiate requests with the API layer [0028, 0041]. [See at least registering users, having user IDs for the registration for transactions and other requests.]
Claims 20 and 32: Naren discloses the method and the medium of Claims 13 and 25 above, and Naren further discloses wherein the service layer describes tasks or operations to be performed for the service to be performed by outlining a semantics and syntax and at least one interface through which the at least one blockchain transactions and formatted input data interact with the blockchain platform for the predetermined use case specific rule [0029]. [See at least receiving commands and translating them into a particular format for communication with a blockchain.]
Claims 22 and 34: Naren discloses the method and the medium of Claims 13 and 25 above, and Naren further discloses wherein the blockchain platform specific chaincode accesses a blockchain ledger and smart contracts of the blockchain platform to query or update the blockchain ledger [0019].
Claims 23 and 35: Naren discloses the method and the medium of Claims 13 and 25 above, and Naren further discloses wherein all operations of the client applications are logged securely to the blockchain ledger [0019, 0032].
Claims 24 and 36: Naren discloses the method and the medium of Claims 13 and 25 above, and Naren further discloses a state database, wherein the service layer accepts inputs from the API layer and translates the inputs to action by invoking the blockchain platform specific chaincode and the state database [0019-0020, 0046].
Claim 28 is rejected under 35 U.S.C. 103 as being unpatentable over Narendranathan et al (US Patent Application Publication 2022/0198458, hereinafter, Naren) in view of Sepulveda et al (US Patent Application Publication 2021/0042748) and further in view of Padmanabhan et al (US Patent Application Publication 2020/0252406).
Claim 28: Naren discloses the medium of Claim 25 above, but Naren alone does not explicitly disclose wherein the API layer, service layer, and blockchain platform specific chaincode are adapted to support a multi-tenant framework whereby multiple client applications create and manage data on the blockchain platform.
However, Padmanabhan [0077] discloses being able to use a blockchain in a multi-tenant environment to at least create and/or manage data.
As such, it would have been obvious for one of ordinary skill in the art before the effective filing date to modify Naren with Padmanabhan. One would have been motivated to do so in order for tenants to be able to use blockchain technology for data management.
Claims 15 and 27 rejected under 35 U.S.C. 103 as being unpatentable over Narendranathan et al (US Patent Application Publication 2022/0198458, hereinafter, Naren) in view of Sepulveda et al (US Patent Application Publication 2021/0042748) and further in view of Harris et al (US Patent Application Publication 2021/0143980).
Claims 15 and 27: Naren discloses the method and the medium of Claims 13 and 25 above, but Naren alone does not explicitly disclose wherein the predetermined REST APIs are load balanced and are adapted to interact with the blockchain platform.
However, Harris [0018, 0063-0064] discloses using REST API traffic that is distributed via load balancing with relation to blockchains.
As such, it would have been obvious for one of ordinary skill in the art before the effective filing date to modify Naren with Harris. One would have been motivated to do so in order to make sure that traffic is evenly distributed across nodes for optimized data processing.
Claims 19 and 31 are rejected under 35 U.S.C. 103 as being unpatentable over Narendranathan et al (US Patent Application Publication 2022/0198458, hereinafter, Naren) in view of Mohan et al (US Patent Application Publication 2014/0222885) and further in view of Beecham et al (US Patent Application Publication 2018/0307857)
Claims 19 and 31: Naren discloses the method and the medium of Claims 18 and 30 above, but Naren alone does not explicitly disclose a database for each Tenant whereby each Tenant performs operations in its own database.
However, Beecham [0043, 0053] discloses that each tenant would have private data storage.
As such, it would have been obvious for one of ordinary skill in the art before the effective filing date to modify Naren with Beecham. One would have been motivated to do so in order to provide a storage space for each tenant to store their private data.
Conclusion
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 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 ALEX GOFMAN whose telephone number is (571)270-1072. The examiner can normally be reached Monday-Friday 8-5.
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, Tony Mahmoudi can be reached at 571-272-4078. 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.
/ALEX GOFMAN/Primary Examiner, Art Unit 2163
Prosecution Insights