IDENTIFICATION OF A COMPUTING DEVICE DURING AUTHENTICATION

Application No. 17/884,295

• Filed: Aug 09, 2022
• Examiner: KHADKA, AMIT
• Art Unit: 2432
• Tech Center: 2400 — Computer Networks
• Assignee: CrowdStrike Inc.
• OA Round: 5 (Non-Final)

Office 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 .
Response to Amendment
The amendment filed on 03/11/2026, has been accepted and considered for this office action. Claims 1, 4, 6, 8, 11, 15 and 20 have been amended. No claims have been canceled. No new claims have been added.
Response to Arguments
Applicant’s arguments, filed on 03/11/2026, with respect to the amended limitation have been fully considered and are not persuasive. See below rejections for full detail.
Applicant argues that Stites merely teaches that agent 134 “attaches metadata … to the request” and that attaching metadata to a request is different from retrieving metadata from the request. Applicant further argues that Stites does not teach retrieving “additional data indicating compatibility of the computing device” from the request.
Stites is not relied upon alone for the newly amended “retrieving” limitation. Rather, Stites is relied upon for the federated device-identity authentication flow in which an agent on the device intercepts a request, modifies the request by attaching metadata associated with the device to the request and sends to the device identity server. See, Stites, [0020], discloses that the agent 134 attaches the metadata associated with the device to the request 335 to form a new request 340 for an authenticated device identity which the agent 134 sends to the device identity server.
However, the rejection relies on Bodin for the teaching of “retrieving, by the security agent, an identifier of the computing device and additional information from the request.”
Bodin, para 14, discloses the system 100 extracts user-agent identifiers (para 20, device identifier is also referred as user- agent identifier) and unique user identifiers from the http requests; para 12, Bodin discloses user-agent identifier string (e.g., a cookie) uniquely identifies the make, type, and/or capabilities of an end-user mobile device; para 16, Bodin discloses capabilities of device D1, such as, for example, memory capacity, connectivity speed, connectivity type (e.g., 4G, Wi-Fi), GPS enabled, camera, video, screen resolution, screen size, touch screen, media player, Bluetooth.RTM. enabled operating system, software/application compatibility, image file formats supported, types of audio/video file formats supported, SMS/MMS support, support for near field communication, level/version of CSS, JavaScript, html supported, etc.
Applicant’s argument that an “OS version” is different from “compatibility” does not overcome the rejection because the current rejection is not based merely on an OS version being equivalent to compatibility. Bodin, para 12, 14 discloses that extracted information includes identifiers that uniquely identifies the make, type, and/or capabilities of an end-user mobile device; para 16, Bodin discloses capabilities of device D1, such as, for example, memory capacity, connectivity speed, connectivity type (e.g., 4G, Wi-Fi), GPS enabled, camera, video, screen resolution, screen size, touch screen, media player, Bluetooth.RTM. enabled operating system, software/application compatibility, image file formats supported, types of audio/video file formats supported, SMS/MMS support, support for near field communication, level/version of CSS, JavaScript, html supported, etc.
Therefore, the applicant’s argument is not persuasive.

Regarding 35 U.S.C. 112(a),
The rejection of the current claims under 35 U.S.C. 112(a) for the lack of written description is maintained.
In their Remarks (pages 12-13), Applicant merely recites a portion of their specification without providing any substantive explanation or technical support for how the security agent retrieves the device identifier from the authentication request, as currently claimed.
Furthermore, the cited disclosure fails to support Applicant’s argument. Not only does the quoted text from paragraph 30 fails to state that the identifier is retrieved from the authentication request itself, but the specification description actively teaches against this limitation. Specifically, steps 208-210 of Figure 2 (detailed in para 51-52) explicitly clarify that the identifier is not embedded within the initial request received by the device. Instead, the specification teaches that the security agent intercepts the request, then retrieves the identifier from the local device environment, then injects the identifier into the request, then forwards the modified request with the injected identifier. Thus, not only is there no 112a support for the limitation argued, it is nonsensical in light of the context of the disclosed invention. Further, the claim omits the essential step of injecting the identifier into the request.
Because the specification fails to demonstrate that the inventor was in possession of the claimed subject matter at the time of filing. Accordingly, the rejection under 35 U.S.C. 112(a) is maintained.

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.

1, 4-8, 11-15, 17 and 19-26 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 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.
The limitation of claims 1, 8 and 15 recite “retrieving, by the security agent, an identifier of the computing device from the authentication request”. The Specification para [0030] states, “Accordingly, the security agent 114 may intercept the authentication request, and may retrieve data about the computing device 102 after intercepting the authentication request.” Para [0040] clarifies the source of the data, “After intercepting the authentication request and retrieving the data about the computing device 102 (e.g., from the data 128)” and para [0021] states, “The memory 118 may also store various types of data 128, at least some of which may be usable by the security agent 114, the browser(s) 122, the client application(s) 124, and/or the OS 126.” The specification repeatedly describes the security agent retrieving data from the local computing device and that the agent “injects” that data into the authentication request before forwarding it to the second identity provider, para [0051]. Nowhere does the specification describe an authentication request that initially contains “an identifier of the computing device” nor any operation in which the agent “retrieves” such an identifier from the authentication request itself.
Because the specification does not describe or enable an authentication request that includes a device identifier prior to agent interception, the written description requirement is not satisfied. Reliance on undisclosed external material cannot satisfy written description requirement. See MPEP 2163.06
Regarding claims 4-7, 11-14, 17 and 19-26, they are also rejected because of their dependency with rejected claims 1, 8 and 15.

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.

Claim(s) 1, 4-6, 8, 11-12, 14 and 26 are rejected under 35 U.S.C. 103 as being unpatentable over Stites (U.S. 2018/0337920 A1) in view of Pochuev (US 20200145409 A1) in view of Ahmed (US 20220217132 A1) in view of Srinivasan (US 8924721 B2) further in view of Bodin (US 20130054575 A1).
Regarding Claim 1, Stites teaches:
sending, by a computing device, a request to a first identity provider (Stites, [0018], the client device sends a request 300 to the Application server 120.);
receiving, by the computing device, from the first identity provider, redirection data to redirect the request to a second identity provider (Stites, [0019, 0020], Fig. 3, discloses that the client device receives a redirect data back from the application server and then the client device forwards it to Device ID server.);
sending, by the security agent, the request with the identifying information and the additional information to the second identity provider (Stites, [0020], discloses that the agent 134 attaches the metadata associated with the device to the request 335 to form a new request 340 for an authenticated device identity which the agent 134 sends to the device identity server; para 26, Stites discloses the content of the metadata may include any information that the device identity server 150 can use to verify the identity of the device 110 with a given level of trust. The metadata may be a self-asserted identifier or a signed assertion from a hardware token in the device 110.);
receiving, by the computing device, from the second identity provider, a response to the request, wherein the response includes the identifying information (Stites, [0022], discloses that the device identity server sends a redirect message (response) back to the computing device. This response includes the authenticated device identity and any available device context information.);
sending, by the computing device, the response to the first identity provider (Stites, [0022], discloses that the client 132 forwards the authenticated device identity to the application server 120 in message 355, providing the application server 120 with the authenticated device identity provided by the device identity server 150.);
and receiving, by the computing device, a result of the request from the first identity provider (Stites, [0022], discloses that the application server 120 determines whether to grant or deny access to the application resource requested in the original request message 300. The application server 120 informs the client 132 of the determination in message 370.);

Stites, para [0030] also discloses that the agent 134 intercepts the request 335 and the agent attaches metadata associated with the device to the request; Stites does not disclose retrieving the metadata from the request.
Stites does not explicitly teach; However, Ahmed teaches:
wherein the redirection data comprises a uniform resource locator (URL) managed by the second identity provider, and in response to a browser of the computing device being directed to the URL, the URL resolves to a localhost associated with the computing device (Ahmed, para 40, 41, discloses that the traffic intended for the remote identity provider (108) is redirected such that its url (e.g., idp.enterprise.com) resolves to 127.0.0.1 (localhost) on the computing device.);
intercepting, by a security agent executing on the computing device, the request based at least in part on the URL resolving to the localhost (Ahmed, para 68, discloses the local agent executing on the client device (Fig 1) intercepts the SAML request since the DNS lookup for the IdP's URL resolves to localhost, directing the traffic to the local agent.);
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites to incorporate the teaching of Ahmed to combine the technique to include URL managed by Identity provider in the redirection request such that the URL resolves to localhost and intercepting the request by an agent on the host device. One would be motivated to make such modifications on Stites to improve the system that require repeated user interactions and lack transparent support for sharing authentication across multiple local applications by providing a true single sign-on experience without requiring user intervention for each application or modifications to existing service providers. (Ahmed, Page 1)
Ahmed does not explicitly teach; However, Pochuev teaches:
Wherein the request is an authentication request (Pochuev, [0079], discloses that the IoT device 110 sends an authentication request 1205 to the authentication policy server.);
wherein the response is signed response (Pochuev, [0108], discloses that the RoT server 114 signs and sends the authentication response back to the authentication policy server 112.);
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites to incorporate the teaching of Pochuev to utilize the concept of having the authentication request sent to an Identity Provider and the response back from the Identity provider to be signed. One would be motivated to make such modifications on Stites to improve the secure management of computing devices, including their enrollment, remotely and on a larger scale by eliminating the need for secure, manual, on-site provisioning. (Pochuev, Page 2)
Pochuev does not teach; However, Srinivasan teaches:
Wherein the identifying information is the unique identifier of the security agent (Srinivasan, Column 3, lines 16-18, discloses an agent probe that queries an agent installed on the host device for a unique agent identifier; Column 6, lines 63-64, the agent 112 provides an agent identifier of the agent);
the identifier of the computing device being an identifying information (Srinivasan, Column 11, lines 37-42, discloses By monitoring host attributes (Col 15, lines 59-64, host attributes include an agent identifier of an agent 112 installed on the host device 110) of the host device that identify the host device, traffic to and from the host device, and the state of the host device, the sensor 102 can control network access of the host device according to the one or more network access zones associated with the state of the host device.);
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites to incorporate the teaching of Srinivasan to utilize the concept of identifying information as a unique identifier of a security agent which strengthens the security mechanism by providing distinct and verifiable attribute tied directly to the security agent. The motivation to make such a combination would be to enhance the authentication process and prevent various attacks such as reply attack. (Srinivasan, Column 2)
Srinivasan does not explicitly teach; However; Bodin teaches:
retrieving, by the security agent, an identifier of the computing device and additional information from the request (Bodin, para 14, discloses the system 100 extracts user-agent identifiers (para 20, device identifier is also referred as user- agent identifier) and unique user identifiers from the http requests; para 12, Bodin discloses user-agent identifier string (e.g., a cookie) uniquely identifies the make, type, and/or capabilities of an end-user mobile device; para 16, Bodin discloses capabilities of device D1, such as, for example, memory capacity, connectivity speed, connectivity type (e.g., 4G, Wi-Fi), GPS enabled, camera, video, screen resolution, screen size, touch screen, media player, Bluetooth.RTM. enabled operating system, software/application compatibility, image file formats supported, types of audio/video file formats supported, SMS/MMS support, support for near field communication, level/version of CSS, JavaScript, html supported, etc.)
Wherein the additional information comprises additional data indicating compatibility of the computing device (Bodin, para 12, 14 discloses that extracted information includes identifiers that uniquely identifies the make, type, and/or capabilities of an end-user mobile device; para 16, Bodin discloses capabilities of device D1, such as, for example, memory capacity, connectivity speed, connectivity type (e.g., 4G, Wi-Fi), GPS enabled, camera, video, screen resolution, screen size, touch screen, media player, Bluetooth.RTM. enabled operating system, software/application compatibility, image file formats supported, types of audio/video file formats supported, SMS/MMS support, support for near field communication, level/version of CSS, JavaScript, html supported, etc.)
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites/Ahmed/Pochuev/Srinivasan to incorporate Bodin’s teaching of extracting a user identifier such as name, email address, telephone number from the request. One would be motivated to perform such modification on Stites/Ahmed/Pochuev/Srinivasan’s system to improve the system by allowing the device identity server and/or application server to associate the authenticated device information with the user making the request. This would improve user to device mapping, auditing, policy enforcement authorization.

Regarding Claim 4, Stites, Ahmed, Pochuev, Srinivasan and Bodin teach the method of claim 1,
Bodin further teaches:
wherein the additional data further indicates at least one of: a version of an operating system (OS) of the computing device; a policy level of the security agent; user information about a user of the computing device; a strength of a password associated with the user; a location associated with the request; proxy information associated with the request; whether a security feature is enabled on the computing device; or whether the computing device has been involved in a security incident (Bodin, para 14, discloses the system 100 extracts user-agent identifiers (para 20, device identifier is also referred as user- agent identifier) and unique user identifiers (para 20, e.g., user identifier (name, e-mail address, phone number, and/or a combination thereof)) from the http requests);
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites/Ahmed/Pochuev/Srinivasan to incorporate Bodin’s teaching of extracting a user identifier such as name, email address, telephone number from the request. One would be motivated to perform such modification on Stites/Ahmed/Pochuev/Srinivasan’s system to improve the system by allowing the device identity server and/or application server to associate the authenticated device information with the user making the request. This would improve user to device mapping, auditing, policy enforcement authorization.

Regarding Claim 5, Stites/Ahmed/Srinivasan/Bodin/Pochuev teach the method of claim 1,
Stites further teaches:
the sending the request with the identifying information to the second identity provider comprises sending the request with the identifying information using a secure tunneling mechanism between the security agent and the second identity provider; (Stites, [0020], discloses the agent 134 attaches metadata associated with the device 110 to the request 335 to form a new request 340 for an authenticated device identity, which the agent 134 sends to the device identity server 150; [0020], Stites discloses the agent 134 establishes a separate SSL tunnel to the device identity server 150 and sends the request 340 through the separate SSL tunnel.);
and the receiving the response from the second identity provider comprises receiving the response using the secure tunneling mechanism (Stites, [0022], discloses the device identity server 150 sends a redirect message 345 back to the device 110 including the authenticated device identity and any available device context information. The agent 134 receives the redirect message 345 and forwards it as a redirect message 350 to the client 132. [Examiner interprets, the secure tunneling mechanism (SSL tunnel) is implied to be used for both directions of communication, including sending the response.])
Stites/Ahmed/Bodin do not explicitly disclose:
Wherein the request is an authentication request;
Wherein the identifying information is the unique identifier of the security agent;
Wherein the response is signed response.
However, Pochuev teaches:
Wherein the request is an authentication request (Pochuev, [0079], discloses that the IoT device 110 sends an authentication request 1205 to the authentication policy server.);
wherein the response is signed response (Pochuev, [0108], discloses that the RoT server 114 signs and sends the authentication response back to the authentication policy server 112.)
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites/Ahmed/Srinivasan/Bodin’s system to incorporate the teaching of Pochuev to utilize the concept of having the authentication request sent to an Identity Provider and the response back from the Identity provider to be signed. One would be motivated to make such modifications on Stites/Ahmed/Srinivasan/Bodin’s system to improve the secure management of computing devices, including their enrollment, remotely and on a larger scale by eliminating the need for secure, manual, on-site provisioning. (Pochuev, Page 2)
Pochuev does not teach; However, Srinivasan teaches:
Wherein the identifying information is the unique identifier of the security agent (Srinivasan, Column 3, lines 16-18, discloses an agent probe that queries an agent installed on the host device for a unique agent identifier; Column 6, lines 63-64, the agent 112 provides an agent identifier of the agent);
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites/Ahmed/Pochuev/Bodin’s system to incorporate the teaching of Srinivasan to utilize the concept of identifying information as a unique identifier of a security agent which strengthens the security mechanism by providing distinct and verifiable attribute tied directly to the security agent. The motivation to make such a combination would be to enhance the authentication process and prevent various attacks such as reply attack. (Srinivasan, Column 2)

Regarding Claim 6, Stites/Ahmed/Pochuev/Bodin/Srinivasan teach the method of claim 1,
Stites further teaches:
wherein the response includes data about the computing device retrieved by the second identity provider (Stites, [0021], discloses the device identity provider requests device context information from a context server and receives details such as posture or compliance data; [0022], Stites discloses the device identity server includes the authenticated device identity and any available context information in a redirect message sent back to the computing device.)
Stites/Ahmed/Srinivasan/Bodin do not explicitly disclose:
Wherein the response is signed response.
However, Pochuev teaches:
wherein the response is signed response (Pochuev, [0108], discloses that the RoT server 114 signs and sends the authentication response back to the authentication policy server 112.);
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites/Ahmed/Srinivasan/Bodin’s system to incorporate the teaching of Pochuev to utilize the concept of having the authentication request sent to an Identity Provider and the response back from the Identity provider to be signed. One would be motivated to make such modifications on Stites/Ahmed/Srinivasan/Bodin’s system to improve the secure management of computing devices, including their enrollment, remotely and on a larger scale by eliminating the need for secure, manual, on-site provisioning. (Pochuev, Page 2)

Regarding Claim 8, Stites teaches:
send a request to a first identity provider (Stites, [0018], the client device sends a request 300 to the Application server 120.);
receive from the first identity provider, redirection data to redirect the request to a second identity provider (Stites, [0019, 0020], Fig. 3, discloses that the client device receives a redirect data back from the application server and then the client device forwards it to Device ID server.);
send the request with the identifying information and the additional information to the second identity provider (Stites, [0020], discloses that the agent 134 attaches the metadata associated with the device to the request 335 to form a new request 340 for an authenticated device identity which the agent 134 sends to the device identity server; para 26, Stites discloses the content of the metadata may include any information that the device identity server 150 can use to verify the identity of the device 110 with a given level of trust. The metadata may be a self-asserted identifier or a signed assertion from a hardware token in the device 110.);
receive from the second identity provider, a response to the request, wherein the response includes the identifying information (Stites, [0022], discloses that the device identity server sends a redirect message (response) back to the computing device. This response includes the authenticated device identity and any available device context information.);
send the response to the first identity provider (Stites, [0022], discloses that the client 132 forwards the authenticated device identity to the application server 120 in message 355, providing the application server 120 with the authenticated device identity provided by the device identity server 150.);
and receive a result of the request from the first identity provider (Stites, [0022], discloses that the application server 120 determines whether to grant or deny access to the application resource requested in the original request message 300. The application server 120 informs the client 132 of the determination in message 370.);

Stites, para [0030] also discloses that the agent 134 intercepts the request 335 and the agent attaches metadata associated with the device to the request; Stites does not disclose retrieving the metadata from the request.
Stites does not explicitly teach; However, Ahmed teaches:
wherein the redirection data comprises a uniform resource locator (URL) managed by the second identity provider, and in response to a browser of the computing device being directed to the URL, the URL resolves to a localhost associated with the computing device (Ahmed, para 40, 41, discloses that the traffic intended for the remote identity provider (108) is redirected such that its url (e.g., idp.enterprise.com) resolves to 127.0.0.1 (localhost) on the computing device.);
intercept, by a security agent executing on the computing device, the request based at least in part on the URL resolving to the localhost (Ahmed, para 68, discloses the local agent executing on the client device (Fig 1) intercepts the SAML request since the DNS lookup for the IdP's URL resolves to localhost, directing the traffic to the local agent.);
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites to incorporate the teaching of Ahmed to combine the technique to include URL managed by Identity provider in the redirection request such that the URL resolves to localhost and intercepting the request by an agent on the host device. One would be motivated to make such modifications on Stites to improve the system that require repeated user interactions and lack transparent support for sharing authentication across multiple local applications by providing a true single sign-on experience without requiring user intervention for each application or modifications to existing service providers. (Ahmed, Page 1)
Ahmed does not explicitly teach; However, Pochuev teaches:
Wherein the request is an authentication request (Pochuev, [0079], discloses that the IoT device 110 sends an authentication request 1205 to the authentication policy server.);
wherein the response is signed response (Pochuev, [0108], discloses that the RoT server 114 signs and sends the authentication response back to the authentication policy server 112.);
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites to incorporate the teaching of Pochuev to utilize the concept of having the authentication request sent to an Identity Provider and the response back from the Identity provider to be signed. One would be motivated to make such modifications on Stites to improve the secure management of computing devices, including their enrollment, remotely and on a larger scale by eliminating the need for secure, manual, on-site provisioning. (Pochuev, Page 2)
Pochuev does not teach; However, Srinivasan teaches:
Wherein the identifying information is the unique identifier of the security agent (Srinivasan, Column 3, lines 16-18, discloses an agent probe that queries an agent installed on the host device for a unique agent identifier; Column 6, lines 63-64, the agent 112 provides an agent identifier of the agent);
the identifier of the computing device being an identifying information (Srinivasan, Column 11, lines 37-42, discloses By monitoring host attributes (Col 15, lines 59-64, host attributes include an agent identifier of an agent 112 installed on the host device 110) of the host device that identify the host device, traffic to and from the host device, and the state of the host device, the sensor 102 can control network access of the host device according to the one or more network access zones associated with the state of the host device.);
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites to incorporate the teaching of Srinivasan to utilize the concept of identifying information as a unique identifier of a security agent which strengthens the security mechanism by providing distinct and verifiable attribute tied directly to the security agent. The motivation to make such a combination would be to enhance the authentication process and prevent various attacks such as reply attack. (Srinivasan, Column 2)
Srinivasan does not explicitly teach; However; Bodin teaches:
retrieve, by the security agent, an identifier of the computing device and additional information from the request (Bodin, para 14, discloses the system 100 extracts user-agent identifiers (para 20, device identifier is also referred as user- agent identifier) and unique user identifiers from the http requests; para 12, Bodin discloses user-agent identifier string (e.g., a cookie) uniquely identifies the make, type, and/or capabilities of an end-user mobile device; para 16, Bodin discloses capabilities of device D1, such as, for example, memory capacity, connectivity speed, connectivity type (e.g., 4G, Wi-Fi), GPS enabled, camera, video, screen resolution, screen size, touch screen, media player, Bluetooth.RTM. enabled operating system, software/application compatibility, image file formats supported, types of audio/video file formats supported, SMS/MMS support, support for near field communication, level/version of CSS, JavaScript, html supported, etc.)
Wherein the additional information comprises additional data indicating compatibility of the computing device (Bodin, para 12, 14 discloses that extracted information includes identifiers that uniquely identifies the make, type, and/or capabilities of an end-user mobile device; para 16, Bodin discloses capabilities of device D1, such as, for example, memory capacity, connectivity speed, connectivity type (e.g., 4G, Wi-Fi), GPS enabled, camera, video, screen resolution, screen size, touch screen, media player, Bluetooth.RTM. enabled operating system, software/application compatibility, image file formats supported, types of audio/video file formats supported, SMS/MMS support, support for near field communication, level/version of CSS, JavaScript, html supported, etc.)
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites/Ahmed/Pochuev/Srinivasan to incorporate Bodin’s teaching of extracting a user identifier such as name, email address, telephone number from the request. One would be motivated to perform such modification on Stites/Ahmed/Pochuev/Srinivasan’s system to improve the system by allowing the device identity server and/or application server to associate the authenticated device information with the user making the request. This would improve user to device mapping, auditing, policy enforcement authorization.

Regarding Claim 11, Stites, Ahmed, Pochuev, Srinivasan and Bodin teach the computing device of claim 8,
Bodin further teaches:
wherein the additional data further indicates at least one of: a version of an operating system (OS) of the computing device; a policy level of the security agent; user information about a user of the computing device; a strength of a password associated with the user; a location associated with the request; proxy information associated with the request; whether a security feature is enabled on the computing device; or whether the computing device has been involved in a security incident (Bodin, para 14, discloses the system 100 extracts user-agent identifiers (para 20, device identifier is also referred as user- agent identifier) and unique user identifiers (para 20, e.g., user identifier (name, e-mail address, phone number, and/or a combination thereof)) from the http requests);
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites/Ahmed/Pochuev/Srinivasan to incorporate Bodin’s teaching of extracting a user identifier such as name, email address, telephone number from the request. One would be motivated to perform such modification on Stites/Ahmed/Pochuev/Srinivasan’s system to improve the system by allowing the device identity server and/or application server to associate the authenticated device information with the user making the request. This would improve user to device mapping, auditing, policy enforcement authorization.

Regarding Claim 12, Stites, Ahmed, Pochuev, Srinivasan and Bodin teach the computing device of claim 8,
Stites further teaches:
sending the request with the identifying information to the second identity provider comprises sending the request with the identifying information using a secure tunneling mechanism between the security agent and the second identity provider; (Stites, [0020], discloses the agent 134 attaches metadata associated with the device 110 to the request 335 to form a new request 340 for an authenticated device identity, which the agent 134 sends to the device identity server 150; [0020], Stites discloses the agent 134 establishes a separate SSL tunnel to the device identity server 150 and sends the request 340 through the separate SSL tunnel.);
and the receiving the response from the second identity provider comprises receiving the response using the secure tunneling mechanism (Stites, [0022], discloses the device identity server 150 sends a redirect message 345 back to the device 110 including the authenticated device identity and any available device context information. The agent 134 receives the redirect message 345 and forwards it as a redirect message 350 to the client 132. [Examiner interprets, the secure tunneling mechanism (SSL tunnel) is implied to be used for both directions of communication, including sending the response.])
Stites and Ahmed do not explicitly disclose:
Wherein the request is an authentication request;
Wherein the identifying information is the unique identifier of the security agent;
Wherein the response is signed response.
However, Pochuev teaches:
Wherein the request is an authentication request (Pochuev, [0079], discloses that the IoT device 110 sends an authentication request 1205 to the authentication policy server.);
wherein the response is signed response (Pochuev, [0108], discloses that the RoT server 114 signs and sends the authentication response back to the authentication policy server 112.);
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites/Ahmed/Srinivasan/Bodin’s system to incorporate the teaching of Pochuev to utilize the concept of having the authentication request sent to an Identity Provider and the response back from the Identity provider to be signed. One would be motivated to make such modifications on Stites/Ahmed/Srinivasan/Bodin’s system to improve the secure management of computing devices, including their enrollment, remotely and on a larger scale by eliminating the need for secure, manual, on-site provisioning. (Pochuev, Page 2)
Pochuev does not teach; However, Srinivasan teaches:
Wherein the identifying information is the unique identifier of the security agent (Srinivasan, Column 3, lines 16-18, discloses an agent probe that queries an agent installed on the host device for a unique agent identifier; Column 6, lines 63-64, the agent 112 provides an agent identifier of the agent);
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites/Ahmed/Pochuev/Bodin’s system to incorporate the teaching of Srinivasan to utilize the concept of identifying information as a unique identifier of a security agent which strengthens the security mechanism by providing distinct and verifiable attribute tied directly to the security agent. The motivation to make such a combination would be to enhance the authentication process and prevent various attacks such as reply attack. (Srinivasan, Column 2)

Regarding Claim 14, Stites/Ahmed/Pochuev/Bodin/Srinivasan teach the computing device of claim 8,
Stites further teaches:
wherein receiving the result of the request from the first identity provider comprises at least one of: receiving an indication that access to a resource has been granted; receiving an indication that access to the resource has been denied; receiving a multifactor authentication prompt; or receiving an indication that access to the resource has been denied, and that access to another resource has been granted (Stites, [0022], discloses that the application server 120 determines whether to grant or deny access to the application resource requested in the original request message 300. The application server 120 informs the client 132 of the determination in message 370.);
Stites does not explicitly teach:
Wherein the request is an authentication request;
However, Pochuev teaches:
Wherein the request is an authentication request (Pochuev, [0079], discloses that the IoT device 110 sends an authentication request 1205 to the authentication policy server.);
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites/Ahmed/Srinivasan/Bodin’s system to incorporate the teaching of Pochuev to utilize the concept of having the authentication request sent to an Identity Provider and the response back from the Identity provider to be signed. One would be motivated to make such modifications on Stites/Ahmed/Srinivasan/Bodin’s system to improve the secure management of computing devices, including their enrollment, remotely and on a larger scale by eliminating the need for secure, manual, on-site provisioning. (Pochuev, Page 2)

Regarding Claim 26, Stites, Ahmed, Pochuev, Bodin and Srinivasan teach the method of claim 1,
Stites further teaches:
wherein receiving the result of the request from the first identity provider comprises at least one of: receiving an indication that access to a resource has been granted; receiving an indication that access to the resource has been denied; receiving a multifactor authentication prompt; or receiving an indication that access to the resource has been denied, and that access to another resource has been granted (Stites, [0022], discloses that the application server 120 determines whether to grant or deny access to the application resource requested in the original request message 300. The application server 120 informs the client 132 of the determination in message 370.);
Stites does not explicitly teach:
Wherein the request is an authentication request;
However, Pochuev teaches:
Wherein the request is an authentication request (Pochuev, [0079], discloses that the IoT device 110 sends an authentication request 1205 to the authentication policy server.);
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites/Ahmed/Srinivasan/Bodin’s system to incorporate the teaching of Pochuev to utilize the concept of having the authentication request sent to an Identity Provider and the response back from the Identity provider to be signed. One would be motivated to make such modifications on Stites/Ahmed/Srinivasan/Bodin’s system to improve the secure management of computing devices, including their enrollment, remotely and on a larger scale by eliminating the need for secure, manual, on-site provisioning. (Pochuev, Page 2)

Claim(s) 15, 17, 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Stites (U.S. 2018/0337920 A1) in view of Pochuev (US 20200145409 A1) in view of Ahmed (US 20220217132 A1) in view of Srinivasan (US 8924721 B2) further in view of Bodin (US 20130054575 A1) further in view of Jawahar (US 9948612 B1).

Regarding Claim 15, Stites teaches:
receiving, by a second identity provider, from a security agent executing on a computing device, a request with an identifying information, (Stites, [0020], discloses the agent 134 (Fig 2; agent executes on the Operating system of the device) attaches metadata associated with the device 110 to the request 335 to form a new request 340 for an authenticated device identity, which the agent 134 sends to the device identity server 150);
Wherein the new response includes the identifying information;
(Stites, [0022], lines 1-4, discloses that the device identity server 150 sends a redirect message 345 back to the device 110 including the authenticated device identity and any available device context information);
and sending, by the second identity provider, the response to the computing device (Stites, para [0022], discloses that the device identity server sends a redirect message (response) back to the computing device. This response includes the authenticated device identity and any available device context information.);
Stites, para [0030] also discloses that the agent 134 intercepts the request 335 and the agent attaches metadata associated with the device to the request; Stites does not disclose retrieving the metadata from the request.
Stites does not explicitly teach:
an identifier of the computing device was retrieved from the authentication, the identifying information being the identifier of the computing device;
wherein the request was redirected to the second identity provider based on a first identity provider sending, to the computing device, redirection data comprising a uniform resource locator (URL) managed by the second identity provider, and in response to a browser of the computing device being directed to the URL, the URL resolves to a localhost associated with the computing device in response to a browser of the computing device being redirected to the URL;
Signing, by the second identity provider, a response to the request to obtain a new response;
Wherein the request is an authentication request;
Wherein the identifying information is the unique identifier of the security agent;
Wherein the response is signed response.
Ahmed teaches:
wherein the request was redirected to the second identity provider based on a first identity provider sending, to the computing device, redirection data comprising a uniform resource locator (URL) managed by the second identity provider, and in response to a browser of the computing device being directed to the URL, the URL resolves to a localhost associated with the computing device in response to a browser of the computing device being redirected to the URL;
(Ahmed, para 40, 41, discloses that the traffic intended from the service provider for the remote identity provider (108) which is intercepted by client device and it is redirected such that its url (e.g., idp.enterprise.com) resolves to 127.0.0.1 (localhost) on the computing device.);
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites to incorporate the teaching of Ahmed to combine the technique to include URL managed by Identity provider in the redirection request such that the URL resolves to localhost and intercepting the request by an agent on the host device. One would be motivated to make such modifications on Stites to improve the system that require repeated user interactions and lack transparent support for sharing authentication across multiple local applications by providing a true single sign-on experience without requiring user intervention for each application or modifications to existing service providers. (Ahmed, Page 1)
Ahmed does not explicitly teach:
an identifier of the computing device was retrieved from the authentication, the identifying information being the identifier of the computing device;
Signing, by the second identity provider, a response to the request to obtain a new response;
wherein the request is an authentication request;
wherein the identifying information is the unique identifier of the security agent;
wherein the response is signed response;
However, Pochuev teaches:
Signing, by the second identity provider, a response to the request to obtain a new response (Pochuev, [0108], discloses that the RoT server 114 signs and to obtain authentication response.);
Wherein the request is an authentication request (Pochuev, [0079], discloses that the IoT device 110 sends an authentication request 1205 to the authentication policy server.);
wherein the response is signed response (Pochuev, [0108], discloses that the RoT server 114 signs and sends the authentication response back to the authentication policy server 112.);
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites to incorporate the teaching of Pochuev to utilize the concept of having the authentication request sent to an Identity Provider and the response back from the Identity provider to be signed. One would be motivated to make such modifications on Stites to improve the secure management of computing devices, including their enrollment, remotely and on a larger scale by eliminating the need for secure, manual, on-site provisioning. (Pochuev, Page 2)
Pochuev does not teach; However, Srinivasan teaches:
the identifying information being the identifier of the computing device (Srinivasan, Column 11, lines 37-42, discloses By monitoring host attributes (Col 15, lines 59-64, host attributes include an agent identifier of an agent 112 installed on the host device 110) of the host device that identify the host device, traffic to and from the host device, and the state of the host device, the sensor 102 can control network access of the host device according to the one or more network access zones associated with the state of the host device.);
Wherein the identifying information is the unique identifier of the security agent (Srinivasan, Column 3, lines 16-18, discloses an agent probe that queries an agent installed on the host device for a unique agent identifier; Column 6, lines 63-64, the agent 112 provides an agent identifier of the agent);
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites to incorporate the teaching of Srinivasan to utilize the concept of identifying information as a unique identifier of a security agent which strengthens the security mechanism by providing distinct and verifiable attribute tied directly to the security agent. The motivation to make such a combination would be to enhance the authentication process and prevent various attacks such as reply attack. (Srinivasan, Column 2)
Srinivasan does not explicitly teach; However; Bodin teaches:
an identifier of the computing device was retrieved from the authentication (Bodin, para 14, discloses the system 100 extracts user-agent identifiers (para 20, device identifier is also referred as user- agent identifier) and unique user identifiers from the http requests.)
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites to incorporate the teaching of Bodin to configure Stite’s agent 134, when intercepting the redirected request for a device identity, to parse the request and extract a device/user-agent identifier from that request, as taught by Bodin and use that extracted device identifier that is attached as metadata and forwarded to the device identity server. The motivation to make such a combination would leverage identifiers that are already present in the intercepted request, reduces reliance on additional client-side configuration and yields predictable, incremental improvements in correlating a given request with a particular device for authorization to use device context and identity to enforce finer-grained access policies.
Stites/Ahmed/Pochuev/Bodin/Srinivasan does not explicitly teach; However, Jawahar teaches:
receiving, by the second identity provider, a query from the first identity provider for additional data indicating compatibility of the computing device (Jawahar, Col 25, lines 58-67 discloses in step 828, the identity provider gateway 725 may transmit, to the server 730 (which may comprise a device management server), a request to determine whether the client (e.g., mobile) device is compliant with security policies.);
and sending, by the second identity provider, the additional data to the first identity provider (Jawahar, Col 26, lines 4-7 discloses in step 830, the server 730 may return, to the identity provider gateway 725, compliance information, which may indicate whether the client device is compliant.)
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites to incorporate Jawahar’s device-compliance request mechanism so that the first identity provider can obtain compatibility data for the client device from the associated device management service before completing the authentication or access authorization. One would be motivated to perform such modification on Stites’s system to provide the first identity provider with authoritative compatibility information about the device after receiving the device authentication response. Doing so would improve the authentication system by enabling conditional access based not only on the authenticated device identity, but also on current device compliance information.

Regarding Claim 17, Stites, Ahmed, Pochuev, Srinivasan, Bodin and Jawahar teach the method of claim 15,
Stites further teaches:
validating the identifying information by confirming that the identifying information is one of a plurality of identifying information associated with security agents that have been installed on computing devices (Stites, [0021], discloses that the device identity server 150, on receiving the request 340 (para 20, request created by the agent by attaching the metadata associated with the device) authenticates the device 110 (e.g., by validating the metadata) and generates a secure assertion with the proper level of trust indicated by a stored policy. The device identity provider 150 may also send a request 342 to a context server 160 to verify the device context of the device 110. The context server 160 returns information associated with the device context in message 344; [Examiner interprets, the device identity server validates the identifier (device metadata) as part of its authentication process, confirming it against stored information(context).]);
Stites does not explicitly teach:
Wherein the request is an authentication request;
Wherein the identifying information is the unique identifier of the security agent;
However, Pochuev teaches:
Wherein the request is an authentication request (Pochuev, [0079], discloses that the IoT device 110 sends an authentication request 1205 to the authentication policy server.);
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites/Ahmed/Srinivasan/Bodin’s system to incorporate the teaching of Pochuev to utilize the concept of having the authentication request sent to an Identity Provider and the response back from the Identity provider to be signed. One would be motivated to make such modifications on Stites/Ahmed/Srinivasan/Bodin’s system to improve the secure management of computing devices, including their enrollment, remotely and on a larger scale by eliminating the need for secure, manual, on-site provisioning. (Pochuev, Page 2)
Pochuev does not teach; However, Srinivasan teaches:
Wherein the identifying information is the unique identifier of the security agent (Srinivasan, Column 3, lines 16-18, discloses an agent probe that queries an agent installed on the host device for a unique agent identifier; Column 6, lines 63-64, the agent 112 provides an agent identifier of the agent);
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites/Ahmed/Pochuev/Bodin/Jawahar’s system to incorporate the teaching of Srinivasan to utilize the concept of identifying information as a unique identifier of a security agent which strengthens the security mechanism by providing distinct and verifiable attribute tied directly to the security agent. The motivation to make such a combination would be to enhance the authentication process and prevent various attacks such as reply attack. (Srinivasan, Column 2)

Regarding Claim 19, Stites, Ahmed, Pochuev, Srinivasan, Bodin and Jawahar teach the method of claim 15,
Stites further teaches:
the receiving the request with the identifying information from the computing device comprises receiving the request with the identifying information using a secure tunneling mechanism between the security agent and the second identity provider; (Stites, [0020], discloses the agent 134 attaches metadata associated with the device 110 to the request 335 to form a new request 340 for an authenticated device identity, which the agent 134 sends to the device identity server 150; [0020], Stites discloses the agent 134 establishes a separate SSL tunnel to the device identity server 150 and sends the request 340 through the separate SSL tunnel.);
and the sending the response to the computing device comprises sending the response using the secure tunneling mechanism. (Stites, [0022], discloses the device identity server 150 sends a redirect message 345 back to the device 110 including the authenticated device identity and any available device context information. The agent 134 receives the redirect message 345 and forwards it as a redirect message 350 to the client 132. [Examiner interprets, the secure tunneling mechanism (SSL tunnel) is implied to be used for both directions of communication, including sending the response.])
Stites and Ahmed do not explicitly disclose:
Wherein the request is an authentication request;
Wherein the identifying information is the unique identifier of the security agent;
Wherein the response is signed response.
However, Pochuev teaches:
Wherein the request is an authentication request (Pochuev, [0079], discloses that the IoT device 110 sends an authentication request 1205 to the authentication policy server.);
wherein the response is signed response (Pochuev, [0108], discloses that the RoT server 114 signs and sends the authentication response back to the authentication policy server 112.);
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites/Ahmed/Srinivasan/Bodin/Jawahar’s to incorporate the teaching of Pochuev to utilize the concept of having the authentication request sent to an Identity Provider and the response back from the Identity provider to be signed. One would be motivated to make such modifications on Stites/Ahmed/Srinivasan/Bodin/Jawahar’s to improve the secure management of computing devices, including their enrollment, remotely and on a larger scale by eliminating the need for secure, manual, on-site provisioning. (Pochuev, Page 2)
Pochuev does not teach; However, Srinivasan teaches:
Wherein the identifying information is the unique identifier of the security agent (Srinivasan, Column 3, lines 16-18, discloses an agent probe that queries an agent installed on the host device for a unique agent identifier; Column 6, lines 63-64, the agent 112 provides an agent identifier of the agent);
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites/Ahmed/Pochuev/Bodin’s to incorporate the teaching of Srinivasan to utilize the concept of identifying information as a unique identifier of a security agent which strengthens the security mechanism by providing distinct and verifiable attribute tied directly to the security agent. The motivation to make such a combination would be to enhance the authentication process and prevent various attacks such as reply attack. (Srinivasan, Column 2)

Regarding Claim 20, Stites, Ahmed, Pochuev, Bodin, Srinivasan and Jawahar teach the method of claim 15,
Bodin further teaches:
wherein the additional data further indicates at least one of: a version of an operating system (OS) of the computing device; a policy level of the security agent; user information about a user of the computing device; a strength of a password associated with the user; a location associated with the request; proxy information associated with the request; whether a security feature is enabled on the computing device; or whether the computing device has been involved in a security incident (Bodin, para 14, discloses the system 100 extracts user-agent identifiers (para 20, device identifier is also referred as user- agent identifier) and unique user identifiers (para 20, e.g., user identifier (name, e-mail address, phone number, and/or a combination thereof)) from the http requests);
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites/Ahmed/Pochuev/Srinivasan/Jawahar to incorporate Bodin’s teaching of extracting a user identifier such as name, email address, telephone number from the request. One would be motivated to perform such modification on Stites/Ahmed/Pochuev/Srinivasan/Jawahar’s system to improve the system by allowing the device identity server and/or application server to associate the authenticated device information with the user making the request. This would improve user to device mapping, auditing, policy enforcement authorization.

Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Stites (U.S. 2018/0337920 A1) in view of Pochuev (US 20200145409 A1) further in view of Ahmed (US 20220217132 A1) in view of Srinivasan (US 8924721 B2) further in view of Bodin (US 20130054575 A1) further in view of Tredoux (US 9515836 B2).

Regarding Claim 13, Stites, Ahmed, Srinivasan, Pochuev and Bodin teach the method of claim 8,
Tredoux teaches:
the signed response includes a timestamp indicating a time at which the second identity provider signed the signed response with a private key accessible to the second identity provider (Tredoux, Column 8, lines 52-67, discloses that the token server uses its private key to sign the token (i.e., the response); Tredoux further discloses that the signed token includes temporal identifiers such as timestamp at which either the token was generated or the request for the token was received by the token server);
It would have been obvious to a person of ordinary skills in the art before the effective filing date have modified the system of Stites, Ahmed, Srinivasan, Pochuev and Bodin to incorporate the teaching of Tredoux to include timestamps in signed responses from an IdP. One would be motivated to make such modifications in Stites, Ahmed, Srinivasan, Bodin and Pochuev’s system to improve system’s security by making location spoofing significantly more difficult to execute. (Tredoux, Column 1, 2)

Claim 22 is rejected under 35 U.S.C. 103 as being unpatentable over Stites (U.S. 2018/0337920 A1) in view of Pochuev (US 20200145409 A1) further in view of Ahmed (US 20220217132 A1) in view of Srinivasan (US 8924721 B2) further in view of Bodin (US 20130054575 A1) in view of Jawahar (US 9948612 B1) further in view of Tredoux (US 9515836 B2).

Regarding Claim 22, Stites, Ahmed, Srinivasan, Bodin, Jawahar and Pochuev teach the method of claim 15,
Tredoux teaches:
the signed response further includes a timestamp indicating a time at which the second identity provider signed the signed response with a private key accessible to the second identity provider (Tredoux, Column 8, lines 52-67, discloses that the token server uses its private key to sign the token (i.e., the response); Tredoux further discloses that the signed token includes temporal identifiers such as timestamp at which either the token was generated or the request for the token was received by the token server);
It would have been obvious to a person of ordinary skills in the art before the effective filing date have modified the system of Stites, Ahmed, Srinivasan, Bodin and Pochuev to incorporate the teaching of Tredoux to include timestamps in signed responses from an IdP. One would be motivated to make such modifications in Stites, Ahmed, Srinivasan, Bodin and Pochuev’s system to improve system’s security by making location spoofing significantly more difficult to execute. (Tredoux, Column 1, 2)

Claims 21 is rejected under 35 U.S.C. 103 as being unpatentable over Stites (U.S. 2018/0337920 A1) in view of Pochuev (US 20200145409 A1) further in view of Ahmed (US 20220217132 A1) in view of Srinivasan (US 8924721 B2) further in view of Bodin (US 20130054575 A1) in view of in view of Jawahar (US 9948612 B1) further more in view of Prasad (US 10645073 B1)

Regarding Claim 21, Stites, Ahmed, Srinivasan, Bodin and Pochuev teach the method of claim 15,
Prasad teaches:
prior to the receiving the request, assigning, by the second identity provider, the identifying information (Prasad, Column 7, lines 40-41, authentication tokens may be generated for and/or assigned to a particular endpoint device or user; Column 8, lines 42-44, systems may generate or identify an authentication token prior to receiving a request from request module);
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified system of Stites/Ahmed/Srinivasan/Bodin/Pochuev’s system to incorporate the teaching of Prasad to utilize the concept of assigning unique identifying information of particular endpoint device prior to receiving request to strengthens the security mechanism by providing fast and automatic authentication scheme. The motivation to make such a combination would be to enhance the authentication process and ensuring fast and automatic authentication scheme without requiring any modification to encrypted application packages. (Prasad, Column 3)
Prasad does not explicitly teach:
Wherein the request is an authentication request;
Wherein the identifying information is the unique identifier of the security agent;
However, Pochuev teaches:
Wherein the request is an authentication request (Pochuev, [0079], discloses that the IoT device 110 sends an authentication request 1205 to the authentication policy server.);
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites/Ahmed/Srinivasan/Bodin/Jawahar’s system to incorporate the teaching of Pochuev to utilize the concept of having the authentication request sent to an Identity Provider and the response back from the Identity provider to be signed. One would be motivated to make such modifications on Stites/Ahmed/Srinivasan/Bodin/Jawahar’s to improve the secure management of computing devices, including their enrollment, remotely and on a larger scale by eliminating the need for secure, manual, on-site provisioning. (Pochuev, Page 2)
Pochuev does not teach; However, Srinivasan teaches:
Wherein the identifying information is the unique identifier of the security agent (Srinivasan, Column 3, lines 16-18, discloses an agent probe that queries an agent installed on the host device for a unique agent identifier; Column 6, lines 63-64, the agent 112 provides an agent identifier of the agent);
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites/Ahmed/Pochuev/Bodin/Jawahar’s to incorporate the teaching of Srinivasan to utilize the concept of identifying information as a unique identifier of a security agent which strengthens the security mechanism by providing distinct and verifiable attribute tied directly to the security agent. The motivation to make such a combination would be to enhance the authentication process and prevent various attacks such as reply attack. (Srinivasan, Column 2)

Claims 23 and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Stites (U.S. 2018/0337920 A1) in view of Pochuev (US 20200145409 A1) further in view of Ahmed (US 20220217132 A1) in view of Srinivasan (US 8924721 B2) further in view of Bodin (US 20130054575 A1) in view of in view of Jawahar (US 9948612 B1) further more in view of Prasad (US 10645073 B1)

Regarding Claim 23, Stites, Ahmed, Srinivasan, Bodin and Pochuev teach the method of claim 1,
Prasad teaches:
the identifying information was assigned to the security agent by the second identity provider. (Prasad, Column 7, lines 40-41, authentication tokens may be generated for and/or assigned to a particular endpoint device or user; Column 8, lines 42-44, systems may generate or identify an authentication token prior to receiving a request from request module);
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified system of Stites/Ahmed/Srinivasan/Bodin/Pochuev’s system to incorporate the teaching of Prasad to utilize the concept of assigning unique identifying information of particular endpoint device prior to receiving request to strengthens the security mechanism by providing fast and automatic authentication scheme. The motivation to make such a combination would be to enhance the authentication process and ensuring fast and automatic authentication scheme without requiring any modification to encrypted application packages. (Prasad, Column 3)
Prasad does not explicitly teach:
Wherein the identifying information is the unique identifier of the security agent;
However, Srinivasan discloses:
Wherein the identifying information is the unique identifier of the security agent (Srinivasan, Column 3, lines 16-18, discloses an agent probe that queries an agent installed on the host device for a unique agent identifier; Column 6, lines 63-64, the agent 112 provides an agent identifier of the agent);
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites/Ahmed/Bodin/Pochuev’s system to incorporate the teaching of Srinivasan to utilize the concept of identifying information as a unique identifier of a security agent which strengthens the security mechanism by providing distinct and verifiable attribute tied directly to the security agent. The motivation to make such a combination would be to enhance the authentication process and prevent various attacks such as reply attack. (Srinivasan, Column 2)

Regarding Claim 24, Stites, Ahmed, Srinivasan, Bodin and Pochuev teach the method of claim 8,
Prasad teaches:
the identifying information was assigned to the security agent by the second identity provider. (Prasad, Column 7, lines 40-41, authentication tokens may be generated for and/or assigned to a particular endpoint device or user; Column 8, lines 42-44, systems may generate or identify an authentication token prior to receiving a request from request module);
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified system of Stites/Ahmed/Srinivasan/Bodin/Pochuev’s system to incorporate the teaching of Prasad to utilize the concept of assigning unique identifying information of particular endpoint device prior to receiving request to strengthens the security mechanism by providing fast and automatic authentication scheme. The motivation to make such a combination would be to enhance the authentication process and ensuring fast and automatic authentication scheme without requiring any modification to encrypted application packages. (Prasad, Column 3)
Prasad does not explicitly teach:
Wherein the identifying information is the unique identifier of the security agent;
However, Srinivasan discloses:
Wherein the identifying information is the unique identifier of the security agent (Srinivasan, Column 3, lines 16-18, discloses an agent probe that queries an agent installed on the host device for a unique agent identifier; Column 6, lines 63-64, the agent 112 provides an agent identifier of the agent);
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites/Ahmed/Bodin/Pochuev’s system to incorporate the teaching of Srinivasan to utilize the concept of identifying information as a unique identifier of a security agent which strengthens the security mechanism by providing distinct and verifiable attribute tied directly to the security agent. The motivation to make such a combination would be to enhance the authentication process and prevent various attacks such as reply attack. (Srinivasan, Column 2)

Claims 7 and 25 are rejected under 35 U.S.C. 103 as being unpatentable over Stites (U.S. 2018/0337920 A1) in view of Pochuev (US 20200145409 A1) further in view of Ahmed (US 20220217132 A1) in view of Srinivasan (US 8924721 B2) further in view of Bodin (US 20130054575 A1) further more in view of Suraparaju (US 20200106766 A1)

Regarding Claim 7, Stites, Ahmed, Srinivasan, Bodin and Pochuev teach the method of claim 1,
Stites further teaches:
the request is sent with the identifying information to the second identity provider using Security Assertion Markup Language (SAML) protocol; (Stites, [0011], discloses that the identifying information such as authenticated device identity or authenticated user identity is transmitted using a standardized protocol such as SAML. The device sends the SAML-based assertion to the device identity server 150.)
Stites does not explicitly teach:
Wherein the request is an authentication request;
Wherein the identifying information is the unique identifier of the security agent;
The signed response includes a signed SAML claim.
However, Pochuev teaches:
Wherein the request is an authentication request (Pochuev, [0079], discloses that the IoT device 110 sends an authentication request 1205 to the authentication policy server.);
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites/Ahmed/Bodin/Srinivasan’s system to incorporate the teaching of Pochuev to utilize the concept of having the authentication request sent to an Identity Provider and the response back from the Identity provider to be signed. One would be motivated to make such modifications on Stites/Ahmed/Bodin/Srinivasan’s system to improve the secure management of computing devices, including their enrollment, remotely and on a larger scale by eliminating the need for secure, manual, on-site provisioning. (Pochuev, Page 2)
Pochuev does not teach; However, Srinivasan teaches:
Wherein the identifying information is the unique identifier of the security agent (Srinivasan, Column 3, lines 16-18, discloses an agent probe that queries an agent installed on the host device for a unique agent identifier; Column 6, lines 63-64, the agent 112 provides an agent identifier of the agent);
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites/Ahmed/Bodin/Pochuev’s system to incorporate the teaching of Srinivasan to utilize the concept of identifying information as a unique identifier of a security agent which strengthens the security mechanism by providing distinct and verifiable attribute tied directly to the security agent. The motivation to make such a combination would be to enhance the authentication process and prevent various attacks such as reply attack. (Srinivasan, Column 2)
Stites, Ahmed, Pochuev and Srinivasan does not explicitly disclose:
The signed response includes a signed SAML claim.
However, Suraparaju discloses:
The signed response includes a signed SAML claim (Suraparaju, para [0027], discloses that the SAML-IdP returns a signed SAML response.).
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites/Ahmed/Pocheuv/Bodin/Srinivasan’s system to incorporate the teaching of Suraparaju to include the concept to utilize a digitally sign a response by an IdP. One would be motivated to make such modifications on Stites/Ahmed/Bodin/Pocheuv/Srinivasan’s system to avoid forced re-authentication for already authenticated users, and bridges the gap between SP-initiated and IdP-initiated semantic using redirections and token-based identity propagation. (Suraparaju, Page 1, 2)

Regarding Claim 25, Stites, Ahmed, Srinivasan, Bodin and Pochuev teach the computing device of claim 8,
Stites further teaches:
the request is sent with the identifying information to the second identity provider using Security Assertion Markup Language (SAML) protocol; (Stites, [0011], discloses that the identifying information such as authenticated device identity or authenticated user identity is transmitted using a standardized protocol such as SAML. The device sends the SAML-based assertion to the device identity server 150.)
Stites does not explicitly teach:
Wherein the request is an authentication request;
Wherein the identifying information is the unique identifier of the security agent;
The signed response includes a signed SAML claim.
However, Pochuev teaches:
Wherein the request is an authentication request (Pochuev, [0079], discloses that the IoT device 110 sends an authentication request 1205 to the authentication policy server.);
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites/Ahmed/Bodin/Srinivasan’s system to incorporate the teaching of Pochuev to utilize the concept of having the authentication request sent to an Identity Provider and the response back from the Identity provider to be signed. One would be motivated to make such modifications on Stites/Ahmed/Bodin/Srinivasan’s system to improve the secure management of computing devices, including their enrollment, remotely and on a larger scale by eliminating the need for secure, manual, on-site provisioning. (Pochuev, Page 2)

Pochuev does not teach; However, Srinivasan teaches:
Wherein the identifying information is the unique identifier of the security agent (Srinivasan, Column 3, lines 16-18, discloses an agent probe that queries an agent installed on the host device for a unique agent identifier; Column 6, lines 63-64, the agent 112 provides an agent identifier of the agent);
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites/Ahmed/Bodin/Pochuev’s system to incorporate the teaching of Srinivasan to utilize the concept of identifying information as a unique identifier of a security agent which strengthens the security mechanism by providing distinct and verifiable attribute tied directly to the security agent. The motivation to make such a combination would be to enhance the authentication process and prevent various attacks such as reply attack. (Srinivasan, Column 2)
Stites, Ahmed, Pochuev and Srinivasan does not explicitly disclose:
The signed response includes a signed SAML claim.
However, Suraparaju discloses:
The signed response includes a signed SAML claim (Suraparaju, para [0027], discloses that the SAML-IdP returns a signed SAML response.).
It would have been obvious to a person of ordinary skill in the art before the effective filing date to have modified Stites/Ahmed/Pocheuv/Bodin/Srinivasan’s system to incorporate the teaching of Suraparaju to include the concept to utilize a digitally sign a response by an IdP. One would be motivated to make such modifications on Stites/Ahmed/Pocheuv/Bodin/Srinivasan’s system to avoid forced re-authentication for already authenticated users, and bridges the gap between SP-initiated and IdP-initiated semantic using redirections and token-based identity propagation. (Suraparaju, Page 1, 2)

Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMIT KHADKA whose telephone number is [phone]. The examiner can normally be reached Monday - Friday, 8:00 am - 5: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, Jeffrey L. Nickerson can be reached at [phone]. 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.

/AMIT KHADKA/Examiner, Art Unit 2432
/Jeffrey Nickerson/ Supervisory Patent Examiner, Art Unit 2432

Prosecution Timeline

• Aug 09, 2022: Application Filed
• Jul 03, 2024: Non-Final Rejection mailed — §103, §112
• Oct 03, 2024: Response Filed
• Dec 31, 2024: Final Rejection mailed — §103, §112
• Mar 31, 2025: Request for Continued Examination
• Apr 07, 2025: Response after Non-Final Action
• Jun 10, 2025: Non-Final Rejection mailed — §103, §112
• Sep 02, 2025: Response Filed
• Dec 16, 2025: Final Rejection mailed — §103, §112
• Mar 11, 2026: Request for Continued Examination
• Mar 19, 2026: Response after Non-Final Action
• Jul 09, 2026: Non-Final Rejection mailed — §103, §112 (current)