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 . The present office action is responsive to communication received 2/11/2026.
Claims 21, 25, 31, and 35 have been amended.
Claims 24 and 34 have been canceled.
Claims 21-23, 25-33, and 35-42 are pending.
Response to Arguments
Applicant's arguments filed 2/11/2026 have been fully considered but they are not persuasive.
Applicant argues : “disclose that the version information of the first version has a version number that is a version number of the version information of the first version. Similarly, Chen doesn't disclose that the check bit corresponding to the version number of the first version has a version number that is a version number of the check bit and using version numbers to verify the version information itself.”
The examiner respectfully answers that reference Basehore is the reference that is being used to disclose “using version numbers to verify the version information itself”. Although Basehore does not specifically list first version and second version, it can be seen that the “latest” and “current” software’s are two versions which are being compared. We can see Basehore [0043] that the current software and latest software are being compared and in order to see if the latest version is secure. This comparison is being done in the claim limitations as it is mentioned the first and second version are being compared in order to determine if the second version is secure or not.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 21-23, 25-26, 29, 31-33, 35-36, 39, and 41-42 are rejected under 35 U.S.C. 103 as being unpatentable over Chen et al. (WO 2018090818) in view of Basehore et al. (US 20190018964).
Regarding claim 21,
Chen discloses a method, applied to a network device on which software is deployed, the method comprising:
obtaining a version file,
[obtains the version information of the first version (Chen et al., page 2, in the paragraph starting with “In a scenario where the operating system or the application needs to be safely started or upgraded”)]
wherein the version file is a file that passes security verification,
[a signature authentication module 505, configured to perform signature verification on the version information of the first version (Chen et al., page 7, in the paragraph starting with “In some implementations, the device further includes: a signature authentication module 505”)]
the version file comprises one or more software version identifiers, and a first version number, and the first version number indicates a version of the version file
[where the version information includes the version number of the first version, where the version number is used to identify the first version (Chen et al., page 2, in the paragraph starting with “In a scenario where the operating system or the application needs to be safely started or upgraded”)
and determining, based on the one or more software version identifiers and the first version identifier, that the version of the to-be-loaded software is the secure software version, and loading the to-be-loaded software.
[the device further includes: a security startup module, configured to not start the first version when the first version verification fails, and start the first version when the first version verification passes. (Chen et al., page 4, In paragraph starting with “With reference to any possible implementation of the second aspect, in a second possible implementation manner of the second aspect, the version information acquiring module is configured to”, loading/starting version when verification passes)]
Chen fails to explicitly disclose a first version number, and the first version number indicates a version of the version file and one or more software version identifiers are usable to determine a secure software version obtaining a second version number stored in a secure storage area in the network device and determining, in response to the second version number being less than or equal to the first version number, that the version of the version file is a secure software version and obtaining a first version identifier, wherein the first version identifier indicates a version of to-be-loaded software
However in an analogous art Basehore discloses
and a first version number, and the first version number indicates a version of the version file
[a current software that the computing device is configured to execute is determined to correspond or not correspond with the latest software based on the received message. (Basehore et al., paragraph 43, current software and latest software are two versions of a software which indicates the version of the software, one can be first version and the other being the second version as they are compared to determine whether or not they correspond)]
the one or more software version identifiers are usable to determine a secure software version;
[determining whether the software to be loaded corresponds with the latest software version number, the secure watchdog 128 can verify the latest software is loaded and prevent software that may be contaminated and/or vulnerable to a persistent attack from loading. (Basehore et al., paragraph 55)]
obtaining a second version number stored in a secure storage area in the network device
[retrieve the latest software from the update server 104, store the latest software in the computer-readable storage media 122, (Basehore et al., paragraph 24, latest software being the second version number)]
and determining, in response to the second version number being less than or equal to the first version number, that the version of the version file is a secure software version
[determining whether the software to be loaded corresponds with the latest software version number, the secure watchdog 128 can verify the latest software is loaded and prevent software that may be contaminated and/or vulnerable to a persistent attack from loading (Basehore et al., paragraph 55, latest versions have a greater number than previous and are seen to be vulnerable or contaminated meaning anything less or equal is “safe”/ secure)]
obtaining a first version identifier, wherein the first version identifier indicates a version of to-be-loaded software;
[The update server 104 is configured to send a message to the computing device 102 regarding a latest software available via the update server 104. The message can include information uniquely identifying the latest software, such as a time stamp for when the latest software became available on the update server 104 and/or a latest software version number associated with the latest software. (Basehore et al., paragraph 18)]
Chen and Basehore are considered to be analogous to the claimed invention because they are in the same field of software verification. Therefore, it would have been obvious to one of ordinary skill in the art before the instant application effective filing date to have modified the teachings of Chen to incorporate the teachings of Basehore et al. to include the one or more software version identifiers are usable to determine a secure software version and obtaining a first version identifier, wherein the first version identifier indicates a version of to-be-loaded software, in order to verify the latest software is loaded and prevent software that may be contaminated and/or vulnerable to a persistent attack from loading. (Basehore et al., paragraph 55)]
Regarding claim 31,
Chen discloses an apparatus, comprising:
a memory storing instructions;
and at least one processor in communication with the memory, the at least one processor being configured, upon execution of the instructions, to perform the following steps
[a processor, and a memory connected to each other; the memory is configured to store the program code, and the processor calls the program code in the memory to execute All or part of the steps in the first aspect (Chen et al., page 4, in the paragraph starting with “In a fourth aspect, an embodiment of the present invention further provides a terminal device, where the terminal device includes”)]
The claim recites substantially the same content as claim 1 and is rejected with the rationales set forth for claim 21.
Regarding claims 22 and 32,
Chen in view of Basehore discloses the method according to claim 21 and the apparatus according to claim 31,
wherein the one or more software version identifiers indicate a disabled software version;
[if the parity bit corresponding to the version number of the first version is the first value, it is determined that the first version is disabled, and the first version is verified (Chen et al., page 2, in the paragraph starting with “In a scenario where the operating system or the application needs to be safely started or upgraded”)]
and wherein determining, based on the one or more software version identifiers and the first version identifier, that the version of the to-be-loaded software is the secure software version comprises: determining, in response to the one or more software version identifiers being all different from the first version identifier, that the version of the to-be-loaded software is the secure software version.
[determining whether the software to be loaded corresponds with the latest software version number, the secure watchdog 128 can verify the latest software is loaded and prevent software that may be contaminated and/or vulnerable to a persistent attack from loading. (Basehore et al., paragraph 55, latest version number is different than the first version)]
Chen and Basehore are considered to be analogous to the claimed invention because they are in the same field of software verification. Therefore, it would have been obvious to one of ordinary skill in the art before the instant application effective filing date to have modified the teachings of Chen to incorporate the teachings of Basehore et al. to include determining, in response to the one or more software version identifiers being all different from the first version identifier, that the version of the to-be-loaded software is the secure software version, in order to verify the latest software is loaded and prevent software that may be contaminated and/or vulnerable to a persistent attack from loading. (Basehore et al., paragraph 55)]
Regarding claim 23 and 33,
Chen in view of Basehore discloses the method according to claim 21 and the apparatus according to claim 31,
wherein the one or more software version identifiers indicate the secure software version;
[determining whether the software to be loaded corresponds with the latest software version number, the secure watchdog 128 can verify the latest software is loaded and prevent software that may be contaminated and/or vulnerable to a persistent attack from loading. (Basehore et al., paragraph 55)]
and wherein determining, based on the one or more software version identifiers and the first version identifier, that the version of the to-be-loaded software is the secure software version comprises:
determining, in response to a software version identifier that is the same as the first version identifier existing in the one or more software version identifiers, that the version of the to-be-loaded software is the secure software version.
[the secure watchdog 128 can be incorporated as part of the boot-up process and can ensure the computing device 102 loads the latest software during the boot-up process. By storing the information associated with the latest software and determining whether the software to be loaded corresponds with the latest software version number, the secure watchdog 128 can verify the latest software is loaded and prevent software that may be contaminated and/or vulnerable to a persistent attack from loading. Furthermore, the secure watchdog 128 can influence the boot-up process to load recovery software and cause the processor to operate according to a recovery mode, further protecting the computing device 102 from being influenced by the persistent attack. (Basehore et al., paragraph 55)]
Chen and Basehore are considered to be analogous to the claimed invention because they are in the same field of software verification. Therefore, it would have been obvious to one of ordinary skill in the art before the instant application effective filing date to have modified the teachings of Chen to incorporate the teachings of Basehore et al. to include the wherein the one or more software version identifiers indicate the secure software version and wherein determining, based on the one or more software version identifiers and the first version identifier, that the version of the to-be-loaded software is the secure software version comprises: determining, in response to a software version identifier that is the same as the first version identifier existing in the one or more software version identifiers, that the version of the to-be-loaded software is the secure software version, in order to verify the latest software is loaded and prevent software that may be contaminated and/or vulnerable to a persistent attack from loading. (Basehore et al., paragraph 55)]
Regarding claims 25 and 35,
Chen in view of Basehore discloses the method according to claim 21 and the apparatus according to claim 31,
wherein the secure storage area comprises a trusted platform module or an electronic fuse (eFUSE).
[The bits are stored in a first field of the electronic fuse metal fuse eFuse (Chen et al., page 3, in the paragraph starting with “With reference to the first aspect, or the first possible implementation manner of the first aspect”)]
Regarding claims 26 and 36,
Chen in view of Basehore discloses the method according to claim 21 and the apparatus according to claim 31, wherein the version file further comprises
a digital signature of the version file;
[The system startup code generates a message digest, and then encrypts the message digest using the Efuse private key, that is, digital signature (Chen et al., page 6, in the paragraph starting with “The chip vendor randomly generates an asymmetric key pair, and burns the public key hash value and the private key index into Efuse”)]
Regarding claims 29 and 39,
Chen in view of Basehore discloses the method according to claim 21 and the apparatus according to claim 31,
wherein the version file further comprises a product type identifier, and the product type identifier indicates a product type of the network device to which the version file is applicable.
[The software may be an operating system or an application on the system. For example: system security boot of ARM architecture, version verification of scenarios such as secure startup of an application. (Chen et al., page 4, in the paragraph starting with “The embodiment of the present invention is applicable to a scenario in which software can be upgraded”)]
Regarding claims 41 and 42,
Chen in view of Basehore discloses the method according to claim 21 and the apparatus according to claim 31, wherein the one or more software version identifiers comprise software version identifiers of a plurality of different software.
[responsive to the latest software not being stored, the computing device is caused to operate in a recovery mode, similar to 212 in FIG. 2. (Basehore et al., paragraph 47, different software as it is not stored)]
Chen and Basehore are considered to be analogous to the claimed invention because they are in the same field of software verification. Therefore, it would have been obvious to one of ordinary skill in the art before the instant application effective filing date to have modified the teachings of Chen to incorporate the teachings of Basehore et al. to include wherein the one or more software version identifiers comprise software version identifiers of a plurality of different software, in order to verify the latest software is loaded and prevent software that may be contaminated and/or vulnerable to a persistent attack from loading. (Basehore et al., paragraph 55)]
Claims 27 and 37 are rejected under 35 U.S.C. 103 as being unpatentable over Chen et al. (WO 2018090818) in view of Basehore et al. (US 20190018964) in further view of Richardson et al. (US 20160321452).
Regarding claims 27 and 37,
Chen in view of Basehore discloses the method according to claim 21 and the apparatus according to claim 31, but fail to explicitly disclose wherein the one or more software version identifiers are respectively hash values of one or more software files.
However in an analogous art Richardson discloses wherein the one or more software version identifiers are respectively hash values of one or more software files.
[ an identifier can be sent for the app (e.g., package name or hash of the app) to the server (e.g., side-load server 150), which may have other information about the origin and channel ID of the app, and the app identifier is used at the server to determine whether the app should be trusted or not. (Richardson et al., paragraph 237)]
Chen, Basehore, Richardson are considered to be analogous to the claimed invention because they are in the same field of software verification. Therefore, it would have been obvious to one of ordinary skill in the art before the instant application effective filing date to have modified the teachings of Chen and Basehore to incorporate the teachings of Richardson et al. to include wherein the one or more software version identifiers are respectively hash values of one or more software files, in order to determine whether the app should be trusted or not. (Richardson et al., paragraph 237)]
Claims 28 and 38 are rejected under 35 U.S.C. 103 as being unpatentable over Chen et al. (WO 2018090818) in view of Basehore et al. (US 20190018964) in further view of Koller et al. (US 9917841).
Regarding claims 28 and 38,
Chen in view of Basehore discloses the method according to claim 21 and the apparatus according to claim 31, but fail to explicitly disclose wherein the version file further comprises one or more processor models, the one or more processor models respectively correspond to the one or more software version identifiers, and the one or more processor models indicate one or more processors that are in the network device and that are configured to load software corresponding to the one or more software version identifiers.
However in an analogous art Koller discloses wherein the version file further comprises one or more processor models, the one or more processor models respectively correspond to the one or more software version identifiers, and the one or more processor models indicate one or more processors that are in the network device and that are configured to load software corresponding to the one or more software version identifiers.
[To the extent a particular signature 144 is different across different models of a UE, a UE model identifier may be stored with each such signature 144. The signatures that are potentially relevant to a given model of UE 102 may be provided by the server 140 to the UE. The branding application 120 on the UE 102 may initiate the request to receive signatures 144 from the server that correspond to that particular UE. (Koller et al., column 6, lines 58-65)]
Chen, Basehore, Koller are considered to be analogous to the claimed invention because they are in the same field of software verification. Therefore, it would have been obvious to one of ordinary skill in the art before the instant application effective filing date to have modified the teachings of Chen and Basehore to incorporate the teachings of Koller et al. to include wherein the version file further comprises one or more processor models, the one or more processor models respectively correspond to the one or more software version identifiers,
and the one or more processor models indicate one or more processors that are in the network device and that are configured to load software corresponding to the one or more software version identifiers, in order to generate an alert when an application on the UE violates an applicable usage profile. (Koller et al., column 10, lines 63-64)]
Claims 30 and 40 are rejected under 35 U.S.C. 103 as being unpatentable over Chen et al. (WO 2018090818) in view of Basehore et al. (US 20190018964) in further view of Carter et al. (US 8522232).
Regarding claims 30 and 40,
Chen in view of Basehore discloses the method according to claim 21 and the apparatus according to claim 31, but fail to explicitly disclose obtaining a new version file via a network; and replacing the version file in the network device with the new version file.
However in an analogous art Carter discloses obtaining a new version file via a network; and replacing the version file in the network device with the new version file.
[if the load version identified by the software update message differs from the current software load being used by the module identified by the MIB object identifier, the load version identified by the software update message can be retrieved and can replace the load used by the module load 260, 270 corresponding to the MIB object identifier. (Carter et al., column 3, lines 32-38)]
Chen, Basehore, and Carter are considered to be analogous to the claimed invention because they are in the same field of software verification. Therefore, it would have been obvious to one of ordinary skill in the art before the instant application effective filing date to have modified the teachings of Chen and Basehore to incorporate the teachings of Carter et al. to include obtaining a new version file via a network; and replacing the version file in the network device with the new version file, in order to facilitate updating software on CPE devices without requiring recertification. (Carter et al., column 1, lines 51-53)]
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure
Scott et al. (US 20220300478) discloses A version match being determined determined between the expected version and a current version of the object. When the version match is successful, the update is applied to the object.
Tu et al. (US 20230351050) discloses acquiring a first version number of the resource file through a device management interface, and sending the first version number to the application market server, where the first version number is used to instruct the application market server to acquire a second version number of the resource file, and comparing the first version number with the second version number; receiving a new resource file returned by the application market server when the first version number and the second version number are inconsistent; and replacing the resource file in the device operation service with the new resource file.
Applicant’s amendment necessitated the new ground(s) of rejection presented in this Office action. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee 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 DANIEL ELAHIAN whose telephone number is (703) 756-1284. The examiner can normally be reached on Monday – Friday from 7:30am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Catherine Thiaw can be reached at telephone number 571-270-1138. 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 Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR for authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/D.E./DANIEL ELAHIAN, Examiner, Art Unit 2407
/Catherine Thiaw/Supervisory Patent Examiner, Art Unit 2407 4/3/2026