1
DETAILED ACTION
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. This communication is in response to the Applicant’s submission filed 28 December 2023, where:
Claims 1-25 are pending.
Claims 1-25 are rejected.
Information Disclosure Statement
3. Information disclosure statements were submitted on 28 December 2023 and 30 July 2025. The submissions comply with the provisions of 37 CFR 1.97. Accordingly, the Examiner considered the information disclosure statements.
Specification
4. The use of the terms JAVA, SMALLTALK, C++, (Specification ¶ 0028), and Kubemetes, (Specification ¶ 0047), which are trade names or marks used in commerce, has been noted in this application. The term should be accompanied by the generic terminology; furthermore the term should be capitalized wherever it appears or, where appropriate, include a proper symbol indicating use in commerce such as ™, SM , or ® following the term.
Although the use of trade names and marks used in commerce (i.e., trademarks, service marks, certification marks, and collective marks) are permissible in patent applications, the proprietary nature of the marks should be respected and every effort made to prevent their use in any manner which might adversely affect their validity as commercial marks.
Claim Objections
5. Claims 7, 14, and 20 are objected to because of the following informalities:
Claim 7, line 5, claim 14, line 4, and claim 20, line 2, each recite “a plurality of IoT devices.” The first occurrence in the respective claim of the acronym “IoT” needs to be expanded.
Appropriate correction is required.
Claim Rejections - 35 U.S.C. § 101
6. 35 U.S.C. § 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
7. Claims 14-19 are rejected under 35 U.S.C. § 101 because the broadest reasonable interpretation of the term "at least one computer readable storage medium” covers both statutory and non-statutory embodiments, which are not eligible for patent protection, and therefore the claims are directed to non-statutory subject matter. See In re Nuijten, 500 F.3d 1346, 84 USPQ2d 1495 (Fed. Cir. 2007).
The plain meaning of a “computer readable storage medium” encompasses signals. The specification recites:
the method 350 is implemented in one or more modules as a set of logic instructions stored in a machine- or computer-readable storage medium such as random access memory (RAM), read only memory (ROM), programmable ROM (PROM), firmware, flash memory, etc., in configurable logic such as, for example, programmable logic arrays (PLAs), field programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), in fixed-functionality logic hardware using circuit technology such as, for example, application specific integrated circuit (ASIC), complementary metal oxide semiconductor (CMOS) or transistor-transistor logic (TTL) technology, or any combination thereof.”
(Specification ¶ 0027; see also Specification ¶ 0031). The specification does not rebut the presumption that the term be given its plain meaning because the terms “computer-readable storage medium” and “machine-readable signal medium” both encompass non-statutory subject matter. While the specification provides “specific examples” of storage, they are merely examples rather than a definition of two distinct species or embodiments that would rebut the presumption. Although the machine- and computer-readable storage mediums include statutory embodiments, nothing in the specification specifically excludes signals per se from falling within computer readable storage media.
Examiner suggests Applicant amend the claims to exclude transitory computer-readable devices in order to narrow the broadest reasonable interpretation of those claims to embodiments that fall within a statutory category.
8. Claims 1-25 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more.
Claim 1 recites a “computing system,” which is a machine, and thus one of the statutory categories of patentable subject matter. (35 U.S.C. § 101).
However, under Step 2A Prong One, the claim recites the limitations of “[(a)]1 identify a model update that is to originate from the plurality of IoT devices,” and “[(b)] determine votes from the plurality of IoT devices.” These activities of “[(a)] identify a model update,” and “[(b)] determine votes” contain limitations that can practically be performed in the human mind, including, for example, observations, evaluations, judgments, and opinions, and accordingly, are a mental process, (MPEP § 2106.04(a)(2) sub III), which is one of the groupings of abstract ideas. (MPEP § 2106.04(a)(2)).
The claim also recites more details or specifics to the abstract idea of [(b)] determine votes,” “[(b.1)] wherein the votes indicate whether the model update is to be deployed,” and accordingly, is merely more specific to the abstract idea. Thus, claim 1 recites an abstract idea.
Under Step 2A Prong Two, the claim as a whole is not integrated into a practical application, because the additional elements recited in the claim beyond the identified judicial exception include a “network controller,” a “processor,” a “memory coupled to the processor, the memory including a set of executable program instructions, which when executed by the processor, cause,” are recited at a high-level of generality, and accordingly, are generic computer components used to implement the abstract idea, (MPEP § 2106.05(f)), that do not serve to integrate the abstract idea into a practical application. Also, instructions to apply the abstract idea on generic computer components (i.e. the computer readable storage medium) do not represent a practical application of the abstract idea. (MPEP § 2106.05(f)). Still further, the claim recites “a plurality of internet-of-things (IoT) devices,” which is generally linking the abstract idea to a field of use (that is, specifying the intended use of model updates to IoT devices) that does not serve to integrate the abstract idea into a practical application. (MPEP § 2106.05(h)).
The claim also recites “[(c)] deploy the model update to the plurality of IoT devices based on the votes,” which is a post-processing insignificant extra-solution activity that includes transmitting an update over a network, (MPEP § 2106.05(g)), that does not amount to significantly more than the abstract idea. Therefore, claim 1 is directed to the abstract idea.
Finally, under Step 2B, the additional elements, taken alone or in combination, do not represent significantly more than the abstract idea itself. the additional elements recited in the claim beyond the identified judicial exception include a “network controller,” a “processor,” a “memory coupled to the processor, the memory including a set of executable program instructions, which when executed by the processor, cause,” are recited at a high-level of generality, and accordingly, are generic computer components used to implement the abstract idea, (MPEP § 2106.05(f)), that do not amount to significantly more than the abstract idea. Also, instructions to apply the abstract idea on generic computer components (i.e. the computer readable storage medium) do not amount to significantly more than the abstract idea. (MPEP § 2106.05(f)). Still further, the claim recites “a plurality of internet-of-things (IoT) devices,” which is generally linking the abstract idea to a field of use (that is, specifying the intended use of model updates to IoT devices) that does not amount to significantly more than the abstract idea. (MPEP § 2106.05(h)).
The claim also recites “[(c)] deploy the model update to the plurality of IoT devices based on the votes,” which is a well-understood, routine, and conventional activity that includes transmitting an update over a network, (MPEP § 2106.05(d) sub II.i), that does not amount to significantly more than the abstract idea. Therefore, claim 1 is subject-matter ineligible.
Claim 7 recites a “semiconductor apparatus,” which is a product, and thus one of the statutory categories of patentable subject matter. (35 U.S.C. § 101).
However, under Step 2A Prong One, the claim recites the limitations of “[(a)] identify a model update that is to originate from the plurality of IoT devices,” and “[(b)] determine votes from the plurality of IoT devices.” These activities of “[(a)] identify a model update,” and “[(b)] determine votes” contain limitations that can practically be performed in the human mind, including, for example, observations, evaluations, judgments, and opinions, and accordingly, are a mental process, (MPEP § 2106.04(a)(2) sub III), which is one of the groupings of abstract ideas. (MPEP § 2106.04(a)(2)).
The claim also recites more details or specifics to the abstract idea of [(b)] determine votes,” “[(b.1)] wherein the votes indicate whether the model update is to be deployed,” and accordingly, is merely more specific to the abstract idea. Thus, claim 7 recites an abstract idea.
Under Step 2A Prong Two, the claim as a whole is not integrated into a practical application, because the additional elements recited in the claim beyond the identified judicial exception include a “one or more substrates,” “logic coupled to the one or more substrates, wherein the logic is implemented in one or more of configurable or fixed-functionality hardware,” are recited at a high-level of generality, and accordingly, are generic computer components used to implement the abstract idea, (MPEP § 2106.05(f)), that do not serve to integrate the abstract idea into a practical application. Still further, the claim recites “a plurality of IoT devices,” which is generally linking the abstract idea to a field of use (that is, specifying the intended use of model updates to IoT devices) that does not serve to integrate the abstract idea into a practical application. (MPEP § 2106.05(h)).
The claim also recites “[(c)] deploy the model update to the plurality of IoT devices based on the votes,” which is a post-processing insignificant extra-solution activity that includes transmitting an update over a network, (MPEP § 2106.05(g)), that does not amount to significantly more than the abstract idea. Therefore, claim 7 is directed to the abstract idea.
Finally, under Step 2B, the additional elements, taken alone or in combination, do not represent significantly more than the abstract idea itself. the additional elements recited in the claim beyond the identified judicial exception include “one or more substrates,” “logic coupled to the one or more substrates, wherein the logic is implemented in one or more of configurable or fixed-functionality hardware,” are recited at a high-level of generality, and accordingly, are generic computer components used to implement the abstract idea, (MPEP § 2106.05(f)), that do not amount to significantly more than the abstract idea. Still further, the claim recites “a plurality of IoT devices,” which is generally linking the abstract idea to a field of use (that is, specifying the intended use of model updates to IoT devices) that does not amount to significantly more than the abstract idea. (MPEP § 2106.05(h)).
The claim also recites “[(c)] deploy the model update to the plurality of IoT devices based on the votes,” which is a well-understood, routine, and conventional activity that includes transmitting an update over a network, (MPEP § 2106.05(d) sub II.i), that does not amount to significantly more than the abstract idea. Therefore, claim 7 is subject-matter ineligible.
Claim 14 recites “at least one computer readable storage medium,” which is not one of the statutory categories of patentable subject matter, (35 U.S.C. § 101), because “at least one computer readable storage medium” covers both statutory and non-statutory embodiments, which are not eligible for patent protection, and therefore the claims are directed to non-statutory subject matter. For the limited purposes of examination, however, the claim is considered as complying with one of the statutory categories of patentable subject matter.
Under Step 2A Prong One, the claim recites the limitations of “[(a)] identify a model update that is to originate from the plurality of IoT devices,” and “[(b)] determine votes from the plurality of IoT devices.” These activities of “[(a)] identify a model update,” and “[(b)] determine votes” contain limitations that can practically be performed in the human mind, including, for example, observations, evaluations, judgments, and opinions, and accordingly, are a mental process, (MPEP § 2106.04(a)(2) sub III), which is one of the groupings of abstract ideas. (MPEP § 2106.04(a)(2)).
The claim also recites more details or specifics to the abstract idea of [(b)] determine votes,” “[(b.1)] wherein the votes indicate whether the model update is to be deployed,” and accordingly, is merely more specific to the abstract idea. Thus, claim 14 recites an abstract idea.
Under Step 2A Prong Two, the claim as a whole is not integrated into a practical application, because the additional elements recited in the claim beyond the identified judicial exception include “at least one computer readable storage medium comprising a set of executable program instructions, which when executed by a computing system,” are recited at a high-level of generality, and accordingly, are generic computer components used to implement the abstract idea, (MPEP § 2106.05(f)), that do not serve to integrate the abstract idea into a practical application. Also, instructions to apply the abstract idea on generic computer components (i.e. the computer readable storage medium) do not represent a practical application of the abstract idea. (MPEP § 2106.05(f)). Still further, the claim recites “a plurality of IoT devices,” which is generally linking the abstract idea to a field of use (that is, specifying the intended use of model updates to IoT devices) that does not serve to integrate the abstract idea into a practical application. (MPEP § 2106.05(h)).
The claim also recites “[(c)] deploy the model update to the plurality of IoT devices based on the votes,” which is a post-processing insignificant extra-solution activity that includes transmitting an update over a network, (MPEP § 2106.05(g)), that does not amount to significantly more than the abstract idea. Therefore, claim 14 is directed to the abstract idea.
Finally, under Step 2B, the additional elements, taken alone or in combination, do not represent significantly more than the abstract idea itself. the additional elements recited in the claim beyond the identified judicial exception include “at least one computer readable storage medium comprising a set of executable program instructions, which when executed by a computing system,” are recited at a high-level of generality, and accordingly, are generic computer components used to implement the abstract idea, (MPEP § 2106.05(f)), that do not amount to significantly more than the abstract idea. Also, instructions to apply the abstract idea on generic computer components (i.e. the computer readable storage medium) do not amount to significantly more than the abstract idea. (MPEP § 2106.05(f)). Still further, the claim recites “a plurality of IoT devices,” which is generally linking the abstract idea to a field of use (that is, specifying the intended use of model updates to IoT devices) that does not amount to significantly more than the abstract idea. (MPEP § 2106.05(h)).
The claim also recites “[(c)] deploy the model update to the plurality of IoT devices based on the votes,” which is a well-understood, routine, and conventional activity that includes transmitting an update over a network, (MPEP § 2106.05(d) sub II.i), that does not amount to significantly more than the abstract idea. Therefore, claim 14 is subject-matter ineligible.
Claim 20 recites a “method,” which is a process, and thus one of the statutory categories of patentable subject matter. (35 U.S.C. § 101).
However, under Step 2A Prong One, the claim recites the limitations of “[(a)]identify a model update that is to originate from the plurality of IoT devices,” and “[(b)] determine votes from the plurality of IoT devices.” These activities of “[(a)] identify a model update,” and “[(b)] determine votes” contain limitations that can practically be performed in the human mind, including, for example, observations, evaluations, judgments, and opinions, and accordingly, are a mental process, (MPEP § 2106.04(a)(2) sub III), which is one of the groupings of abstract ideas. (MPEP § 2106.04(a)(2)).
The claim also recites more details or specifics to the abstract idea of [(b)] determine votes,” “[(b.1)] wherein the votes indicate whether the model update is to be deployed,” and accordingly, is merely more specific to the abstract idea. Thus, claim 20 recites an abstract idea.
Under Step 2A Prong Two, the claim as a whole is not integrated into a practical application, because the additional elements recited in the claim beyond the identified judicial exception “a plurality of IoT devices,” which is generally linking the abstract idea to a field of use (that is, specifying the intended use of model updates to IoT devices) that does not serve to integrate the abstract idea into a practical application. (MPEP § 2106.05(h)).
The claim also recites “[(c)] deploy the model update to the plurality of IoT devices based on the votes,” which is a post-processing insignificant extra-solution activity that includes transmitting an update over a network, (MPEP § 2106.05(g)), that does not amount to significantly more than the abstract idea. Therefore, claim 20 is directed to the abstract idea.
Finally, under Step 2B, the additional elements, taken alone or in combination, do not represent significantly more than the abstract idea itself. the additional elements recited in the claim beyond the identified judicial exception include “a plurality of IoT devices,” which is generally linking the abstract idea to a field of use (that is, specifying the intended use of model updates to IoT devices) that does not amount to significantly more than the abstract idea. (MPEP § 2106.05(h)).
The claim also recites “[(c)] deploy the model update to the plurality of IoT devices based on the votes,” which is a well-understood, routine, and conventional activity that includes transmitting an update over a network, (MPEP § 2106.05(d) sub II.i), that does not amount to significantly more than the abstract idea. Therefore, claim 20 is subject-matter ineligible.
Claim 2 depends directly or indirectly from claim 1. Claim 8 depends directly or indirectly from claim 7. Claim 15 depends directly or indirectly from claim 14. Claim 21 depends directly or indirectly from claim 20. The claims further recite “[(d)] identify weight parameters for the plurality of IoT devices,” and “[(e)] determine the votes based on a product of the weight parameters and outcomes of tests associated with the model update.” The activities of “[(d)] identify weight parameters,” and “[(e)] determine the votes” contain limitations that can practically be performed in the human mind, including, for example, observations, evaluations, judgments, and opinions, and accordingly, are a mental process, (MPEP § 2106.04(a)(2) sub III), which is one of the groupings of abstract ideas. (MPEP § 2106.04(a)(2)).
The claims also recite more details or specifics to the abstract idea of “[(d)] identify weight parameters,” “[(d.1)] wherein the weight parameters are associated with local errors that are correctable by the model update for a respective IoT device of the plurality of IoT devices,” and “[(d.2)] potential new errors for the respective IoT device that are caused by the model update,” and accordingly, are merely more specific to the abstract idea. The additional elements of the claim does not serve to integrate the abstract idea into integrated into a practical application, (see MPEP § 2106.04(d)), nor do the additional elements amount to significantly more than the abstract idea, (MPEP § 2106.05 sub I; see also MPEP § 2106.05(a) – (h)), and thus, the claim recites no more than the abstract idea. Therefore, claims 2, 8, 15, and 21 are subject-matter ineligible.
Claim 3 depends directly or indirectly from claim 1. Claim 9 depends directly or indirectly from claim 7. Claim 16 depends directly or indirectly from claim 14. Claim 22 depends directly or indirectly from claim 20. The claims further recite “[(d)] locally generate the model update in a respective IoT device of the plurality of IoT devices in response to an error being identified by the respective IoT device.” The activity of “[(d)] locally generate the model update” contain limitations that can practically be performed in the human mind, including, for example, observations, evaluations, judgments, and opinions, and accordingly, are a mental process, (MPEP § 2106.04(a)(2) sub III), which is one of the groupings of abstract ideas. (MPEP § 2106.04(a)(2)). Also, the activity of “[(d)] locally generate the model update” implements mathematical operations to the weights, and accordingly, is also a mathematical concept, (MPEP § 2106.04(a)(2) sub I; see also Specification ¶ 0040). The additional elements of the claim does not serve to integrate the abstract idea into integrated into a practical application, (see MPEP § 2106.04(d)), nor do the additional elements amount to significantly more than the abstract idea, (MPEP § 2106.05 sub I; see also MPEP § 2106.05(a) – (h)), and thus, the claim recites no more than the abstract idea. Therefore, claims 3, 9, 16, and 22 are subject-matter ineligible.
Claim 4 depends directly or indirectly from claim 1. Claim 10 depends directly or indirectly from claim 7. Claim 17 depends directly or indirectly from claim 14. Claim 23 depends directly or indirectly from claim 20. The claims further recite “[(d)] repeatedly readjust the model update until the model update rectifies an error prior to deployment of the model update to the plurality of IoT devices.” Under Step 2A Prong Two, the activity of “[(d)] repeatedly adjust” is the insignificant extra-solution activity of “repeating,” (MPEP § 2106.05(f)), that does not serve to integrate the abstract idea into a practical application. Also, under Step 2B, the activity of “[(d)] repeatedly adjust” is the well-understood, routine, and conventional activity of performing repetitive calculations, (MPEP § 2106.05(d) sub II.ii), that does not amount to significantly more than the abstract idea. Therefore, claims 4, 10, 17, and 23 are subject-matter ineligible.
Claim 5 depends directly or indirectly from claim 1. Claim 11 depends directly or indirectly from claim 7. Claim 18 depends directly or indirectly from claim 14. Claim 24 depends directly or indirectly from claim 20. The claims further recite “[(d)] broadcast the model update and a voting ledger to the plurality of IoT devices, wherein the voting ledger is to store the votes.” Under Step 2A Prong Two, the activity of “[(d)] broadcast” is a post-processing insignificant extra-solution activity of transmitting a result of the abstract idea, (MPEP § 2106.05(f)), that does not serve to integrate the abstract idea into a practical application. Under Step 2B, the activity of “[(d)] broadcast” is a well-understood, routine, and conventional activity of transmitting data over a network, (MPEP § 2106.05(d) sub II.i), that does not amount to significantly more than the abstract idea. Therefore, claims 5, 11, 18, and 24 are subject-matter ineligible.
Claim 6 depends directly or indirectly from claim 1. Claim 12 depends directly or indirectly from claim 7. Claim 19 depends directly or indirectly from claim 14. Claim 25 depends directly or indirectly from claim 20. The claims further recite “[(d)] generate a hash value of the model update,” which contains a limitation that can practically be performed in the human mind, including, for example, observations, evaluations, judgments, and opinions, and accordingly, are a mental process, (MPEP § 2106.04(a)(2) sub III), which is one of the groupings of abstract ideas. (MPEP § 2106.04(a)(2)).
Also, the claims further recite “[(e)] record the hash value and voting information associated with the votes to a blockchain,” which is a post-processing insignificant extra-solution activity of storing or gathering data, (MPEP § 2106.05(g)), that does not serve to integrate the abstract idea into a practical application. Also, the activity of “[(e)] record” is the well-understood, routine, and conventional activity of storing information in memory, (MPEP § 2106.05(d) sub II.iv), that does not amount to significantly more than the abstract idea. Therefore, claims 6, 12, 19, and 25 are subject-matter ineligible.
Claim 13 depends directly or indirectly from claim 7. The claim recites more details or specifics to the “logic,” “wherein the logic coupled to the one or more substrates includes transistor channel regions that are positioned within the one or more substrates,” and accordingly, is merely more specific to the additional element. Therefore, claim 13 is subject-matter ineligible.
Claim Rejections - 35 U.S.C. § 102
8. The following is a quotation of the appropriate paragraphs of 35 U.S.C. § 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
9. Claims 1, 6, 7, 12, 13, 14, 19, 20, and 25 are rejected under 35 U.S.C. § 102(a)(1) as being anticipated by US Published Application 20190332955 to Manahoman ‘955 et al. [hereinafter Manahoman ‘955].
Regarding claims 1, 14, and 20, Manahoman ‘955 teaches [a] computing system (Manahoman ‘955 ¶ 0028 teaches” a system 100 of decentralized model building in machine learning using blockchain [(that is, a computing system)]”) of claim 1, [a]t least one computer readable storage medium comprising a set of executable program instructions, which when executed by a computing system, cause the computing system (Manahoman ‘955, claim 17, teaches a “non-transitory machine-readable storage medium comprising instructions [(that is, set of executable program instructions)] executable by a processor of at least a first physical computing node of a blockchain network comprising a plurality of physical computing nodes”) of claim 14, and [a] method (Manahoman ‘955 ¶ 0020 teaches “the disclosed . . . methods”) of claim 20, comprising:
a network controller to communicate (Manahoman ‘955, Fig. 1, teaches a system 100 [Examiner annotations in dashed-line text boxes]:
PNG
media_image1.png
883
775
media_image1.png
Greyscale
Manahoman ‘955 ¶ 0037 teaches an “interface layer 26 may communicate with other nodes using blockchain [(that is, a network controller to communicate)] by, for example, broadcasting blockchain transactions and, for a master node elected as describe herein elsewhere, writing blocks to the distributed ledger 42 based on those transactions as well as based on the activities of the master node”) with a plurality of internet-of-things (IoT) devices (Manahoman ‘955 ¶ 0019 teaches “edge devices such as "Internet of Things" (or "IoT") devices in various context such as consumer electronics, appliances, drones, and others are increasingly equipped with computational and network capacity”);
a processor coupled to the network controller (Manahoman ‘955 ¶ 0029 & Fig. 1 teaches ”[n]ode 10 may include . . . one or more processors 20 [(that is, a processor coupled to the network controller)]”); and
a memory coupled to the processor (Manahoman ‘955 ¶ 0029 teaches “[n]ode 10a may include . . . one or more storage devices 40 [(that is, a memory)]”), the memory including a set of executable program instructions, which when executed by the processor (Manahoman ‘955 ¶ 0092 teaches the “storage device [40] may store the computer program instructions (e.g., the aforementioned instructions) to be executed by processor 20 as well as data that may be manipulated by processor 20 [(that is, the memory including a set of executable program instructions, which when executed by the processor)]”), cause the computing system to:
[(a)] identify a model update that is to originate from the plurality of IoT devices (Manahoman ‘955 ¶ 0004 teaches “[e]ach participant node [(that is, IoT device)] may generate a blockchain transaction comprising an indication that the participant node is ready to share the first training parameter [(that is, “indication” is identify a model update)], and may transmit or otherwise provide the first training parameter to a master node.[(that is, identify a model update that is to originate from the plurality of IoT devices)]”);
[(b)] determine votes from the plurality of IoT devices (Manahoman ‘955 ¶ 0019 teaches “a blockchain network can refer to a network where nodes use, e.g., a consensus mechanism to update a blockchain this is distributed across multiple parties”),
[(b.1)] wherein the votes indicate whether the model update is to be deployed (Manahoman ‘955 ¶ 0022 teaches” [w]hen some or all of the participant nodes are ready to share its respective training parameters, a master node (also referred to as “master computing node”) may write the indications [(that is, votes)] to a distributed ledger. The minimum number of participants nodes that are ready to share training parameters in order for the master node to write the indications may be defined by one or more rules, which may be encoded in a smart contract, as described herein [(that is, wherein the votes indicate whether the model update is to be deployed)]”); and
[(c)] deploy the model update to the plurality of IoT devices based on the votes (Manahoman ‘955 ¶ 0023 teaches “[t]he master node may broadcast an indication that it has completed generating the merged training parameters, such as by writing a blockchain transaction that indicates the state change. Such state change (in the form of a transaction) may be recorded as a block to the distributed ledger with such indication. The nodes may periodically monitor the distributed ledger to determine whether the master node has completed the merge, and if so, obtain the merged training parameters [(that is, deploy the model update to the plurality of IoT devices based on the votes)]”).
Regarding claim 7, Manahoman ‘955 teaches [a] semiconductor apparatus (Manahoman ‘955 ‘975 ¶ 0097 teaches that, “[a]s an alternative or in addition to retrieving and executing instructions, hardware processor 502 may include one or more electronic circuits that include electronic components for performing the functionality of one or more instructions, such as a field programmable gate array (FPGA), application specific integrated circuit (ASIC), or other electronic circuits [(that is, a “FPGA,” “ASIC” are a semiconductor apparatus)]) comprising:
one or more substrates; and
logic coupled to the one or more substrates, wherein the logic is implemented in one or more of configurable or fixed-functionality hardware (Manahoman ‘955 ¶ 0118 teaches “"component," "engine," "system," "database," data store," and the like, as used herein, can refer to logic embodied in hardware”), the logic to:
[(a)] identify a model update that is to originate from a plurality of IoT devices (Manahoman ‘955 ¶ 0004 teaches “[e]ach participant node [(that is, IoT device)] may generate a blockchain transaction comprising an indication that the participant node is ready to share the first training parameter [(that is, “indication” is identify a model update)], and may transmit or otherwise provide the first training parameter to a master node.[(that is, identify a model update that is to originate from the plurality of IoT devices)]”);
[(b)] determine votes from the plurality of IoT devices (Manahoman ‘955 ¶ 0019 teaches “a blockchain network can refer to a network where nodes use, e.g., a consensus mechanism to update a blockchain this is distributed across multiple parties”),
[(b.1)] wherein the votes indicate whether the model update is to be deployed (Manahoman ‘955 ¶ 0022 teaches” [w]hen some or all of the participant nodes are ready to share its respective training parameters, a master node (also referred to as “master computing node”) may write the indications [(that is, votes)] to a distributed ledger. The minimum number of participants nodes that are ready to share training parameters in order for the master node to write the indications may be defined by one or more rules, which may be encoded in a smart contract, as described herein [(that is, wherein the votes indicate whether the model update is to be deployed)]”); and
[(c)] deploy the model update to the plurality of IoT devices based on the votes (Manahoman ‘955 ¶ 0023 teaches “[t]he master node may broadcast an indication that it has completed generating the merged training parameters, such as by writing a blockchain transaction that indicates the state change. Such state change (in the form of a transaction) may be recorded as a block to the distributed ledger with such indication. The nodes may periodically monitor the distributed ledger to determine whether the master node has completed the merge, and if so, obtain the merged training parameters [(that is, deploy the model update to the plurality of IoT devices based on the votes)]”).
Examiner notes that the term "one or more substrates" recited in Applicant's claims is interpreted to be a well-known hardware structure of a semiconductor apparatus.
Regarding claims 6, 12, 19, and 25, Manahoman ‘955 teaches all of the limitations of claims 1, 7, 14, and 20, respectively, as described above in detail.
Manahoman ‘955 teaches -
[(d)] generate a hash value of the model update (Manahoman ‘955, Fig. 6, illustrates an example of a model building blockchain block 600 [Examiner annotations in dashed-line text blocks]:
PNG
media_image2.png
417
870
media_image2.png
Greyscale
Manahoman ‘955 teaches a “previous block hash 602 may include a value of a hash of a previous block. As such, the block 600 may be linked to another (previous) block in the distributed ledger 42. The proof information 604 may include, for example, a proof of stake or proof of work, depending on which type of blockchain is implemented [(that is, generate a hash value of the model update)]”); and
[(e)] record the hash value and voting information associated with the votes to a blockchain (Manahoman ‘955 ¶ 0084 teaches the “block 600 may include an identification of transactions 606 that are being written to the block 600 (which is added to the distributed ledger 42). The transaction data—and the block 600—may therefore be used to coordinate decentralized machine learning across nodes 10. This is because each node 10 may have a copy of the distributed ledger 42 and is able to monitor the progress of an iteration of machine learning [(that is, record the has value and voting information associated with the votes to a blockchain)]”).
Regarding claim 13, Manahoman ‘955 teaches all of the limitations of claim 7, as described above in detail.
Manahoman ‘955 teaches -
[(d)] wherein the logic coupled to the one or more substrates includes transistor channel regions that are positioned within the one or more substrates (Manahoman ‘955 ‘975 ¶ 0097 teaches “[a]s an alternative or in addition to retrieving and executing instructions, hardware processor 502 may include one or more electronic circuits that include electronic components for performing the functionality of one or more instructions, such as a field programmable gate array (FPGA), application specific integrated circuit (ASIC), or other electronic circuits [(that is, a “FPGA,” “ASIC” are a semiconductor apparatus)]).
Examiner notes that the term "one or more substrates includes transistor channel regions that are positioned within the one or more substrates" recited in Applicant's claims is interpreted to be a well-known hardware structure of a semiconductor apparatus, and further, is inherent to a “semiconductor apparatus“ such as a FPGA, ASIC, etc.
Claim Rejections – 35 U.S.C. § 103
10. 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.
11. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. § 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
12. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. § 102(b)(2)(C) for any potential 35 U.S.C. § 102(a)(2) prior art against the later invention.
13. Claims 2-5, 8-11, 15-18, and 21-24 are rejected under 35 U.S.C. § 103 as being unpatentable over US Published Application 20190332955 to Manahoman ‘955 et al. [hereinafter Manahoman ‘955] in view of US Published Application US Published Application 20210398017 to Garg et al. [hereinafter Garg].
Regarding claims 2, 8, 15, and 21, Manahoman ‘955 teaches all of the limitations of claims 1, 7, 14, and 20, respectively, as described above in detail.
Manahoman ‘955 teaches -
[(d)] identify weight parameters for the plurality of IoT devices (Manahoman ‘955 ¶ 0022 teaches “training data may include sensitive or otherwise private information that should not be shared with other nodes, but training parameters learned from such data through machine learning can be shared [(that is, in maintaining data privacy, “training parameters” are weight parameters)]”), . . . .
Though Manahoman ‘955 teaches weight parameters and training parameter convergence to correct a model, Manahoman ‘955, however, does not explicitly teach -
[(d) identify weight parameters for the plurality of IoT devices,
(d.1)] wherein the weight parameters are associated with local errors that are correctable by the model update for a respective IoT device of the plurality of IoT devices, and
[(d.2)] potential new errors for the respective IoT device that are caused by the model update; and
[(e)] determine the votes based on a product of the weight parameters and outcomes of tests associated with the model update.
But Garg teaches -
[(d) identify weight parameters for the plurality of IoT devices,
(d.1)] wherein the weight parameters (Garg ¶ 0027 teaches “each node possessing local training data trains a common ML model without sharing the local training data to any other node or entity in the swarm blockchain network. This is accomplished by sharing parameters (weights) derived from training the common ML model using the local training data [(that is, the weight parameters)]”) are associated with local errors that are correctable by the model update for a respective IoT device of the plurality of IoT devices (Garg ¶ 0025 teaches “a model can be evaluated on its performance accuracy by performing on data it has never seen, i.e., the validation dataset. The degree of error or loss resulting from this evaluation is referred to as validation loss [(that is, local errors)]”; Garg ¶ 0079 teaches “During each epoch, each node trains its local model using one or more data batches for some given number of iterations”; Garg ¶ 0101 teaches that, “[a]s would be understood by those of ordinary skill in the art, a ML model can be trained iteratively over multiple batches until it is satisfactorily trained or is no longer improving in its performance [(that is, “improving performance” is the weight parameters are associated with local errors that are correctable by the model update for a respective IoT device of the plurality of IoT devices)]”), and
[(d.2)] potential new errors for the respective IoT device that are caused by the model update (Garg ¶ 0106 teaches “As noted above, the application of a merged parameter can refer to overwriting parameters (weights) that were externally supplied, in this case, the final merge parameter (weight) overrides the local parameters at each of nodes 500-1, 500-2 . . . , 500-n [(that is, “overwriting parameters (weights)” is the model update)]”; post model update, Garg ¶ 0107 teaches “this parameter merging process can be repeated until the swarm learning network is able to converge the global model to a desired accuracy level. As part of determining whether the global model is able to achieve a desired accuracy level, the validation loss may be calculated. As alluded to above, validation may be performed locally, the local validation loss of each node can be shared, and an average of the local validation loss can be calculated to derive a global validation loss. This global validation loss may be shared with each node so that each node may determine how well its local model is performed/has been trained from a network or system-wide (global) perspective [(that is, the “validation loss” is potential new errors for the respective IoT device that are caused by the model update)]”); and
[(e)] determine the votes based on a product of the weight parameters (Garg ¶ 0111 teaches “[s]haring their respective validation loss values [(that is, such “sharing” is determine the votes based on a product of the weight parameters)] can be accomplished by node 500-1, the elected leader, by downloading the encrypted validation loss values from each of nodes 500-2 . . . , 500-n. Node 500-1 may then average the encrypted validation loss values from each of nodes 500-2 . . . , 500-n along with its own validation loss value to arrive at a global validation loss value”) and outcomes of tests associated with the model update (Garg ¶ 0107 teaches that, “[a]s part of determining whether the global model is able to achieve a desired accuracy level, the validation loss may be calculated. As alluded to above, validation may be performed locally, the local validation loss of each node can be shared, and an average of the local validation loss can be calculated to derive a global validation loss [(that is, “validation loss” is outcomes of tests associated with the model update)]”).
Manahoman ‘955 and Garg are from the same or similar field of endeavor. Manahoman ‘955 teaches decentralized machine learning where model builds are performed at nodes where local training datasets are generated. Garg teaches calculating validation loss in a distributed machine learning network where nodes train local instances maintained at the nodes.
Thus, it would have been obvious to a person having ordinary skill in the art as of the effective filing date of the Applicant’s invention to modify Manahoman ‘955 pertaining to decentralized machine learning with the decentralized validation loss of Garg.
The motivation to do so is because “[v]alidation loss can be an important aspect of ML for implementing training features. For example, validation loss can be used to avoid overfitting a model on training data by creating an early stopping criterion in which training is halted once the validation loss reaches a minimum value. As another example, validation loss can be used in an adaptive synchronization setting, where the length of a synchronization interval is modulated based on the progress of validation loss values across multiple iteration (i.e., modulating the synchronization frequency).” (Garg ¶ 0025).
Regarding claims 3, 9, 16, and 22, Manahoman ‘955 teaches all of the limitations of claims 1, 7, 14, and 20, respectively, as described above in detail.
Manahoman ‘955 teaches -
[(d)] locally generate the model update in a respective IoT device of the plurality of IoT devices (Manahoman ‘955 ¶ 0022 teaches “Each node enrolled to participate in an iteration (also referred to herein as a “participant node”) may train a local model using training data that is accessible locally at the node, but may not be accessible at other nodes) . . . .
Though Manahoman ‘955 teaches weight parameters and training parameter convergence to correct a model, Manahoman ‘955, however, does not explicitly teach –
[(d) locally generate the model update in a respective IoT device of the plurality of IoT devices] in response to an error being identified by the respective IoT device.
But Garg teaches -
[(d) locally generate the model update in a respective IoT device of the plurality of IoT devices] in response to an error being identified by the respective IoT device (Garg ¶ 0025 teaches the “degree of error or loss resulting from this evaluation is referred to as validation loss”; Garg ¶ 0026 teaches the “merged parameters are then applied to each local model at each of the participating nodes, and the updated local models are then evaluated using the previously identified validation dataset, and each participating node shares their respective/local validation loss value with the leader. The merge leader merges/averages the local validation loss values to arrive at a global validation loss value, which can then be shared with the rest of the nodes. In this way, a global validation loss value can be derived based on the universe of participating nodes, and that global validation loss value can be used by each of the participating nodes to determine if training can stop or if further training may be needed [(that is, the “degree of error or loss” is in response to an error being identified by the respective IoT device)]”).
Manahoman ‘955 and Garg are from the same or similar field of endeavor. Manahoman ‘955 teaches decentralized machine learning where model builds are performed at nodes where local training datasets are generated. Garg teaches calculating validation loss in a distributed machine learning network where nodes train local instances maintained at the nodes.
Thus, it would have been obvious to a person having ordinary skill in the art as of the effective filing date of the Applicant’s invention to modify Manahoman ‘955 pertaining to decentralized machine learning with the decentralized validation loss of Garg.
The motivation to do so is because “[v]alidation loss can be an important aspect of ML for implementing training features. For example, validation loss can be used to avoid overfitting a model on training data by creating an early stopping criterion in which training is halted once the validation loss reaches a minimum value. As another example, validation loss can be used in an adaptive synchronization setting, where the length of a synchronization interval is modulated based on the progress of validation loss values across multiple iteration (i.e., modulating the synchronization frequency).” (Garg ¶ 0025).
Regarding claims 4, 10, 17, and 23, Manahoman ‘955 teaches all of the limitations of claims 1, 7, 14, and 20, respectively, as described above in detail.
Manahoman ‘955 teaches -
[(d)] repeatedly readjust the model update until the model update rectifies an error prior to deployment of the model update to the plurality of IoT devices (Garg, Fig. 2A teaches a repeatedly adjusting a model update until a stopping criterion is reached [Examiner annotations in dashed-line text boxes]:
PNG
media_image3.png
818
660
media_image3.png
Greyscale
Garg ¶ 0025 teaches the “degree of error or loss resulting from this evaluation is referred to as validation loss”; Garg ¶ 0026 teaches the “merged parameters are then applied to each local model at each of the participating nodes, and the updated local models are then evaluated using the previously identified validation dataset, and each participating node shares their respective/local validation loss value with the leader. The merge leader merges/averages the local validation loss values to arrive at a global validation loss value, which can then be shared with the rest of the nodes. In this way, a global validation loss value can be derived based on the universe of participating nodes, and that global validation loss value can be used by each of the participating nodes to determine if training can stop or if further training may be needed”; Garg ¶ 0082 teaches “When it discovers that all merge participants have signaled completion, the merge leader merges the local validation metric numbers to calculate global metric numbers [(that is, the “stopping condition” is repeatedly readjust the model update until the model update rectifies an error prior to deployment of the model update to the plurality of IoT devices)]”).
Manahoman ‘955 and Garg are from the same or similar field of endeavor. Manahoman ‘955 teaches decentralized machine learning where model builds are performed at nodes where local training datasets are generated. Garg teaches calculating validation loss in a distributed machine learning network where nodes train local instances maintained at the nodes.
Thus, it would have been obvious to a person having ordinary skill in the art as of the effective filing date of the Applicant’s invention to modify Manahoman ‘955 pertaining to decentralized machine learning with the decentralized validation loss of Garg.
The motivation to do so is because “[v] alidation loss can be an important aspect of ML for implementing training features. For example, validation loss can be used to avoid overfitting a model on training data by creating an early stopping criterion in which training is halted once the validation loss reaches a minimum value. As another example, validation loss can be used in an adaptive synchronization setting, where the length of a synchronization interval is modulated based on the progress of validation loss values across multiple iteration (i.e., modulating the synchronization frequency).” (Garg ¶ 0025).
Regarding claims 5, 11, 18, and 24, Manahoman ‘955 teaches all of the limitations of claims 1, 7, 14, and 20, as described above in detail.
Manahoman ‘955 teaches -
[(d)] broadcast the model update and a voting ledger to the plurality of IoT devices, wherein the voting ledger is to store the votes (Manahoman ‘955 ¶ 0023 teaches a “master node may broadcast an indication that it has completed generating the merged training parameters, such as by writing a blockchain transaction that indicates the state change [(that is, broadcast the model update and a voting ledger)]; Manahoman ‘955 ¶ 0040 teaches “any participant node 10 (whether a master node or not), may use the consensus engine 210 to perform consensus decisioning such as whether to enroll a node to participate in an iteration of machine learning. In this way, a consensus regarding certain decisions can be reached after data is written to distributed ledger 42 [(that is, to perform “consensus decisioning” is wherein the voting ledge is to store the votes)]”).
Manahoman ‘955 and Garg are from the same or similar field of endeavor. Manahoman ‘955 teaches decentralized machine learning where model builds are performed at nodes where local training datasets are generated. Garg teaches calculating validation loss in a distributed machine learning network where nodes train local instances maintained at the nodes.
Thus, it would have been obvious to a person having ordinary skill in the art as of the effective filing date of the Applicant’s invention to modify Manahoman ‘955 pertaining to decentralized machine learning with the decentralized validation loss of Garg.
The motivation to do so is because “[v] alidation loss can be an important aspect of ML for implementing training features. For example, validation loss can be used to avoid overfitting a model on training data by creating an early stopping criterion in which training is halted once the validation loss reaches a minimum value. As another example, validation loss can be used in an adaptive synchronization setting, where the length of a synchronization interval is modulated based on the progress of validation loss values across multiple iteration (i.e., modulating the synchronization frequency).” (Garg ¶ 0025).
Conclusion
14. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
(Robert J. Bowman, “Introduction to CMOS Analog Standard Cell ASIC Design,” IEEE (1989)) teaches a vertical bipolar transistor of reasonable performance is available in generic CMOS processes by using the well as the base region, the substrate as the collector and a highly doped pocket in the well as an emitter.
(Lee et al., "Distributed Watchdogs Based on Blockchain for Securing Industrial Internet of Things," Sensors (June 2021)) teaches a new approach that leverages distributed watchdogs with blockchain systems in protecting software supply chains. For this purpose, we bind every entity with a unique identity in the blockchain and employ the blockchain as a delegated authenticator by mapping every reporting action to a non-fungible token transfer. Moreover, we present a detailed specification to clearly define the behavior of systems and to apply model checking.
(Shayan et al., "Biscotti: A Blockchain System for Private and Secure Federated Learning," IEEE (July 2021)) teaches a fully decentralized peer to peer (P2P) approach to multi-party ML, which uses block chain and cryptographic primitives to coordinate a privacy-preserving ML process between peering clients. Our evaluation demonstrates that Biscotti is scalable, fault tolerant, and defends against known attacks. For example, Biscotti is able to both protect the privacy of an individual client’s update and maintain the performance of the global model at scale when 30 percent adversaries are present in the system.
(Rathore et al., "A Blockchain-Based Deep Learning Approach for Cyber Security in Next Generation Industrial Cyber-Physical Systems," IEEE (Aug 2021)) teaches we propose DeepBlockIoTNet, a secure DL approach with blockchain for the IoT network wherein the DL operation is carried out among the edge nodes at the edge layer in a decentralized, secure manner. The blockchain provides a secure DL operation and removes the control from a centralized authority. The experimental evaluation demonstrates that the proposed approach supports higher accuracy.
(US Published Application 20220085975 to Manahoman et al.) teaches systems and methods are provided for implementing swarm learning while using blockchain technology and election/voting mechanisms to ensure data privacy.
15. Any inquiry concerning this communication or earlier communications from the Examiner should be directed to KEVIN L. SMITH whose telephone number is (571) 272-5964. Normally, the Examiner is available on Monday-Thursday 0730-1730.
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, KAKALI CHAKI can be reached on 571-272-3719. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/K.L.S./
Examiner, Art Unit 2122
/KAKALI CHAKI/Supervisory Patent Examiner, Art Unit 2122
1 References to the limitations are provided for the limited purpose of aiding in the subject-matter eligibility evaluation under the Office guidance and not for the purpose of oversimplifying the claims
Prosecution Insights