DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Priority
The instant application claims foreign priority to JP2023-068624 filed 19 April 2023. The priority claim complies with all applicable rules and regulations. Therefore, the effective filing date of the claims will be 19 April 2023.
Response to Arguments
Applicant's arguments filed 06 January 2026 have been fully considered but they are not persuasive.
In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, stated initially on page 13 and then on subsequent pages, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007).
In this case, applicant has provided a blanket statement that “there is no motivation or incentive in Hall et al., alone or in combination with Janjua et al., Yoshimi et al., Kolodner et al., Kim et al. and Kupwade Patil et al. or any of the other references cited, to arrive at Applicant's disclosure as claimed” on page 13. Applicant has not provided any arguments against any of the motivations specifically. The examiner submits that proper motivations to combine the cited prior art have been provided in the 35 U.S.C. 103 section below and were also present in the previous Office action.
In response to applicant’s arguments that “Hall et al., alone or in combination with Janjua et al., Yoshimi et al., Kolodner et al., Kim et al. and Kupwade Patil et al. or any of the other references cited, teaches away from Applicant's unique and innovative signature verification device, signature verification method, storage medium storing a signature verification program and encryption processing device” stated on page 13 and similar arguments, the examiner respectfully disagrees.
See MPEP 2144.05(III)(B)—"Applicant can rebut a presumption of obviousness based on a claimed invention that falls within a prior art range by showing "(1) [t]hat the prior art taught away from the claimed invention." Iron Grip Barbell Co., Inc. v. USA Sports, Inc., 392 F.3d 1317, 1322, 73 USPQ2d 1225, 1228 (Fed. Cir. 2004).”
See also MPEP 2143.01(I)—"Applicant argued that the combination was improper because (1) the prior art did not suggest having the hexagonal projections in a facing (as opposed to a "pointing") orientation was the "most desirable" configuration for the projections, and (2) the prior art "taught away" by showing desirability of the "pointing orientation." 391 F.3d at 1200-01, 73 USPQ2d at 1145-46. The court stated that "the prior art’s mere disclosure of more than one alternative does not constitute a teaching away from any of these alternatives because such disclosure does not criticize, discredit, or otherwise discourage the solution claimed…." Id.”
In this case, applicant has only provided a blanket statement that the cited prior art “teaches away” and has not shown how the any of the cited prior art teaches away from the claimed invention. Applicant states on pages 14-15 that “the cited references teach away from and articulate various disadvantages associated with the arrangement, configuration and orientation of components/steps/instructions taught in Applicant's claimed disclosure”. However, applicant does not state where in the cited prior art the disadvantages are located. The examiner cannot find any evidence of the disadvantages.
The examiner submits that none of the cited prior art used in the 35 U.S.C. 103 combinations criticize, discredit, or otherwise discourage the solution claimed. Therefore, none of the cited prior art teaches away from the respective combinations.
In response to applicant’s arguments that “Hall et al., alone or in combination with Janjua et al., Yoshimi et al., Kolodner et al., Kim et al. and Kupwade Patil et al. or any of the other references cited, does not disclose, teach or suggest, at least, any structure/step/function similar to Applicant's signature verification device including, in part, ‘configured to compare a first security strength, which is a security strength of the signature, with a second security strength, which is a security strength of a signature received together with a previously received file’”, stated on page 14, the examiner respectfully disagrees.
Hall et al. discloses install/update utility 610 may also compare the security index score of software package 602 to a predetermined threshold or a security index score of a previous version of the software in application storage 612 (Fig. 6, el. 612; Para. 48), wherein the software package 602 may be associated with security index 604 and digital signature 606, which may accompany software package 602 (Fig. 6, el. 606; Para. 47). The security index rates the security level of a portion of code and is associated with the code (Para. 20).
Hall further discloses install/update utility 610 may then ensure that the security index for software applications generally increase or at least remain above an acceptable threshold (Para. 49).
Janjua et al. discloses object 106 is signed by a signing entity 114 to create a signature for the object (Fig. 1, el. 106; Para. 17). Once the signature is created, the device 112 and/or the signing entity 114 submit, to the verifying entity 102, the signature for trust verification, as referenced by 120, wherein the signature can be embedded into the object 106 such that the object 106, along with the embedded signature, can be submitted, for trust verification (Para. 18), wherein an object can comprise a certificate (e.g., of a Secure Sockets Layer (SSL) site), an executable file, or user credentials (Para. 14).
Janjua further discloses an invalidity event associated with a signature can alternatively or additionally comprise a recent determination of a previously unknown weakness in the signature, wherein a weakness can be related to an insufficient key size or key length, and a weakness can be related to a compromised or broken signature algorithm (e.g., Security Hash Algorithm-1 (SHA1) is broken and Security Hash Algorithm-2 (SHA2) should be used instead) (Para. 26).
Hall’s system of comparing the security index of a received software package with the security index of a previous version of the software, the software package being accompanied by the signature and the security index is being combined with Janjua’s system of determining a weakness in a signature, wherein the signature may be embedded into an executable file. In other words, Hall’s software package is modified to include the signature as taught by Janjua. Hall’s security index will then also cover the signature since it is included within the software package.
Therefore, the combination of Hall and Janjua then teaches “to compare a first security strength, which is a security strength of the signature, with a second security strength, which is a security strength of a signature received together with a previously received file” of claim 1 and similar limitations in claims 12-14.
Applicant further argues “Hall et al. is an improper primary reference, Janjua et al., Yoshimi et al., Kolodner et al., Kim et al. and Kupwade Patil et al. are improper secondary references” stated on page 17. The examiner respectfully disagrees.
Each of the cited prior art is a valid, proper prior art reference under 35 U.S.C. 102 and, as stated above, none of the references teach away from the combinations. Therefore, the cited prior art are proper references.
In response to applicant's argument that the examiner's conclusion of obviousness is based upon improper hindsight reasoning, stated on page 17, it must be recognized that any judgment on obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so long as it takes into account only knowledge which was within the level of ordinary skill at the time the claimed invention was made, and does not include knowledge gleaned only from the applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 170 USPQ 209 (CCPA 1971).
The examiner submits that all motivations to combine the cited prior art takes into account only knowledge which was within the level of ordinary skill and gleaned from the prior art and does not include knowledge gleaned only from applicant’s disclosure. Therefore, the none of the conclusions of obviousness were based on hindsight reasoning.
Claim Rejections - 35 USC § 103
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.
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, 2, 4, 5, 8, and 12-15 are rejected under 35 U.S.C. 103 as being unpatentable over Hall et al. (US 2005/0283622 A1) in view of Janjua et al. (US 2018/0062859 A1).
Regarding claim 1, Hall teaches a signature verification device, e.g., client 108, 110, 112 (Fig. 1, el. 108, 110, 112), wherein one or more of clients 108, 110, 112 may be used by an operator to install code based on a security index (Para. 22); before installing software package 602, install/update utility 610 may validate security index 604 by authenticating digital signature 606 and validating that security index 604 and software package 602 have not been modified (Fig. 6, el. 602, 604, 610; Para. 48),
that receives, from an external device, e.g., server 104 (Fig. 1, el. 104), a file that records information and a signature generated based on the information, e.g., install/update utility 610 receives software package 602 for installation to application storage 612 (Para. 46); the software package 602 may be associated with security index 604 and digital signature 606, which may accompany software package 602 or may be obtained from a central authority (Fig. 6, el. 606; Para. 47); server 104 may manage a source code repository tool, such as a concurrent versioning system (CVS) (Para. 22); the software package 602 may be an application installation, an application update, an operating update, a security fix, or the like (Para. 46), and
executes processing on the file, e.g., if the security index 604 is not above a critical threshold, install/update utility 610 may refuse to install software package 602 to application storage 612, and if the security index 604 is not above a warning threshold, install/update utility 610 may warn the user of the security level of the software package and prompt the user for instructions as to whether to continue installation (Para. 49); before installing software package 602, install/update utility 610 may validate security index 604 by authenticating digital signature 606 and validating that security index 604 and software package 602 have not been modified (Para. 48),
the signature verification device comprising
at least one of a circuit and a processor with a memory storing computer program code executable by the processor, e.g., the processes of the present invention are performed by processor 302 using computer implemented instructions, which may be located in a memory (Fig. 3, 302; Para. 32); LAN adapter 312/MODEM 322 (Fig. 3, el. 312, 322), configured to serve as:
a reception unit, e.g., the processes of the present invention are performed by processor 302 using computer implemented instructions, which may be located in a memory (Fig. 3, 302; Para. 32); LAN adapter 312/MODEM 322 (Fig. 3, el. 312, 322), configured to receive the file and the signature, e.g., install/update utility 610 receives software package 602 for installation to application storage 612 (Para. 46); the software package 602 may be associated with security index 604 and digital signature 606, which may accompany software package 602 or may be obtained from a central authority (Para. 47);
a security strength comparison unit, e.g., install/update utility 610 (Fig. 6, el. 610); the processes of the present invention are performed by processor 302 using computer implemented instructions, which may be located in a memory (Fig. 3, 302; Para. 32), configured to compare a first security strength, which is a security strength of the file, with a second security strength, which is a security strength of…a previously received file, e.g., install/update utility 610 may also compare the security index score of software package 602 to a predetermined threshold or a security index score of a previous version of the software in application storage 612 (Fig. 6, el. 612; Para. 48),
a signature received together with a previously received file, e.g., the software package 602 may be associated with security index 604 and digital signature 606, which may accompany software package 602 or may be obtained from a central authority (Fig. 6, el. 606; Para. 47); and
a file utilization processing execution unit, e.g., install/update utility 610 (Fig. 6, el. 610); the processes of the present invention are performed by processor 302 using computer implemented instructions, which may be located in a memory (Fig. 3, 302; Para. 32), configured to execute the processing for utilizing the file, e.g., if the security index 604 is not above a critical threshold, install/update utility 610 may refuse to install software package 602 to application storage 612, and if the security index 604 is not above a warning threshold, install/update utility 610 may warn the user of the security level of the software package and prompt the user for instructions as to whether to continue installation (Para. 49),
wherein the file utilization processing execution unit is configured to execute the processing for utilizing the file when the first security strength is higher than the second security strength, e.g., install/update utility 610 may also compare the security index score of software package 602 to a predetermined threshold or a security index score of a previous version of the software in application storage 612 (Para. 48); install/update utility 610 may then ensure that the security index for software applications generally increase or at least remain above an acceptable threshold, wherein if the security index 604 is not above a critical threshold, install/update utility 610 may refuse to install software package 602 to application storage 612, and if the security index 604 is not above a warning threshold, install/update utility 610 may warn the user of the security level of the software package and prompt the user for instructions as to whether to continue installation (Para. 49), and
not execute the processing for utilizing the file when the first security strength is lower than the second security strength, e.g., install/update utility 610 may also compare the security index score of software package 602 to a predetermined threshold or a security index score of a previous version of the software in application storage 612 (Para. 48); install/update utility 610 may then ensure that the security index for software applications generally increase or at least remain above an acceptable threshold, wherein if the security index 604 is not above a critical threshold, install/update utility 610 may refuse to install software package 602 to application storage 612, and if the security index 604 is not above a warning threshold, install/update utility 610 may warn the user of the security level of the software package and prompt the user for instructions as to whether to continue installation (Para. 49).
Hall does not clearly teach a security strength comparison unit configured to compare a first security strength, which is a security strength of the signature, with a second security strength, which is a security strength of a signature received together with a previously received file.
Janjua teaches a signature verification device, e.g., verifying entity 102 (Fig. 1, el. 102); once the signature is created, the device 112 and/or the signing entity 114 submit, to the verifying entity 102, the signature for trust verification, as referenced by 120 (Fig. 1, el. 112, 114, 120; Para. 18), that receives, from an external device, e.g., device 112/signing entity 114 (Fig. 1, el. 112, 114), a file that records information and a signature generated based on the information, e.g., the object 106 is signed by a signing entity 114 to create a signature for the object (Fig. 1, el. 106; Para. 17); once the signature is created, the device 112 and/or the signing entity 114 submit, to the verifying entity 102, the signature for trust verification, as referenced by 120, wherein the signature can be embedded into the object 106 such that the object 106, along with the embedded signature, can be submitted, for trust verification (Para. 18); an object can comprise a certificate (e.g., of a Secure Sockets Layer (SSL) site), an executable file, or user credentials (Para. 14), and
executes processing on the file, e.g., an object can comprise a certificate (e.g., of a Secure Sockets Layer (SSL) site), an executable file, or user credentials (Para. 14),
the signature verification device comprising
at least one of a circuit and a processor with a memory storing computer program code executable by the processor, e.g., the verifying entity 102 is also comprised of one or more devices configured with processing and/or memory resources that can connect to a network 116 (Fig. 1, el. 116; Para. 19), configured to serve as:
a reception unit, e.g., the verifying entity 102 is also comprised of one or more devices configured with processing and/or memory resources that can connect to a network 116 (Fig. 1, el. 116; Para. 19), configured to receive the file and the signature, e.g., once the signature is created, the device 112 and/or the signing entity 114 submit, to the verifying entity 102, the signature for trust verification, as referenced by 120 (Fig. 1, el. 112, 114, 120; Para. 18);
a security strength comparison unit, e.g., invalidity event determination module 206 (Fig. 2, el. 206), configured to compare a first security strength, which is a security strength of the signature, with a second security strength, which is a security strength of a signature…, e.g., an invalidity event associated with a signature can alternatively or additionally comprise a recent determination of a previously unknown weakness in the signature, wherein a weakness can be related to an insufficient key size or key length, and a weakness can be related to a compromised or broken signature algorithm (e.g., Security Hash Algorithm-1 (SHA1) is broken and Security Hash Algorithm-2 (SHA2) should be used instead) (Para. 26); and
….
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hall to include a security strength comparison unit configured to compare a first security strength, which is a security strength of the signature, with a second security strength, which is a security strength of a signature received together with a previously received file, using the known method of determining a signature has an insufficient key length or uses a compromised or broken signature algorithm, as taught by Janjua, in combination with the software package security index comparison techniques of Hall, for the purpose of increasing the security of the communication system and the receiver by aiding in the prevention of installing malicious software packages.
Regarding claim 2, Hall in view of Janjua teaches the signature verification device according to claim 1, wherein the file utilization processing execution unit executes the processing for utilizing the file when the first security strength is equal to or higher than the second security strength, e.g., install/update utility 610 may also compare the security index score of software package 602 to a predetermined threshold or a security index score of a previous version of the software in application storage 612 (Hall-Para. 48); install/update utility 610 may then ensure that the security index for software applications generally increase or at least remain above an acceptable threshold, wherein if the security index 604 is not above a critical threshold, install/update utility 610 may refuse to install software package 602 to application storage 612, and if the security index 604 is not above a warning threshold, install/update utility 610 may warn the user of the security level of the software package and prompt the user for instructions as to whether to continue installation (Hall-Para. 49).
Regarding claim 4, Hall in view of Janjua teaches the signature verification device according to claim 2, wherein the signature verification device is an update control device that controls an update of software, that is the information, for an electronic control unit, e.g., these clients 108, 110, and 112 may be personal computers or network computers (Hall-Para. 19), that implements the signature verification device, and the file utilization processing execution unit installs the software as the processing for utilizing the file, e.g., install/update utility 610 may also compare the security index score of software package 602 to a predetermined threshold or a security index score of a previous version of the software in application storage 612 (Hall-Para. 48); install/update utility 610 may then ensure that the security index for software applications generally increase or at least remain above an acceptable threshold, wherein if the security index 604 is not above a critical threshold, install/update utility 610 may refuse to install software package 602 to application storage 612, and if the security index 604 is not above a warning threshold, install/update utility 610 may warn the user of the security level of the software package and prompt the user for instructions as to whether to continue installation (Hall-Para. 49).
Regarding claim 5, Hall in view of Janjua teaches the signature verification device according to claim 1, wherein the signature verification device is a data utilization control device that controls utilization of data that is the information, and the file utilization processing execution unit decrypts or stores the data or downloads the data as the processing for utilizing the file, e.g., install/update utility 610 may also compare the security index score of software package 602 to a predetermined threshold or a security index score of a previous version of the software in application storage 612 (Hall-Para. 48); install/update utility 610 may then ensure that the security index for software applications generally increase or at least remain above an acceptable threshold, wherein if the security index 604 is not above a critical threshold, install/update utility 610 may refuse to install software package 602 to application storage 612, and if the security index 604 is not above a warning threshold, install/update utility 610 may warn the user of the security level of the software package and prompt the user for instructions as to whether to continue installation (Hall-Para. 49).
Regarding claim 8, Hall in view of Janjua teaches the signature verification device according to claim 2, wherein the security strength of the signature is determined based on an algorithm of a signature method of the signature and a length of a key used for the signature, e.g., an invalidity event associated with a signature can alternatively or additionally comprise a recent determination of a previously unknown weakness in the signature, wherein a weakness can be related to an insufficient key size or key length, and a weakness can be related to a compromised or broken signature algorithm (e.g., Security Hash Algorithm-1 (SHA1) is broken and Security Hash Algorithm-2 (SHA2) should be used instead) (Janjua-Para. 26).
Regarding claim 12, the claim is analyzed with respect to claim 1.
Examiner note: claim 12 includes contingent limitations—“executing the processing for utilizing the file when the first security strength is higher than the second security strength” and “not executing the processing for utilizing the file when the first security strength is lower than the second security strength”.
See MPEP 2111.04 (II)—“The broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed and does not include steps that are not required to be performed because the condition(s) precedent are not met. For example, assume a method claim requires step A if a first condition happens and step B if a second condition happens. If the claimed invention may be practiced without either the first or second condition happening, then neither step A or B is required by the broadest reasonable interpretation of the claim. If the claimed invention requires the first condition to occur, then the broadest reasonable interpretation of the claim requires step A. If the claimed invention requires both the first and second conditions to occur, then the broadest reasonable interpretation of the claim requires both steps A and B.”
Therefore, if the first security strength is higher, then the processing will be executed and the “not executing” step will not be performed or required. If the first security strength is not higher, then the processing will not be executed and the “executing” step will not be performed or required.
Regarding claim 13, the claim is analyzed with respect to claim 1. Hall in view of Janjua further teaches a non-transitory computer readable storage medium, e.g., main memory 304 (Hall-Fig. 3, el. 304), storing a signature verification program executable by a signature verification device, e.g., client 108, 110, 112 (Hall-Fig. 1, el. 108, 110, 112), wherein one or more of clients 108, 110, 112 may be used by an operator to install code based on a security index (Hall-Para. 22); before installing software package 602, install/update utility 610 may validate security index 604 by authenticating digital signature 606 and validating that security index 604 and software package 602 have not been modified (Hall-Fig. 6, el. 602, 604, 610; Para. 48).
Regarding claim 14, Hall teaches an…processing device, e.g., client 108, 110, 112 (Fig. 1, el. 108, 110, 112), wherein one or more of clients 108, 110, 112 may be used by an operator to install code based on a security index (Para. 22); before installing software package 602, install/update utility 610 may validate security index 604 by authenticating digital signature 606 and validating that security index 604 and software package 602 have not been modified (Fig. 6, el. 602, 604, 610; Para. 48), that receives a file that records…information from an external device, e.g., server 104 (Fig. 1, el. 104); install/update utility 610 receives software package 602 for installation to application storage 612 (Para. 46); the software package 602 may be associated with security index 604 and digital signature 606, which may accompany software package 602 or may be obtained from a central authority (Fig. 6, el. 606; Para. 47); server 104 may manage a source code repository tool, such as a concurrent versioning system (CVS) (Para. 22); the software package 602 may be an application installation, an application update, an operating update, a security fix, or the like (Para. 46), and
executes processing on the file, e.g., if the security index 604 is not above a critical threshold, install/update utility 610 may refuse to install software package 602 to application storage 612, and if the security index 604 is not above a warning threshold, install/update utility 610 may warn the user of the security level of the software package and prompt the user for instructions as to whether to continue installation (Para. 49); before installing software package 602, install/update utility 610 may validate security index 604 by authenticating digital signature 606 and validating that security index 604 and software package 602 have not been modified (Para. 48),
the…processing device comprising
at least one of a circuit and a processor with a memory storing computer program code executable by the processor, e.g., the processes of the present invention are performed by processor 302 using computer implemented instructions, which may be located in a memory (Fig. 3, 302; Para. 32); LAN adapter 312/MODEM 322 (Fig. 3, el. 312, 322), configured to serve as:
a reception unit, e.g., LAN adapter 312/MODEM 322 (Fig. 3, el. 312, 322), configured to receive the file, e.g., install/update utility 610 receives software package 602 for installation to application storage 612 (Para. 46); the software package 602 may be associated with security index 604 and digital signature 606, which may accompany software package 602 or may be obtained from a central authority (Para. 47);
a security strength comparison unit, e.g., install/update utility 610 (Fig. 6, el. 610); the processes of the present invention are performed by processor 302 using computer implemented instructions, which may be located in a memory (Fig. 3, 302; Para. 32), configured to compare a first security strength, which is a security strength of…the information, with a second security strength, which is a security strength of…information included in a previously received file, e.g., install/update utility 610 (Fig. 6, el. 610); the processes of the present invention are performed by processor 302 using computer implemented instructions, which may be located in a memory (Fig. 3, 302; Para. 32); and
a file utilization processing execution unit, e.g., install/update utility 610 (Fig. 6, el. 610); the processes of the present invention are performed by processor 302 using computer implemented instructions, which may be located in a memory (Fig. 3, 302; Para. 32), configured to execute the processing for utilizing the file, e.g., if the security index 604 is not above a critical threshold, install/update utility 610 may refuse to install software package 602 to application storage 612, and if the security index 604 is not above a warning threshold, install/update utility 610 may warn the user of the security level of the software package and prompt the user for instructions as to whether to continue installation (Para. 49),
wherein the file utilization processing execution unit is configured to execute the processing for utilizing the file when the first security strength is higher than the second security strength, e.g., install/update utility 610 may also compare the security index score of software package 602 to a predetermined threshold or a security index score of a previous version of the software in application storage 612 (Para. 48); install/update utility 610 may then ensure that the security index for software applications generally increase or at least remain above an acceptable threshold, wherein if the security index 604 is not above a critical threshold, install/update utility 610 may refuse to install software package 602 to application storage 612, and if the security index 604 is not above a warning threshold, install/update utility 610 may warn the user of the security level of the software package and prompt the user for instructions as to whether to continue installation (Para. 49), and
not execute the processing for utilizing the file when the first security strength is lower than the second security strength, e.g., install/update utility 610 may also compare the security index score of software package 602 to a predetermined threshold or a security index score of a previous version of the software in application storage 612 (Para. 48); install/update utility 610 may then ensure that the security index for software applications generally increase or at least remain above an acceptable threshold, wherein if the security index 604 is not above a critical threshold, install/update utility 610 may refuse to install software package 602 to application storage 612, and if the security index 604 is not above a warning threshold, install/update utility 610 may warn the user of the security level of the software package and prompt the user for instructions as to whether to continue installation (Para. 49).
Hall does not clearly teach an encryption processing device that receives a file that records encrypted information from an external device, and executes processing on the file, the encryption processing device comprising:
a security strength comparison unit configured to compare a first security strength, which is a security strength of encryption used to encrypt the information, with a second security strength, which is a security strength of encryption used to encrypt information included in a previously received file.
Janjua teaches an encryption processing device, e.g., verifying entity 102 (Fig. 1, el. 102); once the signature is created, the device 112 and/or the signing entity 114 submit, to the verifying entity 102, the signature for trust verification, as referenced by 120 (Fig. 1, el. 112, 114, 120; Para. 18); the private key is used to sign (e.g., encrypt, encode, etc.) a hash of an object to create the signature (Para. 14), that receives a file that records encrypted information from an external device, e.g., device 112/signing entity 114 (Fig. 1, el. 112, 114), e.g., the object 106 is signed by a signing entity 114 to create a signature for the object (Fig. 1, el. 106; Para. 17); once the signature is created, the device 112 and/or the signing entity 114 submit, to the verifying entity 102, the signature for trust verification, as referenced by 120, wherein the signature can be embedded into the object 106 such that the object 106, along with the embedded signature, can be submitted, for trust verification (Para. 18); an object can comprise a certificate (e.g., of a Secure Sockets Layer (SSL) site), an executable file, or user credentials (Para. 14), and
executes processing on the file, e.g., an object can comprise a certificate (e.g., of a Secure Sockets Layer (SSL) site), an executable file, or user credentials (Para. 14),
the encryption processing device comprising
at least one of a circuit and a processor with a memory storing computer program code executable by the processor, e.g., the verifying entity 102 is also comprised of one or more devices configured with processing and/or memory resources that can connect to a network 116 (Fig. 1, el. 116; Para. 19), configured to serve as:
a reception unit, e.g., the verifying entity 102 is also comprised of one or more devices configured with processing and/or memory resources that can connect to a network 116 (Fig. 1, el. 116; Para. 19), configured to receive the file, e.g., once the signature is created, the device 112 and/or the signing entity 114 submit, to the verifying entity 102, the signature for trust verification, as referenced by 120 (Fig. 1, el. 112, 114, 120; Para. 18);
a security strength comparison unit, e.g., invalidity event determination module 206 (Fig. 2, el. 206), configured to compare a first security strength, which is a security strength of encryption used to encrypt the information, with a second security strength, which is a security strength of encryption used to encrypt information…, e.g., an invalidity event associated with a signature can alternatively or additionally comprise a recent determination of a previously unknown weakness in the signature, wherein a weakness can be related to an insufficient key size or key length, and a weakness can be related to a compromised or broken signature algorithm (e.g., Security Hash Algorithm-1 (SHA1) is broken and Security Hash Algorithm-2 (SHA2) should be used instead) (Para. 26); the private key is used to sign (e.g., encrypt, encode, etc.) a hash of an object to create the signature (Para. 14); and
….
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hall to include an encryption processing device that receives a file that records encrypted information from an external device, and executes processing on the file, the encryption processing device comprising: a security strength comparison unit configured to compare a first security strength, which is a security strength of encryption used to encrypt the information, with a second security strength, which is a security strength of encryption used to encrypt information included in a previously received file, using the known method of determining a signature has an insufficient key length or uses a compromised or broken signature algorithm, as taught by Janjua, in combination with the software package security index comparison techniques of Hall, for the purpose of increasing the security of the communication system and the receiver by aiding in the prevention of installing malicious software packages.
Regarding claim 15, Hall in view of Janjua teaches the encryption processing device according to claim 14, wherein the file utilization processing execution unit decrypts or stores the information or downloads the information as the processing for utilizing the file, e.g., install/update utility 610 may also compare the security index score of software package 602 to a predetermined threshold or a security index score of a previous version of the software in application storage 612 (Hall-Para. 48); install/update utility 610 may then ensure that the security index for software applications generally increase or at least remain above an acceptable threshold, wherein if the security index 604 is not above a critical threshold, install/update utility 610 may refuse to install software package 602 to application storage 612, and if the security index 604 is not above a warning threshold, install/update utility 610 may warn the user of the security level of the software package and prompt the user for instructions as to whether to continue installation (Hall-Para. 49).
Claims 3, 9, 10, 16, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Hall in view of Janjua and further in view of Yoshimi et al. (US 2022/0284743 A1).
Regarding claim 3, Hall in view of Janjua teaches the signature verification device according to claim 2.
Hall further teaches wherein the signature verification device is an update control device that controls an update of software, that is the information, for an update target device that is an update target of the software,…, e.g., install/update utility 610 may also compare the security index score of software package 602 to a predetermined threshold or a security index score of a previous version of the software in application storage 612 (Hall-Para. 48); install/update utility 610 may then ensure that the security index for software applications generally increase or at least remain above an acceptable threshold, wherein if the security index 604 is not above a critical threshold, install/update utility 610 may refuse to install software package 602 to application storage 612, and if the security index 604 is not above a warning threshold, install/update utility 610 may warn the user of the security level of the software package and prompt the user for instructions as to whether to continue installation (Hall-Para. 49).
Hall in view of Janjua does not clearly teach wherein the signature verification device is an update control device that controls an update of software, that is the information, for an update target device that is an update target of the software, among a plurality of connected electronic control units, and the file utilization processing execution unit transmits the file to the update target device as the processing for utilizing the file.
Yoshimi teaches wherein the signature verification device, e.g., master device 11 that includes a central ECU 13 (Fig. 1, el. 11, 13; Para. 28); the MAC signature is verified using the common key A for the data of buffer size (S41) (Fig. 13, el. S41; Para. 76), is an update control device that controls an update of software, that is the information, for an update target device that is an update target of the software, among a plurality of connected electronic control units, e.g., ECUs 19 (Fig. 1, el. 19), and the file utilization processing execution unit transmits the file to the update target device as the processing for utilizing the file, e.g., If the verification is successful (S42:Yes), the streaming data is transferred to the target ECU 19 (S43) (Fig. 13, el. S42, S43; Para. 77); a software package is a unit of installation processing performed by an ECU, and includes, for example, an executable file of one or more applications developed on an AP, an OS or firmware update file, configuration data, calibration data, and the like (Para. 53).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hall in view of Janjua to include wherein the signature verification device is an update control device that controls an update of software, that is the information, for an update target device that is an update target of the software, among a plurality of connected electronic control units, and the file utilization processing execution unit transmits the file to the update target device as the processing for utilizing the file, using the known method of enabling a central ECU to receive a software update package intended for a target ECU, verify the signature, and transmit the software to the target ECU, as taught by Yoshimi, in combination with software update verification system of Hall in view of Janjua, for the purpose of increasing the security of the communication system and the receiver by verifying the software update. Another benefit of the combination is to comply with the need to rewrite (or overwrite, or “reprog”) an application program of the ECU, is increasing due to many version upgrades for to functional improvements (Yoshimi-Para. 3).
Regarding claim 9, Hall in view of Janjua in view of Yoshimi teaches the signature verification device according to claim 1.
Hall in view of Janjua does not clearly teach wherein the signature verification device is mounted on a moving object.
Yoshimi further teaches wherein the signature verification device is mounted on a moving object, e.g., the vehicle-side system 4 has a master device 11, wherein the master device 11 includes a DCM (Data Communication Module) 12 and a central ECU 13 (Fig. 1, el. 4, 11, 12, 13; Para. 28); in addition to the first bus 14, a second bus 15, a third bus 16, a fourth bus 17, and a fifth bus 18 are connected to the central ECU 13 as buses inside the vehicle, and various types of ECUs 19 are connected via the buses 15 to 17 (Fig. 1, el. 19; Para. 30).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hall in view of Janjua to include wherein the signature verification device is mounted on a moving object, using the known system including a plurality of ECUs and a master device on the vehicle, as taught by Yoshimi, in combination with software update verification system of Hall in view of Janjua, for the purpose of increasing the security of the communication system and the receiver by verifying the software update. Another benefit of the combination is to comply with the need to rewrite (or overwrite, or “reprog”) an application program of the ECU, is increasing due to many version upgrades for to functional improvements (Yoshimi-Para. 3).
Regarding claim 10, Hall in view of Janjua in view of Yoshimi teaches the signature verification device according to claim 3.
Hall in view of Janjua does not clearly teach wherein the signature verification device is mounted on a moving object together with the electronic control unit.
Yoshimi further teaches wherein the signature verification device is mounted on a moving object together with the electronic control unit, e.g., the vehicle-side system 4 has a master device 11, wherein the master device 11 includes a DCM (Data Communication Module) 12 and a central ECU 13 (Fig. 1, el. 4, 11, 12, 13; Para. 28); in addition to the first bus 14, a second bus 15, a third bus 16, a fourth bus 17, and a fifth bus 18 are connected to the central ECU 13 as buses inside the vehicle, and various types of ECUs 19 are connected via the buses 15 to 17 (Fig. 1, el. 19; Para. 30).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hall in view of Janjua to include wherein the signature verification device is mounted on a moving object together with the electronic control unit, using the known system including a plurality of ECUs and a master device on the vehicle, as taught by Yoshimi, in combination with software update verification system of Hall in view of Janjua, using the same motivation as in claim 3.
Regarding claim 16, Hall in view of Janjua teaches signature verification device according to claim 1.
Hall in view of Janjua does not clearly teach wherein the signature verification device is mounted on a vehicle and is connected to a plurality of electronic control units via an in-vehicle communication network including at least one of a controller area network (CAN), a local interconnect network (LIN), and Ethernet.
Yoshimi teaches wherein the signature verification device, e.g., master device 11 that includes a central ECU 13 (Fig. 1, el. 11, 13; Para. 28); the MAC signature is verified using the common key A for the data of buffer size (S41) (Fig. 13, el. S41; Para. 76), is mounted on a vehicle and is connected to a plurality of electronic control units, e.g., ECUs 19 (Fig. 1, el. 19), via an in-vehicle communication network including at least one of a controller area network (CAN), a local interconnect network (LIN), and Ethernet, e.g., the buses 14 to 18 on the inside of the vehicle and the buses 21 on the outside of the vehicle are composed of, for example, CAN (Controller Area Network) buses, and the central ECU 13 performs data communication according to a CAN data communication standard with the DCM 12, various ECUs 19, and the tool 23 (Para. 33).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hall in view of Janjua to include wherein the signature verification device is mounted on a vehicle and is connected to a plurality of electronic control units via an in-vehicle communication network including at least one of a controller area network (CAN), a local interconnect network (LIN), and Ethernet, using the known method of enabling a central ECU to receive a software update package intended for a target ECU, verify the signature, and transmit the software to the target ECU, wherein the ECUs communicate via a CAN, as taught by Yoshimi, in combination with software update verification system of Hall in view of Janjua, for the purpose of increasing the security of the communication system and the receiver by verifying the software update. Another benefit of the combination is to comply with the need to rewrite (or overwrite, or “reprog”) an application program of the ECU, is increasing due to many version upgrades for to functional improvements (Yoshimi-Para. 3).
Regarding claim 17, Hall in view of Janjua teaches signature verification device according to claim 1.
Hall in view of Janjua does not clearly teach wherein the signature verification device is provided in an integrated ECU that controls a plurality of electronic control units mounted on a vehicle.
Yoshimi teaches wherein the signature verification device, e.g., master device 11 that includes a central ECU 13 (Fig. 1, el. 11, 13; Para. 28); the MAC signature is verified using the common key A for the data of buffer size (S41) (Fig. 13, el. S41; Para. 76), is provided in an integrated ECU that controls a plurality of electronic control units, e.g., ECUs 19 (Fig. 1, el. 19), mounted on a vehicle, e.g., the buses 14 to 18 on the inside of the vehicle and the buses 21 on the outside of the vehicle are composed of, for example, CAN (Controller Area Network) buses, and the central ECU 13 performs data communication according to a CAN data communication standard with the DCM 12, various ECUs 19, and the tool 23 (Para. 33).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hall in view of Janjua to include wherein the signature verification device is provided in an integrated ECU that controls a plurality of electronic control units mounted on a vehicle, using the known method of enabling a central ECU to receive a software update package intended for a target ECU, verify the signature, and transmit the software to the target ECU, wherein the ECUs communicate via a CAN, as taught by Yoshimi, in combination with software update verification system of Hall in view of Janjua, for the purpose of increasing the security of the communication system and the receiver by verifying the software update. Another benefit of the combination is to comply with the need to rewrite (or overwrite, or “reprog”) an application program of the ECU, is increasing due to many version upgrades for to functional improvements (Yoshimi-Para. 3).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Hall in view of Janjua in view of Yoshimi and further in view of Kolodner et al. (US 2015/0058301 A1).
Regarding claim 6, Hall in view of Janjua in view of Yoshimi teaches the signature verification device according to claim 3.
Hall further teaches …the signature includes…an entire signature generated based on the file, e.g., security index 552 includes a digital signature of the trusted third party, which is based on a hash of the source code (Hall-Para. 45), and
the file utilization processing execution unit executes the processing for utilizing the file when at least one of first security strengths…is higher than the second security strength…, e.g., install/update utility 610 may also compare the security index score of software package 602 to a predetermined threshold or a security index score of a previous version of the software in application storage 612 (Hall-Para. 48); install/update utility 610 may then ensure that the security index for software applications generally increase or at least remain above an acceptable threshold, wherein if the security index 604 is not above a critical threshold, install/update utility 610 may refuse to install software package 602 to application storage 612, and if the security index 604 is not above a warning threshold, install/update utility 610 may warn the user of the security level of the software package and prompt the user for instructions as to whether to continue installation (Hall-Para. 49).
Hall does not clearly teach wherein the file includes a plurality of pieces of software, the signature includes a plurality of individual signatures generated respectively based on the plurality of pieces of software and an entire signature generated based on the file, and the file utilization processing execution unit executes the processing for utilizing the file when at least one of first security strengths of the plurality of individual signatures and the entire signature is higher than the second security strength of a corresponding individual signature or entire signature.
Janjua further teaches the signature includes…an entire signature generated based on the file, and the file utilization processing execution unit executes the processing for utilizing the file when at least one of first security strengths of the plurality of individual signatures and the entire signature is higher than the second security strength of a corresponding individual signature or entire signature, e.g., an invalidity event associated with a signature can alternatively or additionally comprise a recent determination of a previously unknown weakness in the signature, wherein a weakness can be related to an insufficient key size or key length, and a weakness can be related to a compromised or broken signature algorithm (e.g., Security Hash Algorithm-1 (SHA1) is broken and Security Hash Algorithm-2 (SHA2) should be used instead) (Para. 26).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hall to include the file utilization processing execution unit executes the processing for utilizing the file when at least one of first security strengths of the plurality of individual signatures and the entire signature is higher than the second security strength of a corresponding individual signature or entire signature, using the known method of determining a signature has an insufficient key length or uses a compromised or broken signature algorithm, as taught by Janjua, in combination with the software package security index comparison techniques of Hall, using the same motivation as in claim 1.
Hall in view of Janjua in view of Yoshimi does not clearly teach wherein the file includes a plurality of pieces of software, the signature includes a plurality of individual signatures generated respectively based on the plurality of pieces of software and an entire signature generated based on the file, and the file utilization processing execution unit executes the processing for utilizing the file when at least one of first security strengths of the plurality of individual signatures and the entire signature is higher than the second security strength of a corresponding individual signature or entire signature.
Kolodner teaches wherein the file includes a plurality of pieces of software, the signature includes a plurality of individual signatures generated respectively based on the plurality of pieces of software and an entire signature generated based on the file…, e.g., a plurality of signature values may be calculated for data chunks that makes up a target data file (S220), and a unique signature may be calculated for the subject data file based on the individual signatures calculated for the data chunks (S230), and a full file signature may be calculated by concatenating the hash values for the minimal size data chunks and applying a hash function to the concatenation to determine the full file hash signature (Fig. 2, el. S220, S230; Para. 21); the server 120 calculates the signatures for the minimal size data chunks uploaded, stores the signature values, concatenates the signature values together for the minimal data chunks, and calculates a signature for the concatenated version of the signatures (Para. 22).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hall in view of Janjua in view of Yoshimi to include wherein the file includes a plurality of pieces of software, the signature includes a plurality of individual signatures generated respectively based on the plurality of pieces of software and an entire signature generated based on the file, and the file utilization processing execution unit executes the processing for utilizing the file when at least one of first security strengths of the plurality of individual signatures and the entire signature is higher than the second security strength of a corresponding individual signature or entire signature, using the known method of calculating signatures for a plurality of chunks of a file and a signature for the entire file, as taught by Kolodner, in combination with software update verification system of Hall in view of Janjua in view of Yoshimi, for the purpose of aiding in the prevention of unnecessarily or mistakenly preventing the installation of a software update.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Hall in view of Janjua in view of Yoshimi and further in view of Kim et al. (US 2021/0096837 A1).
Regarding claim 7, Hall in view of Janjua in view of Yoshimi teaches the signature verification device according to claim 3.
Hall in view of Janjua in view of Yoshimi does not clearly teach wherein a version of the software included in the received file is lower than a version of software included in the previously received file.
Kim teaches wherein a version of the software included in the received file is lower than a version of software included in the previously received file, e.g., the secure processor 230 may compare the version information of firmware that is operating in the electronic device 200, with the version information of the firmware, included in the update information, wherein the secure processor 230 can prevent the firmware from being updated to a prior version (or a lower version) (Para. 100).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hall in view of Janjua in view of Yoshimi to include wherein a version of the software included in the received file is lower than a version of software included in the previously received file, using the known method of comparing version information of a firmware update with version information for installed firmware, as taught by Kim, in combination with software update verification system of Hall in view of Janjua in view of Yoshimi, for the purpose of aiding in the prevention of unnecessarily or mistakenly rolling-back a software update to an older version.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Hall in view of Janjua in view of Yoshimi and further in view of Kupwade Patil et al. (US 2020/0322135 A1).
Regarding claim 11, Hall in view of Janjua in view of Yoshimi teaches the signature verification device according to claim 3.
Hall in view of Janjua does not clearly teach wherein the electronic control unit is mounted on a moving object, and the signature verification device is disposed outside the moving object.
Yoshimi further teaches wherein the electronic control unit is mounted on a moving object…, e.g., in addition to the first bus 14, a second bus 15, a third bus 16, a fourth bus 17, and a fifth bus 18 are connected to the central ECU 13 as buses inside the vehicle, and various types of ECUs 19 are connected via the buses 15 to 17 (Fig. 1, el. 19; Para. 30).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hall in view of Janjua to include wherein the electronic control unit is mounted on a moving object, using the known system including a plurality of ECUs in the vehicle, as taught by Yoshimi, in combination with software update verification system of Hall in view of Janjua, using the same motivation as in claim 3.
Hall in view of Janjua in view of Yoshimi does not clearly teach the signature verification device is disposed outside the moving object.
Kupwade Patil teaches the signature verification device is disposed outside the moving object, e.g., the signature verification is performed by Road-Side Unit (RSU) RSU 110RSE, wherein the intended recipient is another vehicle, and the message verification is performed by an RSU that is in direct communication with the intended recipient (Para. 96).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hall in view of Janjua in view of Yoshimi to include the signature verification device is disposed outside the moving object, using the known method of performing signature verification at a Road-Side Unit before transmitting the data to the intended vehicle, as taught by Kupwade Pail, in combination with software update verification system of Hall in view of Janjua in view of Yoshimi, for the purpose of reducing the number of required devices onboard the vehicle.
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Hall in view of Janjua in view of Shah et al. (US 2011/0087872 A1) and further in view of Yamashita et al. (US 2013/0156263 A1).
Regarding claim 18, Hall in view of Janjua teaches the signature verification device according to claim 1.
Hall does not clearly teach wherein the security strength of the signature is determined based on an algorithm of a signature method of the signature and a length of a key used for the signature at a time when the signature is received, based on information included in a header of the signature.
Janjua further teaches wherein the security strength of the signature is determined based on an algorithm of a signature method of the signature and a length of a key used for the signature at a time when the signature is received…, e.g., once the signature is created, the device 112 and/or the signing entity 114 submit, to the verifying entity 102, the signature for trust verification, as referenced by 120, wherein the signature can be embedded into the object 106 such that the object 106, along with the embedded signature, can be submitted, for trust verification (Para. 18);
an invalidity event associated with a signature can alternatively or additionally comprise a recent determination of a previously unknown weakness in the signature, wherein a weakness can be related to an insufficient key size or key length, and a weakness can be related to a compromised or broken signature algorithm (e.g., Security Hash Algorithm-1 (SHA1) is broken and Security Hash Algorithm-2 (SHA2) should be used instead) (Para. 26).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hall to include wherein the security strength of the signature is determined based on an algorithm of a signature method of the signature and a length of a key used for the signature at a time when the signature is received, using the known method of determining a signature has an insufficient key length or uses a compromised or broken signature algorithm, as taught by Janjua, in combination with the software package security index comparison techniques of Hall, using the same motivation as in claim 1.
Hall in view of Janjua does not clearly teach wherein the security strength of the signature is determined based on an algorithm of a signature method of the signature and a length of a key used for the signature at a time when the signature is received, based on information included in a header of the signature.
Shah teaches …the signature is determined based on an algorithm of a signature method of the signature and a length of a key used for the signature at a time when the signature is received, based on information included in a header…, e.g., the firmware information signature 224 and the R/W firmware data signature 226 may be generated and verified using a cryptographic hash algorithm that is indicated in the header 216 and a public-key that is included in header 216, as well as a key size for that public-key that may also be indicated in the header 216 (Fig. 2, el. 216; Para. 52).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hall in view of Janjua to include wherein the security strength of the signature is determined based on an algorithm of a signature method of the signature and a length of a key used for the signature at a time when the signature is received, based on information included in a header, using the known method of including the cryptographic hash algorithm and the public key size in the header, as taught by Shah, in combination with software update verification system of Hall in view of Janjua, for the purpose of reducing the amount of processing resources and time required to determine the signature algorithm.
Hall in view of Janjua in view of Shah does not clearly teach wherein the security strength of the signature is determined based on an algorithm of a signature method of the signature and a length of a key used for the signature at a time when the signature is received, based on information included in a header of the signature.
Yamashita teaches …the signature is determined based on an algorithm of a signature method of the signature…based on information included in a header of the signature, e.g., the signature header 501 contains a signature-generation algorithm type field (Fig. 11, el. 501; Para. 97).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hall in view of Janjua in view of Shah to include wherein the security strength of the signature is determined based on an algorithm of a signature method of the signature and a length of a key used for the signature at a time when the signature is received, based on information included in a header of the signature, using the known method of including the signature-generation algorithm type in the signature header, as taught by Yamashita, in combination with software update verification system of method of including algorithm information and key length in the header of Hall in view of Janjua in view of Shah, for the purpose of reducing the amount of processing resources and time required to determine the signature algorithm and more accurately correlating the header to the signature.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Valkaitis (US 2023/0140782 A1)—Valkaitis discloses a signature header (Para. 44, 47).
Shear et al. (US 2006/0248353 A1)—Shear discloses secure computation environments with different tamper resistance work factors use different verification digital signature authentication techniques (e.g., different signature algorithms and/or signature verification keys)--allowing one tamper resistance work factor environment to protect itself against load modules from another, different tamper resistance work factor environment (Abstract).
Crowley (US 2018/0157840 A1)—Crowley discloses during a boot process of a computing device, obtaining a secret key derived from device-specific information for the computing device and verifying that a signature for a software module is valid (Abstract).
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 JEREMY DUFFIELD whose telephone number is (571)270-1643. The examiner can normally be reached Monday - Friday, 7:00 AM - 3:00 PM (ET).
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, Yin-Chen Shaw can be reached at (571) 272-8878. 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.
25 February 2026
/Jeremy S Duffield/Primary Examiner, Art Unit 2498