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 .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claims 1-3 and 22-30 are pending.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 08/12/26 has been entered.
Response to Arguments
Applicant's arguments filed on 08/12/26 have been fully considered.
In response to Applicant’s argument regarding the 112(a) rejection, Examiner acknowledged Applicant’s perspective but the amendments have not fully addressed the lack of support issue.
Claim 1 recites “receiving, from the device, a pre-authentication event signal indicating the device is ready to update the pre-authentication policy that is based on a binary value” and “providing, 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”.
Upon careful review of fig. 4 (410-440) and fig. 5 (520-535) and associated ¶34-37 and 41 which Applicant mentioned as providing support for the claim limitations, it was found that the above underlined limitations are not supported by the specification. These figures and paragraphs mention “runtime update” and “device update” but they do not describe updating the pre-authentication policy as claimed. It is respectfully requested that Applicant cites the exact language from the specification that provides support for the above underlined limitations.
In response to Applicant’s argument regarding the 103 rejection, Examiner acknowledged Applicant’s perspective but respectfully disagreed for the following reasons.
Shantharam discloses “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” (¶27), and “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” (¶39).
Thus, Shantharam discloses a device update pre-authentication policy established in an execution environment and used to gate a runtime update of the client device. Shantharam does not appear to explicitly disclose that the execution environment is trusted.
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 policy (Poiesz, ¶46) thereby increasing the security of the system.
For at least the above reasons, the combined teachings of Shantharam and Poiesz does disclose or suggest the limitations recited in claim 1.
Claim Objections
Claims 2, 24, and 28 objected to because of the following informalities:
“the update” in claims 2, 24, and 28 lacks antecedent basis.
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 “receiving, from the device, a pre-authentication event signal indicating the device is ready to update the pre-authentication policy that is based on a binary value” and “providing, 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”.
Upon careful review of fig. 4 (410-440) and fig. 5 (520-535) and associated ¶34-37 and 41 which Applicant mentioned as providing support for the claim limitations, it was found that the above underlined limitations are not supported by the specification. The figures and paragraphs mention “runtime update” and “device update” but they do not describe updating the pre-authentication policy as claimed. It is respectfully requested that Applicant cites the exact language from the specification that provides support for the above underlined limitations.
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, a device update 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.)
provide the device update 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.)
receive, from the device, a pre-authentication event signal indicating the device is ready to update the pre-authentication policy that is based on a binary value; 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… 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, [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 policy (Poiesz, ¶46) thereby increasing the security of the system.
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.
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:00 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