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 .
Response to Arguments
Applicant's arguments filed 11/25/2025 have been fully considered but they are not persuasive.
Regarding applicant’s argument for 103, applicant argues on page 12-17 “For the reasons set forth herein below, the Applicant respectfully addresses the claim rejections based on the amendments made, as proposed in the amended claim set appended herein. Independent Claims 16 and 22 Amended claim 16 recites a processor-based data processing arrangement configured to cluster the plurality of worker nodes into one or more clusters by processing model-update data using a homomorphic encryption algorithm. The claim further requires that this cluster-formation operation is performed prior to execution of a first model-training iteration. These limitations are central to the invention and distinguish the claims from the cited art” and “The additional references cited for the dependent claim [Singh for claims 18 and 24]; [Ambili for claims 20 and 26]; [Boneh for claims 21 and 27]; [Gazi for claim 28] do not remedy the deficiencies identified in the base combination of Manamohan, Padmanabhan, and Sattler. Therefore, for this reason and by virtue of their dependencies, withdrawal of the rejections of dependent claims 17-21 and 23-28 under 35 U.S.C. § 103 is respectfully requested” The applicant argues amended limitations for independent claims. Further applicant also argues that the cited prior art for dependent claims does not remedy the deficiency of prior art cited for independent claims. However the applicant argues the amended limitations for independent claims and the amended limitations have not been examined rendering the argument moot and not convincing.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier.
Such claim limitation(s) is/are:
“a processor-based data processing arrangement” in claim 16, 17, 20, and 21.
The limitation is interpreted as beaning performed by a processor as stated in the specification in page 14 line 3-14 “The distributed computer system comprises a data processing arrangement. Notably, the data processing arrangement is communicably coupled to the plurality of worker nodes in the distributed computer system. Herein, the data processing arrangement is operable to (namely configured to) track operation of each of the worker nodes. Furthermore, the data processing arrangement may include, but is not limited to, a microprocessor, a microcontroller, a complex instruction set computing (CISC) microprocessor, a reduced instruction set (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, an artificial intelligence (AI) computing engine based on hierarchical networks of variable-state machines, or any other type of processing circuit.”
“wherein the at least one secondary distributed ledger is configured to implement execute” in claim 16 and 19.
The limitation is interpreted as being performed by a worker node as recited in Page 4 line 15, “at least one secondary distributed ledger for coordinating collective learning of the worker nodes configured to implement at least one computer protocol for the collective learning of the worker nodes wherein the worker nodes of a given cluster are configured to train at least one computing model using information comprised in the distributed ledger;” and Page 10 line 1-13 “The worker nodes include computing arrangements that are operable to respond to, and processes instructions and data therein. The computing arrangements may include, but are not limited to, a microprocessor, a microcontroller, a complex instruction set computing (CISC) microprocessor, a reduced instruction set (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, an artificial intelligence (AI) computing engine based on hierarchical networks of variable-state machines, or any other type of processing circuit. Furthermore, the computing arrangements can be one or more individual processors, processing devices and various elements associated with a processing device that may be shared by other processing devices. Additionally, the computing arrangements are arranged in various architectures for responding to and processing the instructions that drive the system.”
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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.
Claim(s) 16, 19, 22, 25, and 29 are rejected under 35 U.S.C. 103 as being unpatentable over Manamohan et al. (US11218293B2) (“Manamohan”) in view of Padmanabhan (US20190236598A1) (“Padmanabhan”).
Regarding claim 16 and analogous claim 22, Manamohan teaches A distributed computer system to enable training of at least one computing model, the system comprises: a plurality of worker nodes that are coupled together via a data communication network to exchange data therebetween (Manamohan FIG.1A,
PNG
media_image1.png
685
444
media_image1.png
Greyscale
Col 2 55-62, Distributed ML can refer to ML model building across multiple nodes using data locally available to each of the nodes. The local model parameters learned from each local model can be merged to derive a global model, where the resulting global model can be redistributed to all the nodes for another iteration, i.e., localized data trains the global model. This can be repeated until the desired level of accuracy with the global model is achieved [A distributed computer system to enable training of at least one computing model].
Col 6 35-57, FIG. 1A illustrates an example of a system 100 of decentralized management of device assets outside a computer network 102, according to an implementation of the invention. System 100 may include a blockchain network 110. The blockchain network 110 may include a plurality of nodes that are connected to one another using one or more connection protocols, including a peer-to-peer connection protocol. The nodes of the blockchain network 110 may include a management node 12 and edge nodes 10. The particular number of, configuration of, and connections between the edge nodes 10 may vary. As such, the arrangement of the edge nodes 10 shown in FIG. 1A is for illustrative purposes only.
The management node 12 is part of and operates within a firewall 106 of computer network 102 and the edge nodes 10 operate outside the firewall. As alluded to above, and as will be described in greater detail below, such edge nodes 10 may contribute data that can be used to train a local instance of a global ML model in a swarm learning context. The computer network 102 may also include one or more backup systems 104 that provides failover protection for the management node 12 and/or other components 108 operating within the computer network. The components of the computer network 102 may communicate with one another via a local area network ("LAN") [the system comprises: a plurality of worker nodes that are coupled together via a data communication network to exchange data therebetween]),
wherein the plurality of worker nodes includes computing arrangements and local databases to process and store data therein;
PNG
media_image2.png
463
320
media_image2.png
Greyscale
Col 9 line 41-46, The edges nodes 10 may communicate with one another in
a peer-to-peer manner [wherein the plurality of worker nodes]. The edge nodes 10 may each include one or more processors 50 (also interchangeably referred to herein as processors 50, processor(s) 50, or processor 50 for convenience), one or more storage devices 70, and/or other 45 components.
Col 11 line 21-24, The storage devices 70 may store an edge node's copy of the distributed ledger 42, the edge node's copy of smart contracts 44, the edge node's public key 72, the edge node's
private key 74, and/or other data) [includes computing arrangements and local databases to process and store data therein;])
a distributed ledger arrangement for coordinating the system (Manamohan Col 9 line 1-12, The storage devices 40 may store a distributed ledger 42, smart contracts 44, node keys 46, and/or other data. The distributed ledger 42 may include a series of blocks of data that reference at least another block, such as a previous block. In this manner, the blocks of data may be chained together [a distributed ledger arrangement]. An example of a distributed ledger is described in the well-known white paper "Bitcoin: A Peer-to-Peer Electronic Cash System," by Satoshi Nakamoto (bitcoin.org), the contents of which are incorporated by reference in its entirety herein. The distributed ledger 42 may store blocks 10 that indicate a state of an edge node 10 relating to its configuration or other management information [for coordinating the system]);
a processor-based data processing arrangement configured to cluster the plurality of worker nodes into one or more cluster by processing model-update data using a homomorphic encryption algorithm (Manamohan Fig. 2A,
PNG
media_image3.png
753
624
media_image3.png
Greyscale
FIG. 2B illustrates an example swarm learning architecture 220. This swarm learning architecture 220 may include local ML models 222A-222N at each node (ML models 1, 2, . . . N). These local ML models 222A-222N may be maintained and trained at nodes making up the swarm. FIGS. 4A-4F illustrate example operations that can be performed to effectuate swarm learning using homomorphic encryption to protect parameter data in accordance with one embodiment of the disclosed technology.
Col 16 4-13, As alluded to above, various embodiments are directed to preventing any participant/node in the swarm learning network from gaining access to all of the parameter data in plaintext, or all of the shared secrets at any point in the parameter merging process, ensuring that even a merge leader cannot decrypt incoming parameter data. Further, the asymmetric keys will be generated by a key manager (external to the swarm learning network). The key manager is not part of the swarm learning "core" architecture (but rather a service relied upon to implement swarm learning).
Col 16 27-59 Referring to FIG. 4A, the swarm learning process may, in one embodiment, begin with the election of a merge leader when a quorum of nodes (nodes 400-1 to 400-n in the swarm network, which can be an embodiment of blockchain network 110, are ready merge their parameters. As illustrated in FIG. 4A, each of nodes 400-1, 400-2 ... , 400-n perform an enroll operation resulting in each of nodes 400-1, 400-2 ... , 400-n being registered in ledger 420, which may be an participant embodiment of ledger 42 or ledger 238 discussed above. It should be understood that the smart contracts 44, described above, may encode rules for enrolling a node for participation in a swarm learning network, e.g., an embodiment of credentials and/or other enrollment prerequisites. The blockchain network 110. The rules may specify required credentials may impose permissions on which nodes are allowed to participate. For example, the blockchain network 110 may be configured as a private blockchain where only authorized nodes are permitted to participate in an iteration. Moreover, any authorization information and expected credentials may be encoded within the smart contracts 44 or other stored information available to nodes on the blockchain network 110. Once a node has been enrolled, the blockchain network 110 may record an identity of the node and its state so that an identification of all nodes is known. Such recordation may be made via an entry in the distributed ledger 420. As such, the distributed ledger 420 may record a topology of the nodes and a state of the nodes, and this may continue through the parameter merging process as will be described further below. [to enable cluster formation using encrypted data]);
wherein the system is further configured perform cluster-formation operation by processing the model-update data from the plurality of worker nodes using the homomorphic encryption algorithm prior to execution of a first model-training iteration to provide compatible computing models to each of the one or more clusters (Manamohan Col 14 line 35-44, FIG. 2B illustrates an example swarm learning architecture 220. This swarm learning architecture 220 may include local ML models 222A-222N at each node (ML models 1, 2,. . . N). These local ML models 222A-222N may be maintained and trained at nodes making up the swarm learning network, e.g., edge nodes 10, described above that make up blockchain network 110. The swarm learning architecture 220 may also include a swarm learning component 224 which may include an API layer 226, a control layer 228, a data layer 230, and a monetization layer 232.
Col 14 line 57-67, It can be deployed within and across data centers, and has built-in support for a fault-tolerant network, where nodes can exit and reenter the swarm learning network dynamically without derailing or stalling the model building process. In other words, blockchain platform 234 is used as an infrastructure component for implementing a swarm learning ledger ( or blackboard) which encompasses the decentralized control logic for ML model building, HE key sharing, and parameter sharing logic. Edge nodes 10 (where ML models 222A, 222B ... , 222N are trained) may themselves have all the infrastructure components and control logic used for controlling/managing swarm learning [wherein the system is further configured perform cluster-formation operation by processing the model-update data from the plurality of worker nodes].
Col 15 line 46-53, As noted above, homomorphic encryption can be the basis for swarm learning in accordance with various embodiments. FIG. 3 illustrates an example of homomorphic encryption. Homomorphic Encryption (HE) can refer to a subset of techniques to implement a trusted computing environment by allowing particular computations to be executed on ciphertexts, obtain an encrypted result that is the ciphertext of the result of operations performed on the plaintext.
Col 16 line 14-26, The key manager can be an enterprise grade key manager that generates and serves public/private keys from a fault tolerant and physical secure environment. For example, a key manager may be specialized and hardened hardware/software co-designed applications. As noted above, the key manager releases only the public key to the merge leader to be published to participants for encrypting their local parameter data, and parameter merging is performed homomorphically. Decryption of merged parameters can be executed by an elected decryptor node that is not the merge leader. This decryptor node can request a private key from the key manager to decrypt the merged parameters and supply it to the merge leader for distribution.
Col 16 line 27-43, FIGS. 4A-4F illustrate example operations that can be performed to effectuate swarm learning using homomorphic encryption to protect parameter data in accordance with one embodiment of the disclosed technology. Referring to FIG. 4A, the swarm learning process may, in one embodiment, begin with the election of a merge leader when a quorum of nodes (nodes 400-1 to 400-n in the swarm network, which can be an embodiment of blockchain network 110, are ready merge their parameters. As illustrated in FIG. 4A, each of nodes 400-1, 400-2 ... , 400-n perform an enroll operation resulting in each of nodes 400-1, 400-2 ... , 400-n being registered in ledger 420, which may be an embodiment of ledger 42 or ledger 238 discussed above. It should be understood that the smart contracts 44, described above, may encode rules for enrolling a node for participation in a swarm learning network, e.g., an embodiment of blockchain network 110).
Col 18 It should be understood that the above-described phase ensures full protection of the local, node-specific parameters prior to them being merged. Also, by distributing the compute-intensive encryption process to each of the participating nodes, scaling bottlenecks are avoided. Furthermore, the algorithm ensures complete data privacy as none of the nodes including the merge leader will ever have parameters from another peer in plaintext [using the homomorphic encryption algorithm prior to execution of a first model-training iteration to provide compatible computing models to each of the one or more clusters]).
Manamohan does not explicitly teach plurality of worker nodes,
wherein the at least one secondary distributed ledger is configured to execute at least one computer protocol for the collective learning of the plurality of worker nodes to train the at least one computing model
wherein the plurality of worker nodes of a given cluster are configured update the at least one computing model using model-update data information comprised in the at least one secondary distributed ledger,
However Padmanabhan teaches the at least one secondary distributed ledger for coordinating collective learning of the plurality of worker nodes,
wherein the at least one secondary distributed ledger is configured to execute at least one computer protocol for the collective learning of the plurality of worker nodes to train the at least one computing model (Padmanabhan Para 0055, In certain embodiments, a client-server computing architecture may be utilized to supplement features, functionality, or computing resources for the database system130 or alternatively, a computing grid, or a pool of work servers, or some combination of hosted computing architectures may provide some or all of computational workload and processing demanded of the host organization 110 in conjunction with the database system 130.
Para 0413, FIG. 16C depicts another exemplary architecture 1602, with additional detail of a permissioned blockchain 1640 which implements machine learning models for smart contracts using distributed ledger technologies in a cloud based computing environment, in accordance with described embodiments.
Para 421 line 6 -15, In such an embodiment, each of the multiple distinct customer organizations may contribute historical data to the machine learning platform 1605, which is then utilized by the machine learning platform to inform the machine learning model. In such a way, the machine learning platform 1605 utilizes the historical data from the participating nodes 1650 in the permissioned blockchain network 1640 to train the neural network which generates the machine learning model for use with execution of a specified smart contract [wherein the at least one secondary distributed ledger is configured to execute at least one computer protocol for the collective learning of the plurality of worker nodes to train the at least one computing model].
Para 0422, The generated machine learning model may be stored by the host organization 110, or stored within the permissioned blockchain network itself, for instance, within each of the participating nodes 1650, or stored within an IPFS, or stored within another queryable data source, such as a database system 130 within the host organization 110 or stored within a queryable source external from the host organization 110. For instance, the generated machine learning model may be stored within a private sidechain of the permissioned blockchain 1640 which only the participating nodes 1650A and 1650B with access to restricted data and restricted functions are permitted to access, thus, participating nodes 1650C of the permissioned blockchain without access to the sidechain cannot access the generated machine learning model [the at least one secondary distributed ledger for coordinating collective learning of the plurality of worker nodes]),
wherein the plurality of worker nodes of a given cluster are configured update the at least one computing model using model-update data information comprised in the at least one secondary distributed ledger (Padmanabhan
Para 0046 line 1-16, According to another embodiment, there is a system having at least a processor and a memory therein executing within a host organization and having therein: means for operating a blockchain interface to a blockchain on behalf of a plurality of tenants of the host organization, in which each one of the plurality of tenants operate as a participating node with access to the blockchain; receiving historical data from each of the participating nodes on the blockchain, in which the historical data represents historical smart contract transactions on the blockchain for customers of the plurality of tenants and further in which each of the participating nodes provides different historical data; generating a new machine learning model at the host organization by inputting the historical data received from the participating nodes into a neural network of a machine learning platform operating at the host organization;
Para 0421, As depicted here, the machine learning platform 1605 of the host organization 110 may interact with different participating nodes 1650 of the permissioned blockchain 1640 via the permissioned ledger bridge 1610, such as a node representing each one of a collection of different customer organizations. In such an embodiment, each of the multiple distinct customer organizations may contribute historical data to the machine learning platform 1605, which is then utilized by the machine learning platform to inform the machine learning model. In such a way, the machine learning platform 1605 utilizes the historical data from the participating nodes 1650 in the permissioned blockchain network 1640 to train the neural network which generates the machine learning model for use with execution of a specified smart contract [wherein the plurality of worker nodes of a given cluster are configured update the at least one computing model].
Para 0422, For instance, the generated machine learning model may be stored within a private sidechain of the permissioned blockchain 1640 which only the participating nodes 1650A and 1650B with access to restricted data and restricted functions are permitted to access, thus, participating nodes 1650C of the permissioned blockchain without access to the sidechain cannot access the generated machine learning model),
Para 423, According to certain embodiments, once the machine learning model is generated, it is then distributed to each of the participating nodes 1650 of the permissioned blockchain network 1640 which possess sufficient access to the restricted functions and the restricted data of the permissioned blockchain network, such as participating nodes 1650A and 1650B which operate within the permissioned ledger 1661 of the blockchain network, separate from previously depicted participating node 1650C which lacks access to the restricted functions and restricted data [using model-update data information comprised in the at least one secondary distributed ledger]),
Manamohan and Padmanabhan are considered to be analogous to the claim invention because they are in the same field of distributed machine learning. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filling date of the claimed invention to have modified Manamohan in view of Padmanabhan to a secondary distributed ledger or sidechain. Doing so to allow validation services of data on data between blockchain and sidechains (Padmanabhan Para 0112 line 1-12, With a symmetric two-way pegged sidechain transfer, both the parent blockchain 188 and sidechains 189 may perform SPY validation services of data on each other, especially where the parent blockchain 188 is provided the host organization and where the sidechain is a foreign sidechain
for which the host organization is merely a participating node via the sidechain exchange manager node
193. Because the parent blockchain 188 clients (e.g., participating nodes) do not observe every
sidechain, users import proofs of work from the sidechain into the parent chain in order to prove possession. In a symmetric two-way peg, the reverse is also true).
Regarding claim 19 and analogous claim 25, Manamohan in view of Padmanabhan teach the distributed computer system of claim 16
Manamohan and Padmanabhan are combine in the same rational as set forth above with respect to claim 16 and analogous claim 22.
Padmanabhan further teaches wherein each of the secondary distributed ledgers is configured to store cryptographically signed records pertaining to the respective computing model, worker nodes associated therewith, and a contribution of each of the worker nodes in their respective cluster in relation to training the respective computing model (Padmanabhan Para 0045, According to another embodiment, there is a distributed ledger technology platform host, having at least a processor and a memory therein, in which the platform host is to receive a collaborative document or portion thereof from a collaborative document processing application, create a blockchain asset comprising the collaborative document or portion thereof, create a blockchain transaction comprising the blockchain asset and a blockchain asset identifier associated with a first collaborator that signed the collaborative document, broadcast the blockchain transaction into circulation on a blockchain, receive validation of the blockchain transaction, responsive to broadcasting the blockchain transaction in the blockchain, and commit the validated blockchain transaction in a block to the blockchain.
Para 0422, The generated machine learning model may be stored by the host organization 110, or stored within the permissioned blockchain network itself, for instance, within each of the participating nodes 1650, or stored within an IPFS, or stored within another queryable data source [worker nodes associated therewith], such as a database system 130 within the host organization 110 or stored within a queryable source external from the host organization 110. For instance, the generated machine learning model may be stored within a private sidechain [, wherein each of the secondary distributed ledgers is configured to store information cryptographically signed records pertaining to the respective computing model] of the permissioned blockchain 1640 which only the participating nodes 1650A and 1650B with access to restricted data and restricted functions are permitted to access, thus, participating nodes 1650C of the permissioned blockchain without access to the sidechain cannot access the generated machine learning model (i.e. the sidechain contains the contributions of all the nodes in relation to training the respective computing model).
Regarding claim 29, Manamohan in view of Padmanabhan teach the distributed computer system of claim 16
Manamohan teaches wherein the homomorphic encryption algorithm comprises encrypting model-update data vectors generated by the worker nodes to enable cluster formation using encrypted data (Manamohan Fig. 2A,
PNG
media_image3.png
753
624
media_image3.png
Greyscale
FIG. 2B illustrates an example swarm learning architecture 220. This swarm learning architecture 220 may include local ML models 222A-222N at each node (ML models 1, 2, . . . N). These local ML models 222A-222N may be maintained and trained at nodes making up the swarm. FIGS. 4A-4F illustrate example operations that can be performed to effectuate swarm learning using homomorphic encryption to protect parameter data in accordance with one embodiment of the disclosed technology.
Col 16 4-13, As alluded to above, various embodiments are directed to preventing any participant/node in the swarm learning network from gaining access to all of the parameter data in plaintext, or all of the shared secrets at any point in the parameter merging process, ensuring that even a merge leader cannot decrypt incoming parameter data. Further, the asymmetric keys will be generated by a key manager (external to the swarm learning network). The key manager is not part of the swarm learning "core" architecture (but rather a service relied upon to implement swarm learning).
Col 16 27-59 Referring to FIG. 4A, the swarm learning process may, in one embodiment, begin with the election of a merge leader when a quorum of nodes (nodes 400-1 to 400-n in the swarm network, which can be an embodiment of blockchain network 110, are ready merge their parameters. As illustrated in FIG. 4A, each of nodes 400-1, 400-2 ... , 400-n perform an enroll operation resulting in each of nodes 400-1, 400-2 ... , 400-n being registered in ledger 420, which may be an participant embodiment of ledger 42 or ledger 238 discussed above. It should be understood that the smart contracts 44, described above, may encode rules for enrolling a node for participation in a swarm learning network, e.g., an embodiment of credentials and/or other enrollment prerequisites. The blockchain network 110. The rules may specify required required credentials may impose permissions on which nodes are allowed to participate. For example, the blockchain network 110 may be configured as a private blockchain where only authorized nodes are permitted to participate in an iteration. Moreover, any authorization information and expected credentials may be encoded within the smart contracts 44 or other stored information available to nodes on the blockchain network 110. Once a node has been enrolled, the blockchain network 110 may record an identity of the node and its state so that an identification of all nodes is known. Such recordation may be made via an entry in the distributed ledger 420. As such, the distributed ledger 420 may record a topology of the nodes and a state of the nodes, and this may continue through the parameter merging process as will be described further below. [to enable cluster formation using encrypted data].
Col 16 60-66, As further illustrated in FIG. 4A, each of nodes 400-1, 400-2 ... , 400-n can train instances of a common, global model using local data present/contributed by each of the nodes. As noted above, parameters, e.g., weights, can be derived pursuant to the training of the model using local data, and these parameters may then be persisted in their encrypted state or format [wherein the homomorphic encryption algorithm comprises encrypting model-update data vectors generated by the worker nodes]. (Examiner Note: The system allows clustering by only allowing nodes that are allowed to participate in the swarm learning. Swarm learning is implemented by using Homomorphic encryption.).
Claim(s) 17 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Manamohan in view of Padmanabhan and further in view of Felix Sattler, Klaus-Robert Müller, Wojciech Samek, Clustered Federated Learning: Model-Agnostic Distributed Multi-Task Optimization under Privacy Constraints (2019) (“Sattler”).
Regarding claim 17 and analogous claim 23, Manamohan in view of Padmanabhan teach the distributed computer system of claim 16
Manamohan and Padmanabhan are combine in the same rational as set forth above with respect to claim 16 and analogous claim 22.
Manamohan does not explicitly teach wherein the data processing arrangement is configured to cluster the plurality of worker nodes into one or more clusters based on estimated generalization performance of a shared classifier on a task associated with the worker nodes.
Sattler further teaches wherein the data processing arrangement is configured to cluster the plurality of worker nodes into one or more clusters based on estimated generalization performance of a shared classifier on a task associated with the worker nodes (Settler Page 10,
PNG
media_image4.png
196
498
media_image4.png
Greyscale
Fig. 8: CFL applied to the "permuted labels problem" on CIFAR with 20 clients and 4 different permutations [wherein the data processing arrangement]. The top plot shows the accuracy of the trained model(s) on their corresponding validation sets. The bottom plot shows the separation gaps g(α) for all different clusters. After an initial 50 communication rounds a large separation gap has developed and a first split separates out the purple group of clients, which leads to an immediate drastic increase of accuracy for these clients. In communication rounds 100 and 150 this step is repeated until all clients with incongruent distributions have been separated. After the third split, the model accuracy for all clients has more than doubled and the separation gaps in all clusters have dropped to below zero which indicates that the clustering is finalized [configured to cluster the plurality of worker nodes into one or more clusters.
Page 10 C. Clustered Federated Learning Para 1,
In this section, we apply CFL as described in Algorithm 5 to different Federated Learning setups, which are inspired by our motivating examples in the introduction. In all experiments, the clients perform 3 epochs of local training at a batch-size of 100 in every communication round. Label permutation on Cifar-10: We split the CIFAR-10 training data randomly and evenly among m = 20 clients, which we group into k = 4 different clusters. All clients belonging to the same cluster apply the same random permutation Pc(i) to their labels such that their modified training and test data is given by The clients then jointly train a 5-layer convolutional neural network on the modified data using CFL with 3 epochs of local training at a batch-size of 100. Figure 8 (top) shows the joint training progression: In the first 50 communication rounds, all clients train one single model together, following the conventional Federated Learning protocol. After these initial 50 rounds, training has converged to a stationary point of the Federated Learning objective and the client test accuracies stagnate at around 20% [based on estimated generalization performance of a shared classifier]. Conventional Federated Learning would be finalized at this point
Page 11 Fig. 9: CFL applied to the Ag-News problem. The top plot shows the perplexity achieved by the different clients on their local test set (lower is better). The clients are separated in communication rounds 30, 60 and 90. After the final separation the perplexity of all clients on their local test set has dropped to less than 36, while the Federated Learning solution (black, dotted) still stagnates at a perplexity of 42 [on a task associated with the worker nodes]).
Manamohan and Sattler are considered to be analogous to the claim invention because they are in the same field of distributed machine learning. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filling date of the claimed invention to have modified Manamohan in view of Sattler to incorporate clustered nodes into one or more cluster. Doing so to increase accuracy of Federated Learning Model (Sattler Page 10 C. Clustered Federated Learning Para 2 line 28-36, At this point the accuracy of all clients has more than doubled the one achieved by the Federated Learning solution and is now at close to 60% 4 . This underlines, that after standard FL, our novel CFL can detect, the necessity for subsequent splitting and clustering which enables arriving at significantly higher performance. In addition, the cluster structure found can potentially be illuminating as it provides interesting insight about the composition of the complex underlying data distribution.)
Claim(s) 18 and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Manamohan in view of Padmanabhan and further in view of Amritraj Singh, Kelly Click, Reza M. Parizi, Qi Zhang, Ali Dehghantanha, Kim-Kwang Raymond Choo, Sidechain technologies in blockchain networks: An examination and state-of-the-art review, Journal of Network and Computer Applications, Volume 149, 2020, 102471, ISSN 1084-8045 (2019) (“Singh”).
Regarding claim 18 and analogous claim 24,Manamohan in view of Padmanabhan teach the distributed computer system of claim 16.
Manamohan and Padmanabhan are combine in the same rational as set forth above with respect to claim 16 and analogous claim 22.
Manamohan does not explicitly teach wherein the system is configured to initiate the secondary distributed ledger by employing at least one of: staking of tokens in the distributed ledger, smart contract, off-chain contractual agreements.
However Singh teaches wherein the system is configured to initiate the secondary distributed ledger by employing at least one of: staking of tokens in the distributed ledger, smart contract, off-chain contractual agreements (Singh Page 4, 2.2.2 Multi-signature or federated two-way pegs
An improvement over centralized two-way pegs are the federated two-way pegs (Backet al., 2014), (Dilley et al., 2016). In such a design, a group of entities or notaries control the lock-box rather than just one central entity. Consequently, the entire federation or group collectively holds custody of the locked funds and regulates fund transfer between the primary blockchain and its sidechain. The fund transfer takes place only when the majority of the entities i.e. ‘n’ out of ‘m’ entities (where ‘n’ is the majority and ‘m’ is the total number of entities in the federation) within the federation sign the transaction (Deng et al., 2018). Fig. 3 demonstrates the sequential steps with which fund transfer takes place between the two blockchains using a federated two-way peg [staking of tokens in the distributed ledger].
Page 4,
PNG
media_image5.png
533
922
media_image5.png
Greyscale
).
Manamohan and Singh are considered to be analogous to the claim invention because they are in the same field of blockchains. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filling date of the claimed invention to have modified Manamohan in view of Singh to incorporate staking tokens in the distributed ledger. Doing so to improve upon centralized two way peg design and faster funds transfer between blockchains (Singh Page 5 2.2.2 Multi-signature or federated two-way pegs Advantages of federated two-way pegs: The advantages of using a federated two-way peg design are: 1) It improves upon centralized two way peg design by improving the political decentralization of such multi blockchain systems to some extent and 2) These designs could be implemented with specialized federation protocols for fast transfer of funds between the blockchains. Some of these protocols are Strong Federations (Dilley et al., 2016) (which is discussed further in Section 3.3 B).).
Claim(s) 20 and 26 are rejected under 35 U.S.C. 103 as being unpatentable over Manamohan in view of Padmanabhan and further in view of Ambili, K. N., M. Sindhu, and M. Sethumadhavan. "On Federated and Proof Of Validation Based Consensus Algorithms In Blockchain." IOP Conference Series. Materials Science and Engineering. Vol. 225. No. 1. IOP Publishing, 2017 (“Ambili”).
Regarding claim 20 and analogous claim 26, Manamohan in view of Padmanabhan teach the distributed computer system of claim 16.
Manamohan and Padmanabhan are combine in the same rational as set forth above with respect to claim 16 and analogous claim 22.
Manamohan does not explicitly teach wherein the data processing arrangement is configured to validate a given block in the distributed ledger arrangement when the given block is referenced by a block that has been notarized by a majority of the plurality of worker nodes.
However Ambili teaches wherein the data processing arrangement is configured to validate a given block in the distributed ledger arrangement when the given block is referenced by a block that has been notarized by a majority of the plurality of worker nodes (Ambili Page 5, 3.2 Tendermint Protocol, Tendermint [8, 19] tries to achieve consensus by taking account of stake of validators. It avoids the “nothing at stake” problem wherein validators have nothing to lose even if they misbehave over the network by using proper penalizing techniques. It relays new information by gossip. The algorithm was initially based on DLS protocol [2] though there have been attempts to modify it. Every participating node keeps a complete copy of sequence of transactions in blocks included in blockchain. Each user keeps an account in the system and it is identified by users’ public key or address. Each account can hold sum of coins. These may change with new transactions. Nodes relay new transactions which were signed and submitted by users to a node of the network. Special users with accounts that have coins locked in a bond deposit by posting a bond transaction are the validators of the system. The voting power of a validator is equal to the amount of bonded coin his account holds. The voting power of a validator reduces only when its coins are unlocked later by unbonding transaction. A set of validators with at least two-third of total voting power have the power to confirm a block. A block is said to be committed when a two-third majority of validators send commit votes for it. It is called “polka”. A fork is identified in the blockchain, when two blocks at the same height are each signed by two-third majority of validators [when the given block is referenced by a block that has been ]. So a fork can happen only when one-third majority of validators signs in duplicate. A short evidence transaction can be generated by anyone who gets two conflicting commit vote signatures. The guilty validator gets punished when this is committed into the blockchain and it destroys their bonded coins. Validators participate in consensus process by signing votes for blocks. There are three types of votes - Prevote, Precommit and Commit. A block is said to be committed by the network when a two-third majority of validators commit it (signed and broadcast commits) [wherein the data processing arrangement is configured to validate a given block in the distributed ledger arrangement]. The block creation at a particular height is determined using round robin protocol. Each round has three steps -Propose, Prevote and Precommit and two special steps - Commit and NewHeight).
Manamohan and Ambili are considered to be analogous to the claim invention because they are in the same field of blockchains. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filling date of the claimed invention to have modified Manamohan in view of Ambili to incorporate validating blocks with majority voting. Doing so to ensure that only signed and validated blocks are committed to the blockchain when majority of validators agree (Ambili Page 6, For commit, two parallel conditions are to be satisfied. Node must receive the block committed by the network if it had not received already. Once a block is received, it signs and broadcasts a commit for that block. Secondly, node must wait until it receives at least two-third of commits for the block precommitted by the network. Then CommitTime is set to current time and transitions to NewHeight. In effect, blocks are added when two-third majority of validators agree. Cosmos has been designed to facilitate inter blockchain communication. Cosmos hub lies at its core and interacts with participating blockchains using cosmos hub).
Claim(s) 21 and 27 are rejected under 35 U.S.C. 103 as being unpatentable over Manamohan in view of Padmanabhan and further in view of Boneh, Dan, et al. "Verifiable delay functions." Annual international cryptology conference. Cham: Springer International Publishing, 2018 (“Boneh”).
Regarding claim 21 and analogous claim 27, Manamohan in view of Padmanabhan teach the distributed computer system of claim 16.
Manamohan and Padmanabhan are combine in the same rational as set forth above with respect to claim 16 and analogous claim 22.
Manamohan does not explicitly teach wherein the method comprises employing verifiable delay functions to space a timing of block production according to a priority of each worker node within a given cluster.
However Boneh teaches wherein the data processing arrangement is configured to employ verifiable delay functions to space a timing of block production according to a priority of each worker node within a given cluster (Boneh Page 4, Randomness beacons. VDFs are useful for constructing randomness beacons from sources such as stock prices [24] or proof-of-work blockchains (e.g. Bitcoin, Ethereum) [17, 63, 12]. Proofof- work blockchains include randomly sampled solutions to computational puzzles that network participants (called miners) continually find and publish for monetary rewards. Underpinning the security of proof-of-work blockchains is the strong belief that these solutions have high computational min-entropy. However, similar to potential manipulation of asset prices by high frequency traders, powerful miners could potentially manipulate the beacon result by refusing to post blocks which produce an unfavorable beacon output [according to a priority of each worker node within a given cluster].
Again, this attack is only feasible if the beacon can be computed quickly, as each block is fixed to a specific predecessor and will become “stale” if not published. If a VDF with a suitably long delay is used to compute the beacon, miners will not be able to determine the beacon output from a given block before it becomes stale [wherein the data processing arrangement is configured to employ verifiable delay functions to space a timing of block production]. More specifically, given the desired delay parameter t, the public parameters pp = (ek, vk) ←R Setup(λ, t) are posted on the blockchain, then given a block b the beacon value is determined to be r where (r, π) = Eval(ek, b), and anyone can verify correctness by running Verify(vk, b, r, π). The security of this construction, and in particular the length of delay parameter which would be sufficient to prevent attacks, remains an informal conjecture due to the lack of a complete game-theoretic model capturing miner incentives in Nakamoto-style consensus protocols. We refer the reader to [17, 63, 12] for proposed models for blockchain manipulation. Note that most formal models for Nakamoto-style consensus such as that of Garay et al. [36] do not capture miners with external incentives such as profiting from lottery manipulation.).
Manamohan and Boneh are considered to be analogous to the claim invention because they are in the same field of blockchains. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filling date of the claimed invention to have modified Manamohan in view of Boneh to incorporate verifiable delay functions to delay block production. Doing so to make it infeasible for an adversary to distinguish function’s output and delay an adversary (Boneh Page 1 1 Introduction Para 1 line 5-8 and para 2-3, Stock prices are believed to be difficult to predict for a passive observer, but an active adversary could manipulate prices to bias the lottery. For example, a high-frequency trader might slightly alter the closing price of a stock by executing (or not executing) a few transactions immediately before the market closes.
Suppose the extractor takes only a single bit per asset (e.g. whether the stock finished up or down for the day) and suppose the adversary is capable of changing this bit for k different assets using last-second trades. The attacker could read the prices of the assets it cannot control, 2k quickly simulate potential lottery outcomes based on different combinations of the k outcomes it can control, and then manipulate the market to ensure its preferred lottery outcome occurs.
One solution is to add a delay function after extraction, making it slow to compute the beacon outcome from an input of raw stock prices. With a delay function of say, one hour, by the time the adversary simulates the outcome of any potential manipulation strategy, the market will be closed and prices finalized, making it too late to launch an attack. This suggests the key security property for a delay function: it should be infeasible for an adversary to distinguish the function’s output from random in less than a specified amount of wall-clock time, even given a potentially large number of parallel processors.).
Claim 28 is rejected under 35 U.S.C. 103 as being unpatentable over Manamohan in view of Padmanabhan and further in view of P. Gaži, A. Kiayias and D. Zindros, "Proof-of-Stake Sidechains," 2019 IEEE Symposium on Security and Privacy (SP), San Francisco, CA, USA, 2019, pp. 139-156, (“Gazi”).
Regarding claim 28, Manamohan in view of Padmanabhan teach the distributed computer system of claim 22.
Manamohan and Padmanabhan are combine in the same rational as set forth above with respect to claim 16 and analogous claim 22.
Manamohan does not explicitly teach further comprising checking finality of each chain and relaying the information between the chains.
However Gazi teaches further comprising checking finality of the distributed ledger arrangement and the at least one secondary distributed ledger distributed ledger arrangement and the at least one secondary distributed ledger (Page 145 IV. Implementing Pegged Ledgers, The main challenge in implementing pegged ledgers is to facilitate secure cross-chain transfers. We consider two approaches to such transfers and refer to them as direct observation or cross-chain certification [checking finality of the distributed ledger arrangement and the at least one secondary distributed ledger]. Consider two pegged ledgers L1 and L2. Direct observation of L1 means that every node of L2 follows and validates L1; it is easy to see that this enables transfers from L1 to L2. On the other hand, crosschain certification of L2 means that L1 contains appropriate cryptographic information sufficient to validate data issued by the nodes following L2. This allows transfers of assets from L2, as long as they are certified, to be accepted by L1-nodes without following L2. The choice between direct observation and cross-chain certification can be made independently for each direction of transfers between L1 and L2, any of the 4 variants is possible (cf. Figure 1 [and relaying the information between the distributed ledger arrangement and the at least one secondary distributed ledger]).
Manamohan and Gazi are considered to be analogous to the claim invention because they are in the same field of blockchains. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filling date of the claimed invention to have modified Manamohan in view of Gazi to incorporate validating between chains. Doing so to allow assets to be moved between sidechains securely (Gazi Page 1 Abstract line 1-12 Abstract—Sidechains have long been heralded as the key enabler of blockchain scalability and interoperability. However, no modeling of the concept or a provably secure construction has so far been attempted.
We provide the first formal definition of what a sidechain system is and how assets can be moved between sidechains securely. We put forth a security definition that augments the known transaction ledger properties of liveness and safety to hold across multiple ledgers and enhance them with a new “firewall” security property which safeguards each blockchain from its sidechains, limiting the impact of an otherwise catastrophic sidechain failure ).
Pertinent Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Bhowmic et al. (US20190370334A1) - teaches using homographic encryption to protect data during sequence learning.
Carpov et al. (US20190334708A1) teaches learning on encrypted data that uses homomorphic encryption.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALFREDO CAMPOS whose telephone number is (571)272-4504. The examiner can normally be reached 7:00 - 4:00 pm M - F.
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, Michael J. Huntley can be reached at (303) 297-4307. 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.
/ALFREDO CAMPOS/Examiner, Art Unit 2129
/MICHAEL J HUNTLEY/Supervisory Patent Examiner, Art Unit 2129