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 .
DETAILED ACTION
This action is in response to the communication filed on 2/27/24.
Claims 1 – 14 are rejected.
Claim 15 is objected.
Any references to applicant’s specification are made by way of applicant’s U.S. pre-grant printed patent publication.
Claim Interpretation
The claim term “iteration number” – used within the context of digital certificates – is not a standard term within the art. However, the Applicant’s disclosure has appeared, on multiple instances, to suggest that the term “iteration number” can be equated to the term “version number”. For example, see Specification, paragraph [0032], “… The iteration number or version number distinguishes certificates…” and paragraph [0068], “… The certification authorities 14 and signers 13 comprise an additional information called iteration number or version number. …”.
Thus, for the purposes of examination, the examiner presumes the claimed term “iteration number” may be interpreted as representing a “version number”.
Claim Objections
Claim 11 is objected to because of the following informalities: the recitation of “…the data hos)…” (line 3) should be amended to recite “the data host”. Appropriate correction is required.
Claim 15 is objected to under 37 CFR 1.75(c) as being in improper form because a multiple dependent claim may only refer to other claims in the alternative only (e.g. claims 12 or 13) See MPEP § 608.01(n). Accordingly, claim 15 (which cumulatively depends upon each of claims 12 and 13) not been further treated on the merits.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1 – 14 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 1, the applicant establishes antecedent basis for the term “authenticated data” (e.g. line 1), however subsequently refers only to “the data” within line 3. Thus, the applicant’s claims fails to follow the norms of antecedent basis within claim terminology, and it is unclear whether the recitation of “the data” is a reference to the previously recited “authenticated data”.
Furthermore, it is noted that the applicant’s claims additionally establish the term “the signed data” (lines 4 and 5) – which is apparently a reference to the antecedent recitation of “signing the data” within line 3). However, subsequent within the claim, the applicant reverts back to reciting the term “the data” (e.g. line 9), which fails to clearly provide a reference to which of the antecedent forms of data (e.g. “authenticated data”, “the data”, “the signed data”) that the applicant intends to reference.
Thus, claim 1 is rendered indefinite in scope.
Regarding claim 2, similar to claim 1, the applicant recites the term “the data” without clearly pointing to which of the antecedent recited forms of data (e.g. “authenticated data”, “the data”, “the signed data”) that the applicant intends to reference. Thus, claim 2 is rendered indefinite in scope.
Claims 12 and 13, comprise essentially similar recitations as claim 1, and are noted to lack clarity for the same reasons.
Depending claims 3 – 11 and 14 are rejected by virtue of dependency.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1 – 3 and 12 – 14 are rejected under 35 U.S.C. 103 as being unpatentable over Fassino et al. (Fassino), US 2022/0179640 A1.
Regarding claim 1, as best determined in view of the above noted lack of clarity, Fassino discloses:
A method for modifying an electronic device using authenticated data from a data host (e.g. Fassino, Abstract; fig. 1:2, 6, 10; par. 5, 37, 40, 58 – herein is a method for updating a device 2 by providing a plurality of signed firmware updates (i.e. “authenticated data” or “the data”), which are received from a work station signing portal 6), the method comprising the steps of
a signing service (e.g. Fassino, fig. 1:5 – the signing portal accesses a HSM, i.e. “signing service” to perform digital signatures upon the created firmware updates; par. 40) digitally signing the data with a digital signature using a signature private key of a signature key pair … (e.g. Fassino, par. 13, 39, 40, 58 – the signing portal uses a HSM to digitally sign the plurality of firmware updates using the private part of a signing key, i.e. the private key of a public/private keypair)
Fassino discloses that the “data host” (i.e. the signing portal) creates firmware updates and provides the created updates to a “signing service” (i.e. a HSM) which digitally signs the updates. However, Fassino does not appear to explicitly state that the “signing service” provides the signed updates back to the “data host” so that the data host can deliver the signed updates to the electronic device. Thus, Fassino does not appear to explicitly state “…and providing the signed data to the data host”.
However, the examiner points out that this feature would have been obvious to one of ordinary skill in the art at the time of the applicant’s invention. Specifically because the examiner points out that Fassino explicitly illustrates that the signed firmware updates are sent to the device from the “data host” (e.g. Fassino, fig. 1:2, 10, 6). Herein, the firmware updates 10 are shown to be sent from the Portal 6 to the Device 2. Furthermore, Fassino also explicitly claims that the Portal is the device which provides the signed firmware update (e.g. claim 2, “…the signing portal providing a software package that contain a firmware update signed with the signing key…”).
Thus, it would have been obvious to one of ordinary skill in the art to recognize that the Portal (or “data host”) should first receive back from the HSM (or “signing service”) the signed firmware updates that were signed by the HSM, so as to enable the Portal to deliver the signed firmware updates to the Device 10, because one of ordinary skill in the art would have been motivated by Fassino’s teachings that the Portal itself is the means for delivering the digitally signed updates to the Device 10.
Thus, Fassino enables:
the electronic device retrieving the signed data from the data host (e.g. Fassino, fig. 1:2 [Wingdings font/0xDF] 10 [Wingdings font/0xDF] 6; Claim 2);
the electronic device confirming a signature public key of the signature key pair using a certificate of a certificate authority (e.g. Fassino, par. 46, 47 – the device validates the public key of the certificate, which comprises the public key [i.e. same master key] of the Certificate Authority);
the electronic device checking whether the certificate is valid (e.g. Fassino, par. 41, 44 – the device checks the revision number of the certificate to ensure that it is current and accepted as valid);
and the electronic device confirming the digital signature and thus authenticity of the data using the signature public key (e.g. Fassino, par. 49, 50 – the device verifies the signature of the signing key on the firmware update and based upon the verification, accepts the firmware update if the signature is valid),
wherein the certificate includes an iteration number (e.g. Fassino, par. 15, 42 – revision number, aka “version number”, to indicate if it is the latest version) and in that the electronic device checks whether the certificate is valid based on the iteration number (e.g. Fassino, par. 44, 49 – the device checks the certificates revision number).
Regarding claim 2, Fassino enables:
wherein at least a second digital signature and at least a second certificate are used to confirm authenticity of the data (e.g. Fassino, par. 58 – herein the firmware updates are validated using updated or “second” signing certificates) with the second certificate also checked for validity based on the iteration number or another iteration number (e.g. Fassino, par. 58, 15, 42 – the updated or “second” certificate also comprises a revision number to be validated).
Regarding claim 3, Fassino enables:
wherein the electronic device stores a minimal iteration number that the certificate's iteration number needs to match or exceed in order to be accepted as being valid (e.g. Fassino, par. 44, 53 – the revision number must be greater or equal to a rollback number, i.e. “minimal iteration number”).
Regarding claims 12 and 13, they are system and device claims essentially corresponding to the claims above, and they are rejected, at least, for the same reasons.
Furthermore because regarding claim 12, Fassino enables:
A data host (e.g. Fassino, fig. 1:6 – Portal) and certification network (e.g. Fassino, fig. 1) for providing authenticated data (e.g. Fassino, fig. 1:10) to an electronic device (e.g. Fassino, fig. 1:2), the certification network comprising a certificate authority (e.g. Fassino, fig. 1:7) configured to issue a certificate confirming authenticity of a signature public key of a signature key pair (e.g. Fassino, par. 46, 47) and a signing service (e.g. Fassino, fig. 1:5) for digitally signing the data with a digital signature using a signature private key of the signature key pair (e.g. Fassino, par. 40) and the data host providing direct or indirect access for the electronic device to retrieve the signed data (e.g. Fassino, fig. 1:2 [Wingdings font/0xDF] 10 [Wingdings font/0xDF] 6; Claim 2), wherein the certificate includes an iteration number usable in a check whether the certificate is valid (e.g. Fassino, par. 15, 42).
Furthermore because regarding claim 13, Fassino enables:
An electronic device (e.g. Fassino, fig. 1:2) comprising an interface for at least indirectly connecting the electronic device to a data host (e.g. Fassino, fig. 1:2 [Wingdings font/0xDF] 10 [Wingdings font/0xDF] 6; Claim 2), a memory for storing data (e.g. Fassino, par. 37), and a control unit configured to retrieve authenticated data via the interface and to store the data in the memory (e.g. Fassino, par. 37 – the device comprises, at least, controlling software to perform firmware updates), the data digitally being signed by a signing service with a digital signature using a signature private key of a signature key pair (e.g. Fassino, par. 40, 46, 47);
verify a signature public key of the signature key pair using a certificate of a certificate authority (e.g. Fassino, par. 46, 47 – the device validates the public key of the certificate, which comprises the public key [i.e. same master key] of the Certificate Authority);
check whether the certificate is valid (e.g. Fassino, par. 41, 44 – the device checks the revision number of the certificate to ensure that it is current and accepted as valid);
confirm the digital signature and thus authenticity of the data using the signature public key (e.g. Fassino, par. 49, 50 – the device verifies the signature of the signing key on the firmware update and based upon the verification, accepts the firmware update if the signature is valid);
and if authenticity of the data is confirmed, modify the future control of the electronic device based on the data (e.g. Fassino, par. 49, 50 – the device accepts the firmware update),
wherein the certificate includes an iteration number and the control unit is further configured to check whether the certificate is valid based on the iteration number (e.g. Fassino, par. 15, 42, 49, 50 – revision number, aka “version number”, to indicate if it is the latest version).
Regarding claim 14, Fassino enables:
An electronic device according to claim 13 that is configured as a sensor (e.g. Fassino, par. 37 – the device may be a circuit breaker or power meter, i.e. a sensing device).
Claims 4 – 11 are rejected under 35 U.S.C. 103 as being unpatentable over Fassino et al. (Fassino), US 2022/0179640 A1 in view of Pyle, US 2016/0191253 A1.
Regarding claim 4, Fassino does not disclose, however Pyle does disclose that certificate authorities may belong to a chain or hierarchy of certificate authorities (e.g. Pyle, par. 31, 32).
It would have been obvious to one of ordinary skill in the art to recognize the hierarchical CA certificate chaining teachings of Pyle within the teachings of Fassino for employing a certificate authority CA.
This would have been obvious because one of ordinary skill in the art would have been motivated by the teachings that employing a plurality of hierarchical certificate authorities provides an additional layer of security (e.g. Pyle, par. 31).
Thus, the combination enables:
wherein certificates of the certificate authority are validated by a chain of higher-level certificate authorities with a root certificate authority at the origin of the chain (e.g. Pyle, par. 31), wherein in particular the electronic device stores a root certificate of the root certificate authority (e.g. Fassino, par. 48; Pyle, par. 5, 31).
Regarding claim 5, it is rejected for the same reasons as claim 4, and furthermore the combination enables:
wherein the electronic device stores a product identifier corresponding to a designated certificate authority among a plurality of certificate authorities that include a certificate authority responsible for each possible product identifier (e.g. Fassino, par. 48; Pyle, par. 5, 31, 33 – each root, or CA, certificate comprises an identifiers established by the manufacturer, i.e. “product identifier” used to identity the specific CA).
Regarding claim 6, the combination enables:
wherein the electronic device (10) checks whether the certificate matches the product identifier (e.g. Pyle, par. 5, 33).
Regarding claim 7, the combination enables:
wherein the root certificate authority authenticates a plurality of certificate authorities that include a certificate authority responsible for each possible product identifier (e.g. Pyle, par. 32, 33).
Regarding claim 8, the combination enables:
wherein, in order to invalidate or revoke a certificate, a new certificate authority is set up, replacing the certificate authority, and issuing certificates with iteration number increased (e.g. Fassino, par. 19, 60; Pyle, par. 5, 21, 22, 31-33).
Regarding claim 9, the combination enables:
wherein the new certificate authority is authenticated by the root certificate authority (e.g. Pyle, par. 31-33).
Regarding claim 10, the combination enables:
wherein the authentication by the root certificate authority takes place offline and/or wherein the root certificate authority is always offline (e.g. Fassino, par. 39; Pyle, par. 4, 22, 29).
Regarding claim 11, the combination enables:
wherein, following revocation of a certificate and increase of the iteration number (e.g. Fassino, par. 49, 53), the electronic device is updated via authenticated data retrieved from the data hos), the update including storage of a new minimal iteration number (e.g. Fassino, par. 16, 19, 57, 65; Pyle, par. 29, 31).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
See Notice of References Cited.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEFFERY L WILLIAMS whose telephone number is (571)272-7965. The examiner can normally be reached on 7:30 am - 4:00 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Farid Homayounmehr can be reached on 571-272-3739. 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.
/JEFFERY L WILLIAMS/ Primary Examiner, Art Unit 2495