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 .
This Office Action is in response to the Request for Continuation filed on 01/26/2026.
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 01/26/2026 has been entered.
Response to Arguments
Applicant's arguments filed 01/02/2025 regarding claims 1, 13 and 20 have been considered but are moot in view of the new ground(s) of rejection, which were necessitated by amendment.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph 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.
Claimsare 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 applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 1 and 20 recite "generating, using the security context, an attestation result indicating whether the attestation information satisfies an appraisal condition". Although the Specification discloses establishment of a security context following authentication (e.g., para [0123]) and separately discloses generating an attestation result based on attestation information and an appraisal policy (e.g., para [0124]-[0129]), the Specification does not reasonably convey that the security context is used to generate the attestation result. Rather, the Specification subsequently discloses the reverse relationship, in which service security establishment may be based on an attestation result and the attestation result may be an input for generation of a security key (para [0134]-[0135]). Thus, the originally filed disclosure does not reasonably convey possession of generating the attestation result using the security context.
Claims 2-9, 11-12 and 21-22 are rejected for lack of written description support by virtue of claim dependency.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1—9, 11-12, and 20 -22 are rejected under 35 U.S.C. 103 as being unpatentable over Lee et al. (U.S. Pub. 20220070178 A1; Hereinafter “Lee”) in view of Song et al. (U.S. Pub. 20240354429 A1; Hereinafter “Song”), Hawkes et al. (U.S. Pub. 20170289799 A1; Hereinafter “Hawkes”), Haggerty et al. (E.P. Pub. 3541106 A1; Hereinafter “Haggerty”), and Kumar et al. (U.S. Pat. 8327441 B2; Hereinafter “Kumar”).
As per claims 1 and 20, Lee teaches an apparatus for wireless communication at a security service device, comprising (Lee: fig. 13, 14, para[199-201], “the device 1302 (e.g., the attester) is implemented by a vehicle, the service managing entity 1304 (e.g., the relying party) is implemented by a town, and the agent 1306 is implemented by a bridge… the bridge may act as an agent for the town to control traffic based on a number of attestable parameters”):
one or more memories; and one or more processors, coupled to the one or more memories, configured to cause the security service device to:
receive, from at least one of the device or the service, attestation information that includes verifiable information regarding a state of the device or a state of the service (Lee: para[201-205], “the device 1302 may provide attestation information corresponding to one or more attestable parameters to the agent 1306, which may then verify the attestation information… the attestation information may include user attestable information, device attestable information, and/or network (or connectivity) attestable information. In some examples, the attestation information may include one or more sub-states of attestable information. For example, the attestation information may include one or more of device state information, user authentication state information, and/or connectivity state information.”), wherein the security service device is configured to operate as a root of trust for attestation of the device or the service (Lee: para [199-205], [206-208], [221-226], “The agent 1306 may then facilitate verifying the attestation information. For example, the agent 1306 may use the attestation information by the device 1302, may perform its own verifications of the attestation information, and/or may communication with one or more third party verification entities to perform verifications”);
generate, (para[169-170], [206-208], “The agent 1306 may then facilitate verifying the attestation information. For example, the agent 1306 may use the attestation information by the device 1302, may perform its own verifications of the attestation information, and/or may communication with one or more third party verification entities to perform verifications” see also verification result of para[221-226] of fig. 14).
Lee does not clearly teach receive a device credential associated with at least one of a device or a service, wherein the device credential comprises at least one of an integrated universal integrated circuit card (UICC) credential or an embedded UICC credential; establish a security context between the device and the security service device based at least in part on authenticating at least one of the device or the service using the device credential; receive a request for the attestation result; and provide the attestation result in accordance with the request; and generating the attestation result using a security context.
However, in the related art, Song teaches receive a request for the attestation result (Song: para[431-434], “The network function service consumer sends an access token obtaining request message. The access token obtaining request (e.g. access_token_get_request) message is for initiating, to a receiver of the message, a request for obtaining the access token.”); and
provide the attestation result in accordance with the request (Song: para[471-473], “The network repository network element generates the access token. The access token (e.g. access_token) indicates that a holder of the access token is permitted to access a resource, data, or a service…..the access token includes a first attestation result, and the first attestation result includes an attestation result indicating that the network function service consumer is attested by the network repository network element to be trusted.”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to configure Lee’s verifying entity to operate as a root of trust consistent with Song’s teaching to provide a centralized, trusted attestation anchor and enhance replay-attack resistance (Song: para [439]).
Lee in view of Song does not explicitly teach receive a device credential associated with at least one of a device or a service, wherein the device credential comprises at least one of an integrated universal integrated circuit card (UICC) credential or an embedded UICC credential; establish a security context between the device and the security service device based at least in part on authenticating at least one of the device or the service using the device credential; and generating the attestation result using a security context.
However, in the related art, Hawkes teaches receive a device credential associated with at least one of a device or a service ((Hawkes: para [0095], Fig. 17, Hawkes teaches obtaining user equipment credentials from a UE, including a username, password, and a preconfigured UE certificate, and thereafter authenticating the UE to an OSU component using the UE certificate obtained from the UE.);
establish a security context between the device and the security service device based at least in part on authenticating at least one of the device or the service using the device credential (Hawkes: para [0061], [0097], Fig. 19, Hawkes further teaches that authentication of the UE using the preconfigured UE certificate employs Transport Layer Security (TLS), wherein a corresponding TLS session is established with the UE, and the TLS session further authenticates the OSU component using an OSU certificate. Thus, Hawkes teaches receiving a device credential, authenticating the device using that received device credential, and establishing a security context in the form of an authenticated TLS session between the device and the security side component.).
Therefore, It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Lee's device agent attestation arrangement as taught by Hawkes to receive a device credential from the device, authenticate the device using the received credential, and establish a TLS security context based on the credential authentication, because Hawkes teaches that certificate based TLS authentication provides authenticated and secure communications between the device and the security side component (Hawkes para[95-97]).
Lee in view of Song and Hawkes does not teach wherein the device credential comprises at least one of an integrated universal integrated circuit card (UICC) credential or an embedded UICC credential; and generating the attestation result using a security context.
However, in the related art, Haggerty teaches wherein the device credential comprises at least one of an integrated universal integrated circuit card (UICC) credential or an embedded UICC credential (Haggerty: para [0027], [0033], [0066], [0068], [0082]–[0085]), Haggerty teaches that an electronic UICC is contained within a secure element in the UE and, in one embodiment, is a non-removable component of the device. Haggerty further teaches that each eUICC contains a private key and associated eUICC certificate, and that each client eUICC stores the eUICC certificate and associated eUICC private key as security related data. Haggerty additionally teaches that, during an authentication session, a session request generated by the eUICC is passed to a server, and the server cryptographically verifies the request by verifying the eUICC L2 certificate and using the corresponding eUICC L2 public key to verify the L2 signature. Accordingly, Haggerty teaches the device authentication credential as an embedded UICC credential, namely an eUICC associated certificate/private-key credential maintained in a UICC contained within and non-removably associated with the device.).
Therefore, It further would have been obvious to one of ordinary skill in the art before the effective filing date to implement the device credential of the modified Lee system as an eUICC associated credential as taught by Haggerty because Haggerty teaches maintaining an eUICC certificate and corresponding private key in a UICC contained within the secure element of the device and cryptographically verifying the eUICC using that credential, thereby providing a secure device associated authentication credential (Haggerty: para [79]).
Lee in view of Song, Hawkes and Haggerty does not teach generating the attestation result using a security context.
However, in the related art, Kumar teaches generating the attestation result using a security context (Kumar: fig. 1 and 8, col. 18 line 57-67, Kumar teaches an attestation service receiving a security context providing security information and generating a report indicating security risks based on the received security context, as an attestation result. Kumar further expressly recites receiving a security context and generating a report indicating security risks based on the received security context as an attestation result “At block 820, the attestation server 109 may generate a report 117 indicating security risks associated with the application based on.. the received security context 111, as an attestation result”).
It would have been obvious to one of ordinary skill in the art before the effective filing date to further modify the attestation system of Lee, as modified by Hawkes and Haggerty, to use security context information associated with the authenticated device in generating Lee's attestation result, as taught by Kumar, because Kumar teaches that consideration of security context information in generating an attestation result permits the attestation determination to account for security information associated with the entity being evaluated, thereby providing a more context aware assessment of the entity's security state.
As per claim 2, Lee in view of Song, Hawkes, Haggerty, and Kumar teaches the independent claim 1. Lee teaches wherein the one or more processors are further configured to cause the security service device to request the attestation information prior to receiving the attestation information (Lee: para[200], [219], “the agent 1406 transmits an attestation request 1411 that is received by the device 1402.”).
As per claim 3, Lee in view of Song, Hawkes, Haggerty, and Kumar y teaches the dependent claim 2. Lee teaches wherein the one or more processors are further configured to cause the security service device to receive an attestation initiation message (Lee: para[216-218], “The trust score evaluation parameters of the policy 1410 may include one or more triggering events that cause the agent 1406 to evaluate (or re-evaluate) the trust score for a device. For example, triggering events may include an initial service access request from the device, a service access request for one or more services (e.g., a request to access a particular building or building type, a request to access a particular file or file type, etc.).”), wherein, to cause the security service device to receive the attestation information, the one or more processors are configured to cause the security service device to request the attestation information in accordance with the attestation initiation message (Lee: para[216-219], “the agent 1406 may request and/or obtain the policy 1410 after the device 1402 requests access to the services provided by the service managing entity 1404….the attestation request 1411 may indicate the one or more attestable parameters that the agent 1406 may use to evaluate the attestation. For example, the agent 1406 may identify the one or more attestable parameters defined by the policy 1410 to the device 1402 via the attestation request 1411.”).
As per claim 4, Lee in view of Song, Hawkes, Haggerty, and Kumar y teaches the dependent claim 3. Lee teaches wherein the attestation information indicates the state of the device and the attestation initiation message is from the service, or wherein the attestation information indicates the state of the service and the attestation initiation message is from the device (Lee: para[218-220], “The attestation information 1412 may include user attestable information, device attestable information, and/or network (or connectivity) attestable information. In some examples, the attestation information 1412 may include one or more sub-states of attestable information. For example, the attestation information 1412 may include one or more of device state information,…device state information may include one or more of Basic Input/Output System (BIOS) information, Unified Extensible Firmware Interface (UEFI) information, primary boot loader (PBL) information, secondary boot loader (SBL) information, firmware information, Hypervisor information, high level operating system (HLOS) information, real-time operating system (RTOS) information, and/or runtime integrity information”).
As per claim 5, Lee in view of Song, Hawkes, Haggerty, and Kumar teaches the dependent claim 2. Lee teaches wherein the one or more processors, to cause the security service device to request the attestation information, are configured to cause the security service device to request the attestation information in accordance with a previous attestation result having expired (Lee: para[218], “he trust score evaluation parameters of the policy 1410 may include one or more triggering events that cause the agent 1406 to evaluate (or re-evaluate) the trust score for a device…..the trust score evaluation parameters may indicate how frequently or how often the agent 1406 is to evaluate (or re-evaluate) the trust score for a device (e.g., once every hour, once every day, etc.).”).
As per claim 6, Lee in view of Song, Hawkes, Haggerty, and Kumar teaches the dependent claim 2. Lee teaches wherein the one or more processors, to cause the security service device to request the attestation information, are configured to cause the security service device to request the attestation information in association with a service access request of the device (Lee: para[217-219], “triggering events may include an initial service access request from the device, a service access request for one or more services (e.g., a request to access a particular building or building type, a request to access a particular file or file type, etc.)…. the attestation request 1411 may indicate the one or more attestable parameters that the agent 1406 may use to evaluate the attestation. For example, the agent 1406 may identify the one or more attestable parameters defined by the policy 1410 to the device 1402 via the attestation request 1411”).
As per claim 7, Lee in view of Song, Hawkes, Haggerty, and Kumar teaches the independent claim 1. Lee teaches wherein the one or more processors, to cause the security service device to receive the attestation information, are configured to cause the security service device to receive the attestation information from the device or the service (Lee: para[201-205], “the device 1302 may provide attestation information corresponding to one or more attestable parameters to the agent 1306, which may then verify the attestation information… the attestation information may include user attestable information, device attestable information, and/or network (or connectivity) attestable information. In some examples, the attestation information may include one or more sub-states of attestable information. For example, the attestation information may include one or more of device state information, user authentication state information, and/or connectivity state information.”).
Song teaches wherein the attestation result includes a first attestation result for the device or a second attestation result for the service (Song: para[471-473], “The network repository network element generates the access token. The access token (e.g. access_token) indicates that a holder of the access token is permitted to access a resource, data, or a service…..the access token includes a first attestation result, and the first attestation result includes an attestation result indicating that the network function service consumer is attested by the network repository network element to be trusted.”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to have update Lee with the request for attestation result of Song, it will prevent replay attack (Song: para [439]).
As per claims 8 and 21, Lee in view of Song, Hawkes, Haggerty, and Kumar teaches the independent claim 1. Lee teaches wherein the one or more processors, to cause the security service device to receive the attestation information, are configured to cause the security service device to receive the attestation information from the service, wherein the attestation information indicates the state of the service (Lee: para[205], “The connectivity state information may include one or more of radio frequency (RF) fingerprint information, virtual private network (VPN) information, channel-type information, authentication method information, security protocol and/or algorithm information”
As per claims 9 and 22, Lee in view of Song, Hawkes, Haggerty, and Kumar teaches the independent claim 1. Song teaches wherein the one or more processors, to cause the security service device to provide the attestation result, are configured to cause the security service device to provide the attestation result in association with a key generation operation of the device or the service (Song: para[471-480], “The network repository network element generates the access token. The access token (e.g. access_token) indicates that a holder of the access token is permitted to access a resource, data, or a service… the access token includes a first attestation result, and the first attestation result includes an attestation result indicating that the network function service consumer is attested by the network repository network element to be trusted….The network repository network element sends an access token obtaining response message…. the access token obtaining response message further includes a refresh token.”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to have update Lee with the request for attestation result of Song, it will prevent replay attack (Song: para [439]);
As per claim 11, Lee in view of Song, Hawkes, Haggerty, and Kumar teaches the independent claim 1. Lee teaches wherein the one or more processors, to cause the security service device to generate the attestation result, are configured to cause the security service device to verify the verifiable information in accordance with a remote attestation operation or an entity attestation token operation (Lee: para[225-226], “the agent 1406 may facilitate verification of the attestation information by requesting a third party verification entity perform the verification. For example, the agent 1406 may transmit a verification result request 1418 to the third party verification entity 1408 and request that the third party verification entity 1408 provide a verification result for a sub-state of the attestation information 1412…. The third party verification entity 1408 may transmit a verification result 1422 that is received by the agent 1406”).
As per claim 12, Lee in view of Song, Hawkes, Haggerty, and Kumar teaches the independent claim 1. Song teaches wherein the one or more processors are further configured to cause the security service device to provide the attestation result to the service (Song: para[471-480], “The network repository network element generates the access token. The access token (e.g. access_token) indicates that a holder of the access token is permitted to access a resource, data, or a service… the access token includes a first attestation result, and the first attestation result includes an attestation result indicating that the network function service consumer is attested by the network repository network element to be trusted….The network repository network element sends an access token obtaining response message…. the access token obtaining response message further includes a refresh token.”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to have update Lee with the request for attestation result of Song, it will prevent replay attack (Song: para [439]).
Claims 13, and 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over Lee et al. (U.S. Pub. 20220070178 A1; Hereinafter “Lee”) in view of Hawkes et al. (U.S. Pub. 20170289799 A1; Hereinafter “Hawkes”), Haggerty et al. (E.P. Pub. 3541106 A1; Hereinafter “Haggerty”), and Kumar et al. (U.S. Pat. 8327441 B2; Hereinafter “Kumar”).
As per claim 13, Lee teaches an apparatus for wireless communication at an attester device, comprising (fig. 4, 12, para[178], “communication flow 1200 between a network endpoint 1202, a network health manager 1204, and a trusted third party 1206, as presented herein. Aspects of the network endpoint 1202 may be implemented by a network endpoint…an attester (e.g., the attester 702 of FIGS. 7A, 7B, and/or 7C), and/or the device 803 of FIG. 8.”):
one or more memories (fig. 3, para[89], “memory 360”); and
one or more processors, coupled to the one or more memories, configured to cause the attester device to (Lee: para[89], “As shown in FIG. 3,.. The example UE 350 includes antennas 352, a transceiver 354 including a transmitter 354a and a receiver 354b, an RX processor 356, a channel estimator 358, a controller/processor 359, memory 360, and a TX processor 368.”):
receive, from a service, a request for attestation information that includes verifiable information regarding a state of the attester device (Lee: para[43], “For example, a network, such as an IoT network, may include one or more network endpoints that access a service (e.g., wireless communication, Internet access, messaging, networking, etc.) provided by a service provider (e.g., a gateway, a router, an access point, a base station, etc.).”, para[98-99], para[124], [189-190], [216-229], “ the network health manager 1204 initiates performing a verification of the network endpoint 1202 by transmitting a state query 1224 that is received by the network endpoint 1202”, “the agent 1406 transmits an attestation request 1411 that is received by the device 1402. In some examples, the attestation request 1411 may indicate the one or more attestable parameters that the agent 1406 may use to evaluate the attestation. For example, the agent 1406 may identify the one or more attestable parameters defined by the policy 1410 to the device 1402 via the attestation request 1411.”), wherein the attester device is configured to operate as a root of trust for attestation of the device or the service (Lee: para [199-205], [206-208], [221-226], “The agent 1306 may then facilitate verifying the attestation information. For example, the agent 1306 may use the attestation information by the device 1302, may perform its own verifications of the attestation information, and/or may communication with one or more third party verification entities to perform verifications”); and
transmit, (Lee; para[98-99], [113], [190], [216-229] “In response to receiving the state query 1224, the network endpoint 1202 transmits an attestation 1226 that is received by the network health manager 1204. In some examples, the attestation 1226 may be based on one or more of a device identifier of the network endpoint 1202, a permanent credential of the network endpoint 1202, and/or device state information of the network endpoint 1202”, “the device 1402 transmits attestation information 1412 that is received by the agent 1406. The attestation information 1412 may include user attestable information, device attestable information, and/or network (or connectivity) attestable information. In some examples, the attestation information 1412 may include one or more sub-states of attestable information.”).
Lee does not explicitly teach send, to a security service device, a device credential associated with the attester device, wherein the device credential comprises at least one of an integrated universal integrated circuit card (UICC) credential or an embedded UICC credential; establish a security context between the attester device and the security service device; and generating the attestation result using the security context.
However, in the related art, Hawkes teaches send, to a security service device, a device credential associated with the attester device (Hawkes: para [0095], Fig. 17, Hawkes teaches obtaining user equipment credentials from a UE, including a username, password, and a preconfigured UE certificate, and thereafter authenticating the UE to an OSU component using the UE certificate obtained from the UE.);
establish a security context between the attester device and the security service device (Hawkes: para [0061], [0097], Fig. 19, Hawkes further teaches that authentication of the UE using the preconfigured UE certificate employs Transport Layer Security (TLS), wherein a corresponding TLS session is established with the UE, and the TLS session further authenticates the OSU component using an OSU certificate. Thus, Hawkes teaches receiving a device credential, authenticating the device using that received device credential, and establishing a security context in the form of an authenticated TLS session between the device and the security side component.).
Therefore, It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Lee's device agent attestation arrangement as taught by Hawkes to receive a device credential from the device, authenticate the device using the received credential, and establish a TLS security context based on the credential authentication, because Hawkes teaches that certificate based TLS authentication provides authenticated and secure communications between the device and the security side component (Hawkes para[95-97]).
Lee in view of Hawkes does not teach wherein the device credential comprises at least one of an integrated universal integrated circuit card (UICC) credential or an embedded UICC credential; and generating the attestation result using the security context.
However, in the related art, Haggerty teaches wherein the device credential comprises at least one of an integrated universal integrated circuit card (UICC) credential or an embedded UICC credential (Haggerty: para [0027], [0033], [0066], [0068], [0082]–[0085]), Haggerty teaches that an electronic UICC is contained within a secure element in the UE and, in one embodiment, is a non-removable component of the device. Haggerty further teaches that each eUICC contains a private key and associated eUICC certificate, and that each client eUICC stores the eUICC certificate and associated eUICC private key as security related data. Haggerty additionally teaches that, during an authentication session, a session request generated by the eUICC is passed to a server, and the server cryptographically verifies the request by verifying the eUICC L2 certificate and using the corresponding eUICC L2 public key to verify the L2 signature. Accordingly, Haggerty teaches the device authentication credential as an embedded UICC credential, namely an eUICC associated certificate/private-key credential maintained in a UICC contained within and non-removably associated with the device.).
Therefore, It further would have been obvious to one of ordinary skill in the art before the effective filing date to implement the device credential of the modified Lee system as an eUICC associated credential as taught by Haggerty because Haggerty teaches maintaining an eUICC certificate and corresponding private key in a UICC contained within the secure element of the device and cryptographically verifying the eUICC using that credential, thereby providing a secure device associated authentication credential (Haggerty: para [79]).
Lee in view of Hawkes and Haggerty does not teach generating the attestation result using a security context.
However, in the related art, Kumar teaches generating the attestation result using a security context (Kumar: fig. 1 and 8, col. 18 line 57-67, Kumar teaches an attestation service receiving a security context providing security information and generating a report indicating security risks based on the received security context, as an attestation result. Kumar further expressly recites receiving a security context and generating a report indicating security risks based on the received security context as an attestation result “At block 820, the attestation server 109 may generate a report 117 indicating security risks associated with the application based on.. the received security context 111, as an attestation result”).
It would have been obvious to one of ordinary skill in the art before the effective filing date to further modify the attestation system of Lee, as modified by Hawkes and Haggerty, to use security context information associated with the authenticated device in generating Lee's attestation result, as taught by Kumar, because Kumar teaches that consideration of security context information in generating an attestation result permits the attestation determination to account for security information associated with the entity being evaluated, thereby providing a more context aware assessment of the entity's security state.
As per claim 15, Lee in view of Hawkes, Haggerty, and Kumar teaches the independent claim 13. Lee teaches wherein the one or more processors, to cause the security service device to request the attestation information, are configured to cause the security service device to request the attestation information in accordance with a previous attestation result having expired (Lee: para[218], “he trust score evaluation parameters of the policy 1410 may include one or more triggering events that cause the agent 1406 to evaluate (or re-evaluate) the trust score for a device…..the trust score evaluation parameters may indicate how frequently or how often the agent 1406 is to evaluate (or re-evaluate) the trust score for a device (e.g., once every hour, once every day, etc.).”).
As per claim 16, Lee in view of Hawkes, Haggerty, and Kumar teaches the dependent claim 13. Lee teaches wherein the one or more processors, to cause the security service device to request the attestation information, are configured to cause the security service device to request the attestation information in association with a service access request of the device (Lee: para[217-219], “triggering events may include an initial service access request from the device, a service access request for one or more services (e.g., a request to access a particular building or building type, a request to access a particular file or file type, etc.)…. the attestation request 1411 may indicate the one or more attestable parameters that the agent 1406 may use to evaluate the attestation. For example, the agent 1406 may identify the one or more attestable parameters defined by the policy 1410 to the device 1402 via the attestation request 1411”).
As per claim 17, Lee in view of Hawkes, Haggerty, and Kumar teaches the independent claim 13. Lee teaches wherein the one or more processors, to cause the attester device to receive the request for the attestation information, are configured to cause the attester device to receive the request for the attestation information in accordance with a periodicity (para[124], [189-190], “In some examples, the network health manager may perform the verifications of the network endpoint in accordance with a policy. For example, the network health manager may query the network endpoint for an attestation periodically, on-demand, or in response to an occurrence of a triggering event.”).
As per claim 18, Lee in view of Hawkes, Haggerty, and Kumar teaches the independent claim 13. Lee teaches wherein the attester device is a network node (para[119], “Aspects of the attester 702 may be implemented by a network endpoint and/or a device (e.g., the user device 103 of FIG. 1 and/or the UE 104 of FIG. 1) that is connected (or attempting to connect) to the network provided by the relying party 704.”), and wherein the attestation information further indicates a state of a user equipment (UE) associated with the network node (para[120-124], [204], “The attestation information may include user attestable information, device attestable information, and/or network (or connectivity) attestable information. In some examples, the attestation information may include one or more sub-states of attestable information. For example, the attestation information may include one or more of device state information, user authentication state information, and/or connectivity state information.”).
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Lee et al. (U.S. Pub. 20220070178 A1; Hereinafter “Lee”) in view of Hawkes et al. (U.S. Pub. 20170289799 A1; Hereinafter “Hawkes”), Haggerty et al. (E.P. Pub. 3541106 A1; Hereinafter “Haggerty”), Kumar et al. (U.S. Pat. 8327441 B2; Hereinafter “Kumar”), and Smith et al. (U.S. Pub. 20210314365 A1; Hereinafter “Smith”).
As per claim 14, Lee in view of Hawkes, Haggerty, and Kumar teaches the independent claim 13.
Lee in view of Hawkes, Haggerty, and Kumar does not teach wherein the one or more processors are further configured to cause the attester device to transmit, prior to transmitting the attestation information, a cryptographic nonce, wherein the request for the attestation information is based at least in part on the cryptographic nonce.
However, in the related art, Smith teaches wherein the one or more processors are further configured to cause the attester device to transmit, prior to transmitting the attestation information, a cryptographic nonce, wherein the request for the attestation information is based at least in part on the cryptographic nonce (Smith: para[216-18], “the lead Attester may provide a nonce to the ESE Attester who includes it in E1, or the lead Attester may obtain a nonce from remove Verifier and includes it in E2 and/or E1 (for freshness). Both attesters may include a timestamp claim as an alternative form of freshness. Likewise, the lead Attester as local Verifier may match E1 claims against claims in a reference manifest (e.g. CoSWID/SWID/platform certificate) from an ESE vendor, or may verify E1 claims against a policy that accepts only matched claims”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to have update Lee with the cryptographic nonce of Smith, it will prevent unauthorized access to services or resources (Smith: para [52]);
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20160366183 A1 - a credential management server to provide credentials to a plurality of computing devices and a plurality of resource servers; a rights management server to grant capability rights to the plurality of computing devices; and an access management server to assign access control policies for a plurality of resources to be protected by the plurality of resource servers. A first resource server may receive a first access request for access to a first resource from a first computing device and send the first access request to the access management server for determination of whether to grant a permission for the access to the first resource.
US 20210274348 A1 - A method for remote management and remote management authority verification by a terminal includes: receiving a remote management instruction package; obtaining certificate information configured for a security module, which may be used when remotely managing a security service module corresponding to at least one identifier among a plurality of identifiers; and verifying a remote security service module management certificate of a bundle management server and the remote management instruction package by using the obtained certificate information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LYDIA L NOEL whose telephone number is (571)272-1628. The examiner can normally be reached Odd Weeks-Monday: 8:00 AM 4:00 PM, Tuesday & Wednesday: 9:00 AM 3:00 PM. Even Weeks-Monday: 8:00 AM 4:00 PM, Tuesday through Thursday: 9:00 AM 1:00 PM.
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, Alexander Lagor can be reached on (571)-270-5143. 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.
/L.L.N./ /ALI S ABYANEH/ Examiner, Art Unit 2437 Primary Examiner, Art Unit 2437
Prosecution Insights