DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-3 and 22-30 are pending.
The claim objections have been withdrawn in view of the claim amendment.
The 101 rejection has been withdrawn in view of the claim amendment.
Response to Arguments
Applicant's arguments filed on 12/23/25 have been fully considered.
In response to Applicant’s argument regarding the 112(a) rejection, Examiner acknowledged Applicant’s perspective but respectfully disagrees for the reasons provided below.
In response to Applicant’s argument regarding the 103 rejection, Examiner acknowledged Applicant’s perspective but the argument is moot in view of the new ground of rejection presented below in view of newly found prior art Shatharam.
Claim Objections
Claim 23 is objected to because of the following informalities:
“providing” and “receiving” in claim 23 should read “provide” and “receive” respectively.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-3 and 22-30 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 1 recites “establishing, in a trusted execution environment of a computing device, an update for a pre-authentication policy associated with a device in communication with the trusted execution environment of the computing device” and “the runtime update is to be performed to the pre-authentication policy”.
Upon reviewing fig. 4 (410-440) and fig. 5 (520-535) and associated ¶34-37 and 41, it was found that these underlined limitations are still not supported by the specification. Although the specification discloses the trusted security manager (TSM) in a TEE establishing a device update pre-authentication policy for the device and the device performing runtime update. Note that the runtime update is applied to the device itself (e.g. updates to its software and/or firmware, see ¶1, 28) and not to the pre-authentication policy as being claimed. The device only checks the pre-authentication policy to determine whether it needs to perform pre-authentication with the TSM before performing the runtime update (e.g. ¶33, 38). There is no update being performed to the pre-authentication policy.
For at least the above reasons, the specification does not provide sufficient support for the above underlined limitations. Other independent claims reciting the same limitations are also rejected for the same reasons. Dependent claims are also rejected for the same reasons as their independent claims.
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 of this title, 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, 22-24, 26-28 and 30 are rejected under 35 U.S.C. 103 as being unpatentable over Shantharam (US 20180173517) in view of Poiesz (US 20160350561).
Claims 1 and 27, these claims are rejected for similar reasons as in claim 23.
Claims 2 and 28, this claim is rejected for similar reasons as in claim 24.
Claims 22 and 30, this claim is rejected for similar reasons as in claim 26.
Claim 23, Shantharam discloses A computing device comprising:
processing circuitry to:
establish, in a execution environment of the computing device, an update for a pre-authentication policy associated with a device in communication with the execution environment of the computing device; and (e.g. ¶44: When a software update 145 has been specified by an administrator through the administrator console, the computing environment 103 can instruct, the specified client devices 106 to download the software update 145 from the management service 118, the operating system update service 109, or other appropriate service. In one example, the computing environment 103 can generate a deployment profile 139 that is accessed by the agent application 124 which instructs the agent application 124 to download and install a software update 145.)
providing the pre-authentication policy to the device; (e.g. ¶27, 39: [0027] Through the administrator console, a deployment profile can be generated and published that causes the agent application 124 to configure the device in accordance with the deployment profile, [0039] Additionally, the agent application 124 can ensure that various actions are not taken on the client device 106. For instance, the agent application 124 can ensure that the software update 145 is not installed on the client device 106 until authorized by an administrator of the management service 118. In one example, the agent application 124 can configure the operating system 166 of the client device 106 to disable automatic updates. In another example, a setting can be configured by the agent application 124 on the client device 106 that requires administrator approval before installing any software updates 145. Once an administrator pushes this setting, for example, through a deployment profile 139, the client device 106 will not install any software updates 145 until an administrator approves the software updates 145.)
receiving, from the device, a pre-authentication signal; and (e.g. ¶39, 64-65, 68: [0039] When a software update 145 is identified as being available on a client device 106, the agent application 124 can communicate information pertaining to the software update 145 to the management service 118 over the network 112. For example, the agent application 124 can send an identifier 148 that uniquely identifies the software update 145 to the management service 118, [0064] In step 603, the identifier 148 for a software update 145 received from a client device 106 can be accessed for analysis. For example, additional information pertaining to the software update 145 (as described below in step 606) can be accessed using the identifier 148 to assist the administrator in determining…whether an author of the software update 145 is trusted, or other determination, [0065] For example, an administrator can view information associated with the software update 145 in an administrator console to,…determine whether an author of the software update 145 is a trustworthy source…For instance, certain characteristics of a software update 145 can indicate a trustworthiness of the software update 145, such as a type of the update, a revision number, or a publication date indicative of the software update 145, [0068] Even further, an administrator can inspect an author or an original source of a software update 145, or whether the software update 145 is a WSUS infrastructure update, to determine whether the software update 145 is from a trusted source.)
provide, to the device, an indicator of whether a runtime update is acceptable and the runtime update is to be performed to the pre-authentication policy. (e.g. ¶44-45: [0044] When a software update 145 has been specified by an administrator through the administrator console, the computing environment 103 can instruct, the specified client devices 106 to download the software update 145 from the management service 118, the operating system update service 109, or other appropriate service. In one example, the computing environment 103 can generate a deployment profile 139 that is accessed by the agent application 124 which instructs the agent application 124 to download and install a software update 145. In some examples, the deployment profile 139 is an XML document or similar type of file, [0045] Through a deployment profile 139, the computing environment 103 can instruct the agent application 124 executing on the client device 106 to perform a download, and an installation of the software update 145. For example, the deployment profile 139 can instruct client devices 106 to download the software update 145 from the management service 118, the operating system update service 109, or other suitable service. While the, user interface 169 of FIG. 1 shows an installation of a software update 145 in the display 172, the installation of a software update 145 can be a silent installation, or an installation performed as a background process where no user input is required.)
Although Shantharam discloses an execution environment of the computing device (see above), Shantharam does not appear to explicitly disclose but Poiesz discloses a trusted execution environment of the computing device (e.g. fig. 1, ¶21-22, 46: Processor 102 implements a trusted execution environment (TEE) 106…processor 102 may execute, in TEE 106, one or more TEE processes 110…when a TEE process updates a policy, the TEE process cryptographically protects the updated policy.).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the features described by Poiesz into the invention of Shantharam for the purpose of cryptographically protecting the updated deployment profile (Poiesz, ¶46).
Claim 24, Shantharam-Poiesz discloses The computing device of claim 23, wherein the processing circuitry is further to: provide the update to the device; (Shantharam, e.g. ¶44) receive, from the device, a pre-authentication event signal indicating the device is ready to perform the update to the pre-authentication policy, (Shantharam, e.g. ¶39, 64-65, 68) wherein the pre-authentication policy is based on a binary value. (Shantharam, e.g. ¶31)
Claim 26, Shantharam-Poiesz discloses The computing device of claim 23, wherein the processing circuitry comprises one or more of application processing circuitry or graphics processing circuitry, (Shantharam, e.g. ¶18) wherein the computing device and the device are in communication over one or more communication networks including the Internet. (Shantharam, e.g. ¶17)
Claim 3, 25, and 29 are rejected under 35 U.S.C. 103 as being unpatentable over Shantharam (US 20180173517) in view of Poiesz (US 20160350561) and further in view of Patel (US 20200160338).
Claims 3 and 29, this claim is rejected for similar reasons as in claim 25.
Claim 25, Shantharam-Poiesz discloses The computing device of claim 23, (see above) and does to appear to explicitly disclose but Patel discloses wherein to receive the pre-authentication event signal comprises to receive one or more of a firmware secure version number, a debug mode firmware image, a device firmware measurement, or a firmware certificate. (e.g. ¶218-219).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the features described by Patel into the invention of Shantharam-Poiesz for the purpose of enabling the server to determine whether to permit or decline the firmware update request (Patel, ¶219).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Nagamitsu (US 20220012038) discloses the communication unit 27 can receive a software update confirmation request from the software update device 11. The update confirmation request is, for example, information transmitted from the software update device 11 to the server 1 when power supply or ignition is turned on in the vehicle, and is information for requesting the server 1 to confirm whether there is update data of the electronic control unit. Further, the communication unit 27 receives a transmission request (download request) of a distribution package from the software update device 11. Upon receiving the download request of the distribution package, the communication unit 27 transmits, to the software update device 11, instruction information instructing whether approval is required at the time of execution of the software update process… when the life cycle status information set in the update management information is “1” or “2” in FIG. 6, the control unit 28 generates instruction information indicating that approval at the time of update process is not required. When the life cycle status information set in the update management information is “3” to “7” in FIG. 6, the control unit 28 generates instruction information indicating that approval at the time of update process is required.
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 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 TRONG NGUYEN whose telephone number is (571)270-7312. The examiner can normally be reached on Monday through Thursday 9:30 AM - 5:00 PM EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, GELAGAY SHEWAYE can be reached on (571)272-4219. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/TRONG H NGUYEN/Primary Examiner, Art Unit 2436
Prosecution Insights