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 .
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.
Examiner Notes
(1) In the case of amending the Claimed invention, Applicant is respectfully requested to indicate the portion(s) of the specification which dictate(s) the structure relied on for proper interpretation and also to verify and ascertain the metes and bounds of the claimed invention. This will assist in expediting compact prosecution. MPEP 714.02 recites: “Applicant should also specifically point out the support for any amendments made to the disclosure. See MPEP § 2163.06. An amendment which does not comply with the provisions of 37 CFR 1.121 (b), (c), (d), and (h) may be held not fully responsive. See MPEP § 714.” Amendments not pointing to specific support in the disclosure may be deemed as not complying with provisions of 37 C.F.R. 1.131 (b), (c), (d), and (h) and therefore held not fully responsive. Generic statements such as "Applicants believe no new matter has been introduced" may be deemed insufficient.
(2) Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
Remarks
Receipt of Applicant’s Amendment file on 11/06/2025 is acknowledged.
Response to Arguments
Applicant's arguments filed 11/06/2025 have been fully considered but they are not persuasive.
Regarding claim 1, applicant argues that cited reference do not teach “each of the plurality of distributed ledgers running on the cloud-based platform as a separate tenant of a plurality of tenants of the cloud-based platform and utilizing the infrastructure services and embedded resources of the cloud-based platform” (page 8, 2nd paragraph).
Respectfully, it is noted that Nossik, Fig. 2, col. 5, line 34-50, col. 6, line 25-35, teaches: a plurality of distinct ledger systems, each comprising a corresponding blockchain distributed ledger maintained collectively by an associated plurality of clouds, each of the blockchain distributed ledger and ledger nodes of its respective clouds collectively provide a distinct ledger system; the ledger nodes collectively implement a blockchain based distributed arrangement for designated cloud services that are provided at least in part utilizing set of clouds resources of the respective first, second and other clouds; also see Fig. 1-2, col. 2, line 33-44 and line 65, col. 4, line 38-44, the cloud resources implemented by the clouds can include container-based compute functionality and associated storage; the cloud comprise respectively ledger nodes, the first ledger nodes and additional ledger nodes collectively maintain the blockchain distributed ledger on a peer-to-peer basis, which reads on “a plurality of distributed ledgers, each of the plurality of distributed ledgers running on the cloud- based platform as a separate tenant of a plurality of tenants of the cloud-based platform, wherein each of the plurality of distributed ledgers are run on a set of containers provided by the container service”. Further noted, Fig. 10a-10c, col. 7, line 40-67, the server/cloud may provide services of Issuing Trust using one or more servers, storage, and/or applications, or using hosted services, or using Cloud services provided by a third party vendor; Fig. 10C illustrates plurality of ledgers as separate tenants to utilize cloud services for managing transactions
Ramanathan, Fig. 10a-10c, col. 7, line 40-67, teaches the server/cloud may provide services of Issuing Trust using one or more servers, storage, and/or applications, or using hosted services, or using Cloud services provided by a third party vendor; Fig. 10C illustrates plurality of ledgers as separate tenants to utilize cloud services for managing transactions, which reads on “a plurality of distributed ledgers, each of the plurality of distributed ledgers running on the cloud-based platform as a separate tenant of a plurality of tenants of the cloud-based platform and utilizing the infrastructure services and embedded resources of the cloud-based platform” as claimed.
Ramanathan, Fig. 10c, col. 16, line 6-25, col. 15, further teaches: Wallet service identifies general ledger, authenticates itself and establish a secure and encrypted communication; sending coin ID via transaction structure; managing other ledger services and obtain information as to the owner of the coin for the Wallet Service application; Fig. 10C illustrates plurality of ledgers as separate tenants to utilize cloud services for managing transactions, which reads on “wherein each of the plurality of distributed ledgers are isolated from each other of the plurality of distributed ledgers, said isolation being provided at least in part by each set of containers on which each of the plurality of distributed ledgers are run” as claimed.
Therefore, the cited references disclose the limitations.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-30 of U.S. Patent No. 11556521. The subject matter claimed in the instant application is fully disclosed in the U.S. Patent No. 11556521 and is covered by the U.S. Patent No. 11556521 and the application are claiming common subject matter, as follows:
U.S. Patent No. 11556521
Instant Application
1. A system for providing an interface for a blockchain cloud service, comprising: a computer comprising at least one processor at which at least one instance of a container runtime service is deployed, the deployed container runtime service comprising at least one container from a plurality of containers defined within a stack at a repository, wherein each of the plurality of containers comprise a library and a configuration; and a plurality of distributed ledger components in the at least one instance of the deployed container runtime service, each of the plurality of distributed ledger components running within a different container of the plurality of containers, wherein each the plurality of distributed ledger components is provisioned as a separate blockchain cloud service within the at least one instance of the deployed container runtime service, the at least one instance of the deployed runtime service having therein a plurality of peer containers, a plurality of ordering containers, and a plurality of chaincode containers, each of the blockchain cloud services respectively comprising; a peer container of the plurality of peer containers, an ordering container of the plurality of ordering containers, and a chaincode container of the plurality of chaincode containers; wherein each of the peer container, the ordering container, and the chaincode container for each blockchain cloud service are provisioned based upon the plurality of containers defined within the stack at the repository; wherein each of the plurality of peer containers maintains a respective blockchain ledger of a plurality of blockchain ledgers, each blockchain ledger being maintained by a different respective peer container of the plurality of peer containers; wherein each of the plurality of ordering containers orders transactions within the respective blockchain ledger; wherein each of the plurality of chaincode containers comprises a chaincode execution unit that encodes assets in the respective blockchain ledger; and wherein the at least one instance of the deployed container runtime service receives an incoming call from a client application, the incoming call requesting an entry into a targeted blockchain ledger; and wherein the peer container associated with the targeted blockchain ledger comprises an endorser and a committer, wherein the endorser simulates the requested entry into the targeted blockchain ledger maintained by the peer container associated with the targeted blockchain ledger, and wherein the committer, upon approval, commits the requested entry to the targeted blockchain ledger maintained by the peer container associated with the targeted blockchain ledger.
1. (Previously Presented) A system for providing an interface for a blockchain cloud service, comprising: a computer comprising at least one processor; a cloud-based platform comprising a container service, the cloud-based platform further comprising infrastructure services and embedded resources; a plurality of distributed ledgers, each of the plurality of distributed ledgers running on the cloud-based platform as a separate tenant of a plurality of tenants of the cloud-based platform and utilizing the infrastructure services and embedded resources of the cloud-based platform, wherein each of the plurality of distributed ledgers are run on a set of containers provided by the container service, wherein each of the plurality of distributed ledgers are isolated from each other of the plurality of distributed ledgers, said isolation being provided in part by each set of containers on which each of the plurality of distributed ledgers are run; an identity service, the identity service providing authentication for each of the plurality of distributed ledgers; wherein each of the plurality of distributed ledgers respectively comprises: a peer container, an ordering container, and a chaincode container.
2. (Original) The system of The system of wherein each of the plurality of distributed ledgers is respectively associated with a different blockchain ledger.
3. (Original) The system of The system of wherein each peer container respectively maintains the blockchain ledger associated with the distributed ledger of the associated peer container.
4. (Original) The system of The system of wherein each chaincode container respectively enables assets to be written to the blockchain ledger associated with the distributed ledger of the associated chaincode container.
8. The system of claim 1, wherein the ordering container comprises an orderer that orders transactions within the respective blockchain ledger; and wherein the chaincode container is started by the peer container and communicates with the peer container to perform encoding of transactions in the respective blockchain ledger.
5. (Original) The system of The system of wherein each ordering container respectively order transactions on the blockchain ledger associated with the distributed ledger of the associated ordering container.
6. (Original) The system of The system of wherein each chaincode container is started by an associated peer container.
9. A method for providing an interface for a blockchain cloud service, comprising: providing, at a computer comprising at least one processor, at least one instance of a deployed container runtime service, the deployed container runtime service comprising at least one container from a plurality of containers defined within a stack at a repository, wherein each of the plurality of containers comprise a library and a configuration, and a plurality of distributed ledger components in the at least one instance of the deployed container runtime service, each of the plurality of distributed ledger components running within a different container of the plurality of containers, wherein each of the plurality of distributed ledger components is provisioned as a separate blockchain cloud service within the at least one instance of the deployed container runtime service, the at least one instance of the deployed runtime service having therein a plurality of peer containers, a plurality of ordering containers, and a plurality of chaincode containers, each of the blockchain cloud services respectively comprising, a peer container of the plurality of peer containers, an ordering container of the plurality of ordering containers, and a chaincode container of the plurality of chaincode containers; wherein each of the peer container, the ordering container, and the chaincode container for each blockchain cloud service are provisioned based upon the plurality of containers defined within the stack at the repository; maintaining, by each of the plurality of peer containers, a respective blockchain ledger of a plurality of blockchain ledgers, each blockchain ledger being maintained by a different respective peer container of the plurality of peer containers; ordering, by each of the plurality of ordering containers, transactions within the respective blockchain ledger; encoding, by a chaincode execution unit of each of the plurality of chaincode containers, assets in the respective blockchain ledger; and
receiving, at the at least one instance of the deployed container runtime service, an incoming call from a client application, the incoming call requesting an entry into a targeted blockchain ledger; wherein the peer container associated with the targeted blockchain ledger comprises an endorser and a committer, wherein the endorser simulates the requested entry into the targeted blockchain ledger maintained by the peer container, and wherein the committer, upon approval, commits the requested entry to the targeted blockchain ledger maintained by the peer container associated with the targeted blockchain ledger.
8. (Previously Presented) A method for providing an interface for a blockchain cloud service, comprising: providing a computer comprising at least one processor; providing, at the computer, a cloud-based platform comprising a container service, the cloud-based platform further comprising infrastructure services and embedded resources; running a plurality of distributed ledgers, wherein each of the plurality of distributed ledgers are run as a separate tenant of a plurality of tenants of the cloud-based platform and utilizing the infrastructure services and embedded resources of the cloud-based platform, wherein each of the plurality of distributed ledgers are run on a set of containers provided by the container service, wherein each of the plurality of distributed ledgers are isolated from each other of the plurality of distributed ledgers, said isolation being provided in part by each set of containers on which each of the plurality of distributed ledgers are run; providing an identity service, the identity service providing authentication for each of the plurality of distributed ledgers; wherein each of the plurality of distributed ledgers respectively comprises: a peer container, an ordering container, and a chaincode container.
9. (Original) The method of claim 8, further comprising: associating, respectively, each of the plurality of distributed ledgers with a different blockchain ledger.
10. (Original) The method of claim 9, wherein each peer container respectively maintains the blockchain ledger associated with the distributed ledger of the associated peer container.
11. (Original) The method of claim 10, wherein each chaincode container respectively enables assets to be written to the blockchain ledger associated with the distributed ledger of the associated chaincode container.
11. The method of claim 9, wherein the at least one instance of the deployed container runtime service is associated with a front end load balancer; and wherein the incoming call, prior to being received at the at least one instance of the deployed container runtime service, is passed through the front end load balancer.
14. (Original) The method of claim 8, further comprising: providing a front end load balancer associated with each of the plurality of distributed ledgers; wherein an incoming call to a distributed ledger of the plurality of distributed ledgers is passed through the associated front end load balancer.
16. The method of claim 9, wherein the ordering container comprises an orderer that orders transactions within the respective blockchain ledger; and wherein the chaincode container is started by the peer container and communicates with the peer container to perform encoding of transactions in the respective blockchain ledger.
12. (Original) The method of claim 11, wherein each ordering container respectively order transactions on the blockchain ledger associated with the distributed ledger of the associated ordering container.
13. (Original) The method of claim 11, wherein each chaincode container is started by an associated peer container.
17. A non-transitory computer readable storage medium, including instructions stored thereon for providing an interface for a blockchain cloud service which when read and executed by one or more computers cause the one or more computers to perform steps comprising: providing, at a computer comprising at least one processor, at least one instance of a deployed container runtime service, the deployed container runtime service comprising at least one container from a plurality of containers defined within a stack at a repository, wherein each of the plurality of containers comprise a library and a configuration, and a plurality of distributed ledger components in the at least one instance of the deployed container runtime service, each of the plurality of distributed ledger components running within a different container of the plurality of containers, wherein each of the plurality of distributed ledger components is provisioned as a separate blockchain cloud service within the at least one instance of the deployed container runtime service, the at least one instance of the deployed runtime service having therein a plurality of peer containers, a plurality of ordering containers, and a plurality of chaincode containers, each of the blockchain cloud services respectively comprising, a peer container of the plurality of peer containers, an ordering container of the plurality of ordering containers, and a chaincode container of the plurality of chaincode containers; wherein each of the peer container, the ordering container, and the chaincode container for each blockchain cloud service are provisioned based upon the plurality of containers defined within the stack at the repository;
maintaining, by each of the plurality of peer containers, a respective blockchain ledger of a plurality of blockchain ledgers, each blockchain ledger being maintained by a different respective peer container of the plurality of peer containers; ordering, by each of the plurality of ordering containers, transactions within the respective blockchain ledger; encoding, by a chaincode execution unit of each of the plurality of chaincode containers, assets in the respective blockchain ledger;
and receiving, at the at least one instance of the deployed container runtime service, an incoming call from a client application, the incoming call requesting an entry into a targeted blockchain ledger; wherein the peer container associated with the targeted blockchain ledger comprises an endorser and a committer, wherein the endorser simulates the requested entry into the targeted blockchain ledger maintained by the peer container, and wherein the committer, upon approval, commits the requested entry to the targeted blockchain ledger maintained by the peer container associated with the targeted blockchain ledger.
15. (Previously Presented) A non-transitory computer readable storage medium having instructions thereon for providing an interface for a blockchain cloud service, which when read and executed cause a computer to perform steps comprising: providing a computer comprising at least one processor; providing, at the computer, a cloud-based platform comprising a container service, the cloud-based platform further comprising infrastructure services and embedded resources; running a plurality of distributed ledgers, wherein each of the plurality of distributed ledgers are run as a separate tenant of a plurality of tenants of the cloud-based platform and utilizing the infrastructure services and embedded resources of the cloud-based platform, wherein each of the plurality of distributed ledgers are run on a set of containers provided by the container service, wherein each of the plurality of distributed ledgers are isolated from each other of the plurality of distributed ledgers, said isolation being provided in part by each set of containers on which each of the plurality of distributed ledgers are run; providing an identity service, the identity service providing authentication for each of the plurality of distributed ledgers; wherein each of the plurality of distributed ledgers respectively comprises: a peer container, an ordering container, and a chaincode container.
16. (Original) The non-transitory computer readable storage medium of claim 15, the steps further comprising: associating, respectively, each of the plurality of distributed ledgers with a different blockchain ledger.
17. (Original) The non-transitory computer readable storage medium of The non-transitory computer readable storage medium of wherein each peer container respectively maintains the blockchain ledger associated with the distributed ledger of the associated peer container.
18. (Original) The non-transitory computer readable storage medium of The non-transitory computer readable storage medium of wherein each chaincode container respectively enables assets to be written to the blockchain ledger associated with the distributed ledger of the associated chaincode container.
24. The non-transitory computer readable storage medium of claim 17, wherein the ordering container comprises an orderer that orders transactions within the respective blockchain ledger; and wherein the chaincode container is started by the peer container and communicates with the peer container to perform encoding of transactions in the respective blockchain ledger.
19. (Original) The non-transitory computer readable storage medium of The non-transitory computer readable storage medium of wherein each ordering container respectively order transactions on the blockchain ledger associated with the distributed ledger of the associated ordering container.
Further, it would have been obvious to a person of ordinary skill in the art at the time the invention was made to modify or to omit the additional elements of claims U.S. Patent No. 11556521 to arrive at the claims 1-20 of the instant application because the person would have realized that the remaining element would perform the same functions as before. "Omission of element and its function in combination is obvious expedient if the remaining elements perform same functions as before." See In re Karlson (CCPA) 136 USPQ 184, decide Jan 16, 1963, Appl. No. 6857, U.S. Court of Customs and Patent Appeals.
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 of this title, 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 1-6, 8-13 and 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Nossik et al. (U.S. Patent No. 11,128,437 B1) in view of Ramanathan et al. (U.S. Patent No. 10,262,321 B1) and Ramesh Nagappan (“Unpacking HyperLedger Fabric 1.0 – Under the hood of a Permissioned Blockchain”; dated: July 07, 2017; http://websecuritypatterns.com/blogs/2017/07/07/unpacking-hyperledger-fabric-1-0-under-the-hood-of-a-permissioned-blockchain/).
Regarding claim 1,Nossik teaches a system for providing an interface for a blockchain cloud service (‘for’ indicates intended use; Minton v. Nat ’l Ass ’n of Securities Dealers, Inc., 336 F.3d 1373, 1381, 67 USPQ2d 1614, 1620 (Fed. Cir. 2003) “whereby clause in a method claim is not given weight when it simply expresses the intended result of a process step positively recited.” Examples of claim language, although not exhaustive, that may raise a question as to the limiting effect of the language in a claim are: (A) “adapted to” or “adapted for” clauses; (B) “wherein” clauses; and (C) “whereby” clauses. Therefore intended use limitations are not required to be taught, see MPEP 2111.04 [R-3]), comprising:
a computer comprising at least one processor (Fig. 1-6; col. 14, line 29-38);
a cloud-based platform comprising a container service (Fig. 1-6); a plurality of distributed ledgers (Fig. 2, col. 5, line 34-50, col. 6, line 25-35, a plurality of distinct ledger systems, each comprising a corresponding blockchain distributed ledger maintained collectively by an associated plurality of clouds, each of the blockchain distributed ledger and ledger nodes of its respective clouds collectively provide a distinct ledger system; the ledger nodes collectively implement a blockchain based distributed arrangement for designated cloud services that are provided at least in part utilizing set of clouds resources of the respective first, second and other clouds);
a plurality of distributed ledgers, each of the plurality of distributed ledgers running on the cloud- based platform as a separate tenant of a plurality of tenants of the cloud-based platform, wherein each of the plurality of distributed ledgers are run on a set of containers provided by the container service (Fig. 2, col. 5, line 34-50, col. 6, line 25-35, teaches a plurality of distinct ledger systems, each comprising a corresponding blockchain distributed ledger maintained collectively by an associated plurality of clouds, each of the blockchain distributed ledger and ledger nodes of its respective clouds collectively provide a distinct ledger system; the ledger nodes collectively implement a blockchain based distributed arrangement for designated cloud services that are provided at least in part utilizing set of clouds resources of the respective first, second and other clouds; also see Fig. 1-2, col. 2, line 33-44 and line 65, col. 4, line 38-44, the cloud resources implemented by the clouds can include container-based compute functionality and associated storage; the cloud comprise respectively ledger nodes, the first ledger nodes and additional ledger nodes collectively maintain the blockchain distributed ledger on a peer-to-peer basis);
wherein each of the plurality of distributed ledger respectively comprises: a peer container (Fig. 1-2, col. 2, line 33-44 and line 65, col. 4, line 38-44, the cloud resources implemented by the clouds can include container-based compute functionality and associated storage; the cloud comprise respectively ledger nodes, the first ledger nodes and additional ledger nodes collectively maintain the blockchain distributed ledger on a peer-to-peer basis).
Nossik does not explicitly disclose: the cloud-based platform further comprising infrastructure services and embedded resources; a plurality of distributed ledgers, each of the plurality of distributed ledgers running on the cloud-based platform as a separate tenant of a plurality of tenants of the cloud-based platform and utilizing the infrastructure services and embedded resources of the cloud-based platform, wherein each of the plurality of distributed ledgers are isolated from each other of the plurality of distributed ledgers, said isolation being provided at least in part by each set of containers on which each of the plurality of distributed ledgers are run; the identity service providing authentication for each of the plurality of distributed ledgers.
Ramanathan teaches: the cloud-based platform further comprising infrastructure services and embedded resources (col. 7, line 40-67, the server/cloud may provide services of Issuing Trust using one or more servers, storage, and/or applications, or using hosted services, or using Cloud services provided by a third party vendor); a plurality of distributed ledgers, each of the plurality of distributed ledgers running on the cloud-based platform as a separate tenant of a plurality of tenants of the cloud-based platform and utilizing the infrastructure services and embedded resources of the cloud-based platform (Fig. 10a-10c, col. 7, line 40-67, the server/cloud may provide services of Issuing Trust using one or more servers, storage, and/or applications, or using hosted services, or using Cloud services provided by a third party vendor; Fig. 10C illustrates plurality of ledgers as separate tenants to utilize cloud services for managing transactions), wherein each of the plurality of distributed ledgers are isolated from each other of the plurality of distributed ledgers, said isolation being provided at least in part by each set of containers on which each of the plurality of distributed ledgers are run (Fig. 10c, col. 16, line 6-25, col. 15, Wallet service identifies general ledger, authenticates itself and establish a secure and encrypted communication; sending coin ID via transaction structure; managing other ledger services and obtain information as to the owner of the coin for the Wallet Service application; Fig. 10C illustrates plurality of ledgers as separate tenants to utilize cloud services for managing transactions); the identity service providing authentication for each of the plurality of distributed ledgers (col. 15-16, Wallet service identifies general ledger, authenticates itself and establish a secure and encrypted communication; sending coin ID via transaction structure; managing other ledger services and obtain information as to the owner of the coin for the Wallet Service application).
It would have been obvious to one of ordinary skill in art before the effective filing date of the claim invention to include the cloud-based platform further comprising infrastructure services and embedded resources; a plurality of distributed ledgers, each of the plurality of distributed ledgers running on the cloud-based platform as a separate tenant of a plurality of tenants of the cloud-based platform and utilizing the infrastructure services and embedded resources of the cloud-based platform, wherein each of the plurality of distributed ledgers are isolated from each other of the plurality of distributed ledgers, said isolation being provided at least in part by each set of containers on which each of the plurality of distributed ledgers are run; the identity service providing authentication for each of the plurality of distributed ledgers into blockchain services of Nossik.
Motivation to do so would be to include the cloud-based platform further comprising infrastructure services and embedded resources; a plurality of distributed ledgers, each of the plurality of distributed ledgers running on the cloud-based platform as a separate tenant of a plurality of tenants of the cloud-based platform and utilizing the infrastructure services and embedded resources of the cloud-based platform, wherein each of the plurality of distributed ledgers are isolated from each other of the plurality of distributed ledgers, said isolation being provided at least in part by each set of containers on which each of the plurality of distributed ledgers are run; the identity service providing authentication for each of the plurality of distributed ledgers to securely and anonymously transfer digital coins from one wallet in computing device to another wallet in the same device or in another computing device (Ramanathan, col. 2, line 12-15).
Nossik as modified by Ramanathan do not explicitly disclose: an ordering container; a chaincode container.
Ramanathan teaches: an ordering container (Ramesh Nagappan, HyperLedger Fabric 1.0 section , 3rd numeric bullet, 1st line, container Peers- they are nodes that maintain the state and copy of a shared ledger; also see HyperLedger Fabric 1.0 section , 3rd numeric bullet, 2nd bullet point, Ordering Service Nodes (Orderers) - all transactions from the network are received by the orderer and it orders and groups them and then packages the transactions and creates blocks, the orderer service delivers blocks to the committing peers allowed to be part of a Channel, the orderer services do not review transaction information, the orderer makes guaranteed atomic delivery of blocks to committing peers on the channel, the orderer supports multiple channels using a publish/subscribe messaging system (based on Apache Kafka and Zookeeper);
a chaincode container (Ramesh Nagappan teaches chaincode (smart contract)- it holds state and ledger data by managing the lifecycle of transactions representing the business logic, rules, and policies executed within a transaction as agreed to by the participating member of a HyperLedger Fabric network, Chaincode defines endorsement policy and instantiates them and assign which peers need to endorse the transactions, page 2, 2nd paragraph, line 1-4).
It would have been obvious to one of ordinary skill in art before the effective filing date of the claim invention to include an ordering container; a chaincode container into blockchain services of Nossik.
Motivation to do so would be to include an ordering container; a chaincode container to significantly reduce the risks of privacy and confidentiality breaches in sharing information and trusted business process collaboration without intermediaries (Ramesh Nagappan, first page, 2nd paragraph, line 9-10).
Regarding claim 2, Nossik as modified by Ramanathan and Ramesh Nagappan teach all claimed limitations as set forth in rejection of claim 1, further teach wherein each of the plurality of distributed ledger is respectively associated with different blockchain ledger (Nossik, Fig. 2 and 4 illustrates plurality of distributed ledger associated with different blockchain ledger).
Regarding claim 3, Nossik as modified by Ramanathan and Ramesh Nagappan teach all claimed limitations as set forth in rejection of claim 2, further teach wherein each peer container respectively maintains the blockchain ledger associated with the distributed ledger of the associated peer container (Nossik, Fig. 1-2, col. 2, line 33-44 and line 65, col. 4, line 38-44, col. 5, line 34-50, col. 6, line 25-35, the cloud comprise respectively ledger nodes, the first ledger nodes and additional ledger nodes collectively maintain the blockchain distributed ledger on a peer-to-peer basis; a plurality of distinct ledger systems, each comprising a corresponding blockchain distributed ledger maintained collectively by an associated plurality of clouds, each of the blockchain distributed ledger and ledger nodes of its respective clouds collectively provide a distinct ledger system).
Regarding claim 4, Nossik as modified by Ramanathan and Ramesh Nagappan teach all claimed limitations as set forth in rejection of claim 3, further teach wherein each chaincode container respectively enables assets to be written to the blockchain ledger associated with the distributed ledger of the associated chaincode container (Ramesh Nagappan, HyperLedger Fabric 1.0 section , 3rd numeric bullet, 2nd bullet point, Ordering Service Nodes (Orderers) - all transactions from the network are received by the orderer and it orders and groups them and then packages the transactions and creates blocks, the orderer service delivers blocks to the committing peers allowed to be part of a Channel, the orderer services do not review transaction information, the orderer makes guaranteed atomic delivery of blocks to committing peers on the channel, the orderer supports multiple channels using a publish/subscribe messaging system (based on Apache Kafka and Zookeeper), the ordered provides a practical Byzantine Fault tolerance for failures without a single-point of failure); and wherein the chaincode container is started by the peer container and communicates with the peer container to perform encoding of transactions in the respective blockchain ledger (Ramesh Nagappan teaches chaincode (smart contracts)-it holds state and ledger data by managing the lifecycle of transactions representing the business logic, rules, and policies executed within a transaction as agreed to by the participating member of a HyperLedger Fabric network, Chaincode defines endorsement policy and instantiates them and assign which peers need to endorse the transactions, page 2, 2nd paragraph, line 1-4; also see HyperLedger Fabric 1.0 section , 3rd numeric bullet, 1st bullet point , the endorsing Peers (Endorsers) – the endorsing peers take up the role of endorsing transactions before it is ordered and committed as per the policy defined in Chaincode, the client application creating the transaction and sends it to endorsing peers as per the policy in chaincode, the endorsement policy is instantiated at the chaincode of the client application and forwarded to the endorsing peers, the endorsing peer evaluates and validates the transaction and produces an endorsement signature and then returns it to the application, there may be one or more pre-specified set of endorsing peers involved as per the endorsement policy, the transaction is evaluated and declared valid only if it has been endorsed by the endorsing peers as per policy; also see HyperLedger Fabric 1.0 section , 3rd numeric bullet, 1st bullet point, the Committing Peers (Committers) – They receive blocks from Orderer service, which already endorsed by the endorsing peers. The Committing peers ultimately commit the transactional state by adding the blocks to the ledger. Before committal, the peers validate or invalidate the transaction by verifying if the endorsement policies are met, authenticate the signatures and also verify the version info).
Regarding claim 5, Nossik as modified by Ramanathan and Ramesh Nagappan teach all claimed limitations as set forth in rejection of claim 4, further teach wherein each ordering container respectively order transactions on the blockchain ledger associated with the distributed ledger of the associated ordering container (Ramesh Nagappan, HyperLedger Fabric 1.0 section , 3rd numeric bullet, 2nd bullet point, Ordering Service Nodes (Orderers) - all transactions from the network are received by the orderer and it orders and groups them and then packages the transactions and creates blocks, the orderer service delivers blocks to the committing peers allowed to be part of a Channel, the orderer services do not review transaction information, the orderer makes guaranteed atomic delivery of blocks to committing peers on the channel, the orderer supports multiple channels using a publish/subscribe messaging system (based on Apache Kafka and Zookeeper).
Regarding claim 6, Nossik as modified by Ramanathan and Ramesh Nagappan teach all claimed limitations as set forth in rejection of claim 4, further teach wherein each chaincode container is started by an associated peer container (Ramesh Nagappan teaches chaincode (smart contract)- it holds state and ledger data by managing the lifecycle of transactions representing the business logic, rules, and policies executed within a transaction as agreed to by the participating member of a HyperLedger Fabric network, Chaincode defines endorsement policy and instantiates them and assign which peers need to endorse the transactions, page 2, 2nd paragraph, line 1-4)
As per claims 8 and 15, these claims are rejected on grounds corresponding to the rationales given above for rejected claim 1 and are similarly rejected.
As per claims 9-13, these claims are rejected on grounds corresponding to the rationales given above for rejected claims 2-6 respectively and are similarly rejected.
As per claims 16-20, these claims are rejected on grounds corresponding to the rationales given above for rejected claims 2-6 respectively and are similarly rejected.
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Nossik et al. (U.S. Patent No. 11,128,437 B1) in view of Ramanathan et al. (U.S. Patent No. 10,262,321 B1) and Ramesh Nagappan (“Unpacking HyperLedger Fabric 1.0 – Under the hood of a Permissioned Blockchain”; dated: July 07, 2017; http://websecuritypatterns.com/blogs/2017/07/07/unpacking-hyperledger-fabric-1-0-under-the-hood-of-a-permissioned-blockchain/, further in view of Chen et al. (U.S. Pub. No. 2018/0343111 A1).
Regarding claim 7, Nossik as modified by Ramanathan and Ramesh Nagappan teach all claimed limitations as set forth in rejection of claim 1, but do not explicitly disclose a front end load balancer associated with each of the plurality of distributed ledgers; and wherein an incoming call to a distributed ledger of the plurality of distributed ledgers is passed through the associated front end load balancer.
Chen teaches:
a front end load balancer associated with each of the plurality of distributed ledgers (paragraph [0015], paragraph [0016], paragraph [0028]-[0029], load balancer performs load balancing service that operate in conjunction with PaaS [platform as service] system to support distributed ledger, which is equivalent to wherein the at least one instance of the container runtime service is associated with a front end load balancer);
and wherein an incoming call to a distributed ledger of the plurality of distributed ledgers is passed through the associated front end load balancer (paragraph [0033]-[0037], receiving block data from client for data propagation that go through load balancer for determining how blocks being processed, which is equivalent to wherein the incoming call, prior to being received at the at least one instance of the deployed container runtime service, is passed through the front end load balancer).
It would have been obvious to one of ordinary skill in art before the effective filing date of the claim invention to include a front end load balancer associated with each of the plurality of distributed ledgers; and wherein an incoming call to a distributed ledger of the plurality of distributed ledgers is passed through the associated front end load balancer into blockchain cloud service of Nossik.
Motivation to do so would be to include a front end load balancer associated with each of the plurality of distributed ledgers; and wherein an incoming call to a distributed ledger of the plurality of distributed ledgers is passed through the associated front end load balancer to address issue with geographically dispersed nodes can lead to inefficiencies that may adversely affect network bandwidth and severely impact system performance (Chen, paragraph [0014], line 11-13).
As per claim 14, this claim is rejected on grounds corresponding to the rationales given above for rejected claim 7 and are similarly rejected.
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 KEN HOANG whose telephone number is (571)272-8401. The examiner can normally be reached M-F 7:30am-5: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, Charles Rones can be reached at (571)272-4085. 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.
/KEN HOANG/Examiner, Art Unit 2168
/CHARLES RONES/Supervisory Patent Examiner, Art Unit 2168