Detailed Action
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This is in response to Application with case number 18/927677, filed on 11/25/2024 in which claims 1-20 are presented for examination.
Status of Claims
Claims 1-20 are pending, of which claims 1, 12, and 17 are in independent form.
Specification
The examiner notes that the Specification does not include any URL links and Trademark terms requiring capitalization.
The examiner notes that the abstract is in narrative form and is limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The examiner also notes that Abstract includes no legal phraseology.
The examiner notes no claims invokes 35 USC § 112 6th paragraph.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1, 2, 8, 9, 12, 13, 17-19 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-18 of U.S. Patent No. 12,169,545 B2.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-2, 4-7, 11-13, 15-18, 20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Zerrad et al. (US 2020/0304503 A1) hereinafter Zerrad.
As to claim 1, Zerrad teaches an apparatus (e.g., client device 802/mobile device 149 comprising Identity Broker 806 and/or Security Component 805) for authentication by a client device (see para. [0253]-[0254]; It is noted that in response to a request for access to a service provided by service provider 704, service provider 704 sends a request for authentication to identity broker 806 installed in the client device and identity broker 806 performs compliance check of the device. Once the device is found to be compliant, identity broker 806 forwards an authentication request to the identity provider 708.), comprising:
a processor (see para. [0026] “In one embodiment, a method includes: receiving, by an identity broker, a request regarding access by a client device to a service provided by a service provider; in response to receiving the request, determining, by the identity broker, an identity of the client device; determining, by at least one processor of the identity broker, whether the client device is in a secure state”);
memory coupled with the processor (see para. [0159], e.g., computing device including processor 233 and a memory 227; see also para. [0186]); and
instructions stored in the memory and executable by the processor configured to cause the apparatus to:
receive, from a one or more third-party signal providers, via a corresponding one or more authentication plug-ins (e.g., security component 805 in Fig. 8; see para. [0064], “…a component is provided by the application’s creator or by a third party.”), and based on detection of an authentication event, device posture signals (see para. [0083] “In one embodiment, when component 104 makes a request for access to the service, the request is first sent to service provider 170. Then, service provider 170 forwards the access request to monitoring server 150. Monitoring server 150 performs a security evaluation of risk factors associated with mobile device 149. In one embodiment, the risk factors are used to determine the context of the mobile device 149. If the evaluation determines that the configuration is not secure and/or that mobile device 149 is currently operating in violation of one or more rules 116, server 150 blocks access by mobile device 149 to the service.” It is noted that the monitoring server 150 is the security component residing in the user mobile device or the monitoring server 150 closely works with security component in discovering the security context of the mobile device 149.; see para. [0097] “In some embodiments, a mechanism may be used to authenticate a device and a user of the device by authenticating via an identity provider in conjunction with a security component coupled to a monitoring server 150 including one or more of the following: requiring that an SSL client certificate be supplied for each access request by mobile device 149, evaluating authentication factors provided from network connection establishment (e.g., Wi-Fi, VPN, cellular, etc.) by mobile device 149, or evaluating authentication factors provided from establishment of a network tunnel or proxy connection for mobile device 149.”; see para. [0228] “In at least one embodiment, the identity broker checks for mobile device compliance by requesting the compliance information from the security component associated with the mobile device. In another embodiment, the identity broker is notified by the security component associated with the mobile device about mobile device compliance. In at least one embodiment, the identity broker revokes access to the service based on the security state associated with the mobile device.”), wherein each authentication plug-in indicates how an authenticator component (e.g., identity broker and or security component) is to communicate with a corresponding third-party signal provider to obtain a corresponding device posture signal associated with the client device (see para. [0229] “ the identity broker uses historical data stored by the security platform which in at least one embodiment is transmitted to the identity broker by the security component. In one example, the historical data includes information regarding undesirable behavior or other risks associated with particular software applications and/or components (e.g., that have been previously installed on other user devices monitored by the security platform). In one example, the identity broker uses risk assessments from the security platform that are based on comparison of a software component on a user device to a similar component stored in a data repository. In one example, the comparison is based on behavioral and/or structural characteristics.”), and wherein the device posture signals provide an indication of a safety of the client device based on one or more characteristics of the client device (see para. [0228] “In at least one embodiment, the identity broker checks for mobile device compliance by requesting the compliance information from the security component associated with the mobile device. In another embodiment, the identity broker is notified by the security component associated with the mobile device about mobile device compliance. In at least one embodiment, the identity broker revokes access to the service based on the security state associated with the mobile device.”);
send, to an identity provider system, the device posture signals (see para. [0243] “If the identity broker 706 determines that security component 705 is installed and that the device is in a secure state, then the authentication request is passed to identity provider 708.”); and
receive, from the identity provider system, an indication of whether a user of
the client device is authenticated (see para. [0263]-[0264] “[0263] At block 907, in response to determining that the client device is in the secure state, an authentication request for the client device is sent to an identity provider. The authentication request includes the identity of the client device. In one example, identity broker 706 sends a communication with an authentication request to identity provider 708. [0264] At block 909, an authentication is received from the identity provider in response to the authentication request. The authentication authorizes the access by the client device. In one example, identity provider 708 approves access by client device 702 and sends an authentication communication to identity broker 706.”).
As to claim 12, Zerrad teaches an apparatus for authentication by a third-party signal provider system, comprising: a processor; memory coupled with the processor; and instructions stored in the memory and executable by the processor configured to cause the apparatus to:
send, to one or more client devices, an authentication plug-in (e.g., security component 805 in Fig. 8; see para. [0064], “…a component is provided by the application’s creator or by a third party.”) that implements an authentication plug-in interface of an authenticator component (see Fig. 8 identify broker 706l; see para. [0112] “In one embodiment, a user of mobile device 149 is attempting to log into a service at the domain service.com provided by service provider 170. The user enters her username and password. Based on the user entering her e-mail address or the domain name of the e-mail address, service provider 170 redirects this access request to an identity provider (e.g., an identity sign-on provider such as the Okta service). The user then provides her username and password to the identity provider. In one example, this communication occurs over protocols like SAML 2.0 (Security Assertion Markup Language (SAML) is an XML-based data format for exchanging authentication and authorization data). In one embodiment, SAML chaining is used with multiple identity providers that all consult each other before a user can log in. The identity broker can be communicatively positioned between the mobile device and an identity provider. In at least one embodiment, the identity provider is communicatively coupled to a security component.”) ;
receive, from an instance of the authentication plug-in implemented at a client device of the one or more client devices, a request for a device posture signal; and send, to the authentication plug-in implemented at the client device, the device posture signal, wherein the device posture signal provides an indication of a safety of the client device based on one or more characteristics of the client device (see para. [0083] “In one embodiment, when component 104 makes a request for access to the service, the request is first sent to service provider 170. Then, service provider 170 forwards the access request to monitoring server 150. Monitoring server 150 performs a security evaluation of risk factors associated with mobile device 149. In one embodiment, the risk factors are used to determine the context of the mobile device 149. If the evaluation determines that the configuration is not secure and/or that mobile device 149 is currently operating in violation of one or more rules 116, server 150 blocks access by mobile device 149 to the service.” It is noted that the monitoring server 150 is the security component residing in the user mobile device or the monitoring server 150 closely works with security component in discovering the security context of the mobile device 149.).
As to claim 17, Zerrad teaches an apparatus for authentication by an identity provider system (see identity provider 708 in Fig. 8), comprising:
a processor; memory coupled with the processor; and instructions stored in the memory and executable by the processor configured to cause the apparatus to:
define an authentication plug-in interface for authentication plug-ins implemented at one or more client devices; send, to the one or more client devices for installation, an authenticator component that obtains device posture signals from the authentication plug-ins implemented at the one or more client devices (see Fig. 8 identify broker 706l; see para. [0112] “In one embodiment, a user of mobile device 149 is attempting to log into a service at the domain service.com provided by service provider 170. The user enters her username and password. Based on the user entering her e-mail address or the domain name of the e-mail address, service provider 170 redirects this access request to an identity provider (e.g., an identity sign-on provider such as the Okta service). The user then provides her username and password to the identity provider. In one example, this communication occurs over protocols like SAML 2.0 (Security Assertion Markup Language (SAML) is an XML-based data format for exchanging authentication and authorization data). In one embodiment, SAML chaining is used with multiple identity providers that all consult each other before a user can log in. The identity broker can be communicatively positioned between the mobile device and an identity provider. In at least one embodiment, the identity provider is communicatively coupled to a security component.”);
receive, from a client device of the one or more client devices, a one or more device posture signals, the one or more device posture signals generated by one or more third-party signal providers and obtained from one or more of the authentication plug-ins implemented at the client device (see para. [0083] “In one embodiment, when component 104 makes a request for access to the service, the request is first sent to service provider 170. Then, service provider 170 forwards the access request to monitoring server 150. Monitoring server 150 performs a security evaluation of risk factors associated with mobile device 149. In one embodiment, the risk factors are used to determine the context of the mobile device 149. If the evaluation determines that the configuration is not secure and/or that mobile device 149 is currently operating in violation of one or more rules 116, server 150 blocks access by mobile device 149 to the service.” It is noted that the monitoring server 150 is the security component residing in the user mobile device or the monitoring server 150 closely works with security component in discovering the security context of the mobile device 149.), wherein the one or more device posture signals provide an indication of a safety of the client device based on one or more characteristics of the client device (see para. [0228] “In at least one embodiment, the identity broker checks for mobile device compliance by requesting the compliance information from the security component associated with the mobile device. In another embodiment, the identity broker is notified by the security component associated with the mobile device about mobile device compliance. In at least one embodiment, the identity broker revokes access to the service based on the security state associated with the mobile device.”); and
determine, based on the one or more device posture signals, whether to authenticate a user of the client device (see para. [0263]-[0264] “[0263] At block 907, in response to determining that the client device is in the secure state, an authentication request for the client device is sent to an identity provider. The authentication request includes the identity of the client device. In one example, identity broker 706 sends a communication with an authentication request to identity provider 708. [0264] At block 909, an authentication is received from the identity provider in response to the authentication request. The authentication authorizes the access by the client device. In one example, identity provider 708 approves access by client device 702 and sends an authentication communication to identity broker 706.”).
As to claim 2, in view of claim 1, Zerrad teaches wherein the instructions are executable by the processor further configured to cause the apparatus to:
obtain, from an operating system (OS) of the client device and based on
detection of the authentication event, second device posture signals (see para. [0294]-[0297], e.g., telemetry data from security component regarding a new application installed on the client device, particular URLs being requested in the resource access request, historical risk data revealing security status of the requesting device or user).
As to claim 4, in view of claim 1, Zerrad teaches wherein the instructions are executable by the processor further configured to cause the apparatus to:
obtain, from at least one configuration file of the client device and responsive to
detection of the authentication event, third device posture signals (see para. [0294]-[0297], e.g., telemetry data from security component regarding a new application installed on the client device, particular URLs being requested in the resource access request, historical risk data revealing security status of the requesting device or user)..
As to claim 5, in view of claim 4, Zerrad teaches wherein the third device posture signals comprise an indication of a state of the client device (see para. [0026] “…determining, by at least one processor of the identity broker, whether the client device is in a secure state; in response to determining that the client device is in the secure state, sending, by the identity broker, an authentication request for the client device to an identity provider, the authentication request including the identity of the client device...”; see also para. [0136]).
As to claims 6, and 15, in view of claims 1, and 12, respectively, Zerrad teaches wherein the device posture signals comprise Endpoint Detection and Response (EDR) signals, Mobile Device Management (MDM) signals, or a combination thereof (see para. [0137] “In at least one embodiment the risk level can be associated with multiple policies based on various factors. For example, if a banking service is associated with a “not secure” security state when a mobile device has an out of date operating system, additional policy consideration can be factored to determine security state of the mobile device. For example, a device managed by an MDM can be considered more secure than non-managed devices. Therefore in the example described above, a managed mobile device with an out of date operating system can be identified as having a “moderately secure” security state.”).
As to claim 11, in view of claim 1, Zerrad teaches wherein the instructions are executable by the processor further configured to cause the apparatus to: receive a request for access to a resource requiring authentication, wherein detection of the authentication event is based on the request (see para. [0253]-[0254]; It is noted that in response to a request for access to a service provided by service provider 704, service provider 704 sends a request for authentication to identity broker 806 installed in the client device and identity broker 806 performs compliance check of the device. Once the device is found to be compliant, identity broker 806 forwards an authentication request to the identity provider 708.).
As to claim 13, in view of claim 12, Zerrad teaches wherein the authenticator component is implemented at the one or more client devices (e.g., security component 805 in Fig. 8; see para. [0064], “…a component is provided by the application’s creator or by a third party.”)
As to claim 18, in view of claim 17, Zerrad teaches wherein the instructions are executable by the processor further configured to cause the apparatus to: responsive to an indication of an authentication event at the client device: determine, based on an organization associated with the client device, an authentication policy; select, based on the authentication policy, a set of device posture signals to receive from the client device; and transmit, to the client device, an indication of the selected set of device posture signals to receive from the client device, wherein the one or more device posture signals received from the client device comprises the selected set of device posture signals (see para. [0227] “[0227] Device compliance can be determined based on one or more policies. In some embodiments the compliance is based on the risk levels (can be defined in policies) or risks tolerated by the enterprises, services, device users, or user groups. A policy can be service specific, for example a banking service can have a policy requiring a secure network connection and when the networking connection is not secure, the device can be identified as “not compliant.” In another example, the policies can be applicable to all enterprise services, or specific to a device user or user group. For example, in an enterprise the executive team can be associated with a compliance policy different from the policies associated with other employees.”)
As to claim 20, in view of claim 17, respectively, Zerrad teaches wherein the device posture signals comprise Endpoint Detection and Response (EDR) signals, Mobile Device Management (MDM) signals, or a combination thereof (see para. [0137] “In at least one embodiment the risk level can be associated with multiple policies based on various factors. For example, if a banking service is associated with a “not secure” security state when a mobile device has an out of date operating system, additional policy consideration can be factored to determine security state of the mobile device. For example, a device managed by an MDM can be considered more secure than non-managed devices. Therefore in the example described above, a managed mobile device with an out of date operating system can be identified as having a “moderately secure” security state.”), and wherein the device posture signals comprise an indication of a risk score, a compliance score, a trust score, a zero trust assurance (ZTA) score, a status of a system patch, an existence of a known vulnerability, a presence of malware, a presence of quarantined files, or any combination thereof (see para. [0137] “In at least one embodiment the risk level can be associated with multiple policies based on various factors. For example, if a banking service is associated with a “not secure” security state when a mobile device has an out of date operating system, additional policy consideration can be factored to determine security state of the mobile device.”).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 3, 10, 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zerrad, in view of Bansal et al. (US 2019/0158503 A1) hereinafter Bansal.
As to claim 3, in view of claim 2, Zerrad does not explicitly teach but Bansal teaches wherein the second device posture signals comprise an indication of a status of anti-malware software, a firewall, a secure operating system boot, or any combination thereof (see para. [0135]-[0136] “[0135] The multidimensional risk profiling process 1000 includes the mobile device coupled to the cloud based security system through a tunnel via the client application (step 1004). That is, the user is granted access to the network through a network tunnel to the cloud based security system. The multidimensional risk profiling process 1000 includes posture acquisition where the client application collects data (step 1006). Specifically, the client application can collect device information and security telemetry and communicates it to the cloud based security system. The client application listens for security critical events such as Operating System (OS) upgrades, abrupt geolocation changes, device information deviation, and changes in the installed application list and updates the cloud based security system. The cloud based security system evaluates the changes and computes a new risk index for the device. [0136] The multidimensional risk profiling process 1000 includes posture fingerprinting where the cloud based security system creates a mobile device fingerprint (step 1008). Specifically, the cloud based security system creates a device fingerprint and a risk index for the mobile device based on the nature of applications installed on the system, operating system vulnerabilities, anti-virus status, patch level, device configuration, and the like. The multidimensional risk profiling process 1000 includes threat data management where the cloud based security system collects information related to threats (step 1010). The cloud based security system has a data enriching feed mechanism which collects information on all available threats at regular intervals. Based on the threat information, the cloud based security system performs a threat analysis of the mobile device at regular intervals and updates the associated risk index.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Zerrad and Bansal before him or her, to modify the scheme of Zerrad by including Bansal. The suggestion/motivation for doing so would have been to send the collected information by a unified application or identity broker to an identity provider or cloud-based security system for risk appraisal using the collected data such that the access to the resource is contingent upon the risk assessment associated with the user device requesting access, as briefly discussed in the Bansal para. [0136]-[0140].
As to claim 10, in view of claim 1, Zerrad does not explicitly teach but Bansal teaches wherein the instructions arc executable by the processor further configured to cause the apparatus to: transmit, to the identity provider system, an indication of the authentication event; receive, from the identity provider system and based on the indication of the authentication event, an indication of which of the device posture signals to provide to the identity provider system; and provide, to the identity provider system, the indicated device posture signals (see para. [0135]-[0136] “[0135] The multidimensional risk profiling process 1000 includes posture acquisition where the client application collects data (step 1006). Specifically, the client application can collect device information and security telemetry and communicates it to the cloud based security system. The client application listens for security critical events such as Operating System (OS) upgrades, abrupt geolocation changes, device information deviation, and changes in the installed application list and updates the cloud based security system. The cloud based security system evaluates the changes and computes a new risk index for the device. [0136] The multidimensional risk profiling process 1000 includes posture fingerprinting where the cloud based security system creates a mobile device fingerprint (step 1008). Specifically, the cloud based security system creates a device fingerprint and a risk index for the mobile device based on the nature of applications installed on the system, operating system vulnerabilities, anti-virus status, patch level, device configuration, and the like. The multidimensional risk profiling process 1000 includes threat data management where the cloud based security system collects information related to threats (step 1010). The cloud based security system has a data enriching feed mechanism which collects information on all available threats at regular intervals. Based on the threat information, the cloud based security system performs a threat analysis of the mobile device at regular intervals and updates the associated risk index.”; see also para. [0137] “The multidimensional risk profiling process 1000 includes multidimensional risk appraisal where access to network resources is through the cloud based security system as a function of risk (step 1012). That is, the access to any resource on the network is a function of the risk of temporal credentials that are generated by the cloud based security system for that particular resource at that time. The temporal credentials embody risk information of the user requesting the access, the mobile device and the application which are being used to access the resource, and the nature of resource itself. For example, a banking website has higher associated risk and must be denied from a high-risk application.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Zerrad and Bansal before him or her, to modify the scheme of Zerrad by including Bansal. The suggestion/motivation for doing so would have been to send the collected information by a unified application or identity broker to an identity provider or cloud-based security system for risk appraisal using the collected data such that the access to the resource is contingent upon the risk assessment associated with the user device requesting access, as briefly discussed in the Bansal para. [0136]-[0140].
As to claim 19, in view of claim 17, Zerrad does not explicitly teach but Bansal teaches wherein the instructions are executable by the processor further configured to cause the apparatus to:
determine, based on the one or more device posture signals satisfying a security
threshold, to use multi-factor authentication (MFA) for authentication of the user, to require a request for user consent for authentication of the user, to require additional authentication factors for authentication of the user, to lower an authorization level granted to the user for a requested resource, or any combination thereof (see para. [0138] “[0138] The multidimensional risk profiling process 1000 includes adaptive access control where access to sensitive resources is limited based on risk (step 1014). For example, for access to sensitive resources such as corporate applications, a high-risk user will be challenged with a multi-factor authentication scheme as configured by the enterprise. Also, based on the enterprise policy, the network can be quarantined to limit access to certain applications only. The multidimensional risk profiling process 1000 includes dynamic risk enrichment where risk scores for the mobile devices are updated based on activity (step 1016). Based on the network usage, the risk score of the user is updated with each network access. For example, access to malware or phishing sites, increases the risk index of the user. The client application listens for security critical events such as OS upgrades, abrupt geolocation changes, device information deviation, and changes in the installed application list and updates the cloud security system. The cloud based security system evaluates the changes and computes a new updated risk index for the mobile device.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Zerrad and Bansal before him or her, to modify the scheme of Zerrad by including Bansal. The suggestion/motivation for doing so would have been to send the collected information by a unified application or identity broker to an identity provider or cloud-based security system for risk appraisal using the collected data such that the access to the resource is contingent upon the risk assessment associated with the user device requesting access, as briefly discussed in the Bansal para. [0136]-[0140].
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zerrad, in view of Kaegi (US 8,839,233 B2).
As to claim 8, in view of 1, Zerrad does not explicitly teach but Kaegi teaches “wherein the instructions are executable by the processor further configured to cause the apparatus to: identify, based on signal configuration metadata, the one or more authentication plug-ins and additional parameters for using the one or more authentication plug-ins” (see col. 6, lines 9-20, “In certain embodiments, the metadata in the plugin registry 500 may contain information needed to identify each installed plugin 208 (such as a Universal Resource Locator (URL) for each installed plugin 208). The metadata may also include data needed to provide an entry point into the client-side component 204 for each installed plugin 208 (i.e., inform the client-side component 204 of the capabilities provided by each installed plugin application 208). The metadata may also include information indicating how to load the functional capabilities of the installed plugins 208 into the client-side component 204 when the capabilities of the plugins 208 are needed.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Zerrad and Kaegi before him or her, to modify the scheme of Zerrad by including Kaegi. The suggestion/motivation for doing so would have been to discovering and installing web application plug-in using metadata describing a plugin’s capabilities and metadata describing an API to access the plugin’s capabilities via cross-document messaging.
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zerrad, in view of Kaegi, and further in view of Tripp et al. (US 2022/0038449 A1) hereinafter Tripp.
As to claim 9, in view of claim 8, Zerrad teaches wherein the signal configuration metadata indicates one or more signal types to be collected (see para. [0137]).
The combination of Zerrad and Kaegi does not explicitly teach but Tripp teaches, wherein the one or more authentication plug-ins are identified based on the one or more signal types, and wherein different signal types are associated with different authentication plug-ins (see para. [0062] “the IAM APIs 250 support multiple levels of service integration, for example, including direct integration, brokered integration, and authentication level enforcement integration with the unified IAM control plane. Direct integration may involve the use of an “authorized” API, for example, in which services directly check whether or not a specific subject is authorized to perform an action. Brokered integration may involve the use of an “Effective change event API,” which may allow third party services to subscribe to change events and react. Authentication level enforcement may involve the use of “IAM App Management APIs,” which may include: (i) an “app-assignment-rules” API, in which one may describe conditions in which a user/group should be assigned to a third party app so the user/group may be authenticated; and (ii) a “claim-injection-rules” API through which one may describe conditions that will result in dynamically injecting claims into the authentication response (e.g., SAML or Oauth claims). In one embodiment, by coupling authentication level enforcement with brokered change event, both sides of normally disconnected services may be fully dynamically configured.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Zerrad, Kaegi and Tripp before him or her, to modify the scheme of Zerrad and Kaegi by including Tripp. The suggestion/motivation for doing so would have been to link each API for a specific task such as correspondence of authorization API with checking authorization policies across various services.
Claim(s) 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zerrad, in view of Jain et al. (US 2020/0162454 A1) hereinafter Jain.
As to claim 14, in view of claim 12, Zerrad does not explicitly teach but Jain teaches wherein the third-party signal provider system provides an identity provider system with one-time passwords via short message service (SMS) messages (see para. [0091]-[0100] “[0099] At step 630, OTP plugin 437 may get user One Time Password (OTP) credentials or proof of access to a multi-factor authentication device. For example, OTP plugin 437 may cause a text message to be sent to a registered SMS number of the user's mobile device, or may receive as input a time-based one time password code from an authentication device of the user. OTP plugin 437 may, at step 632, request to authenticate the user device with OTP server 447. OTP server 447 may be a federated identity provider, and may be associated with the enterprise hosting authentication system 520 and/or a third party network. The request may be to obtain a third authentication token, an OTP authentication token. The request may comprise the gathered user credentials, e.g., the one time password. If the OTP server 447 is configured to confirm multi-factor authentication in another manner, such as having an authentication device of the user send a message directly to OTP server 447, the request may not require credentials, but may include information identifying the request and the user device to be authenticated. At step 634, OTP server 447 may authenticate the user based on the credentials in the request and/or OTP/multi-factor authentication information corresponding to the request using known techniques. For example, OTP server may send an SMS message to a mobile phone associated with the user, and the user may enter a one time code into a page provided by OTP server 447 and/or authentication system 520. If the user successfully authenticates, OTP server 447 may respond to the OTP plugin 437 with an OTP authentication token at step 636. For example, as a result of the user successfully logging into the virtual, cloud-based enterprise system using OTP authentication, OTP server 447 may issue the OTP authentication token. Although step 630 illustrates the OTP plugin 437 acquiring user credentials, in some implementations OTP server 447 may operate to prompt the user for credentials. [0100] At step 638, OTP plugin 437 may optionally convert the received OTP authentication token to a standard and/or specialized format associated with authentication system 520. The standard form OTP authentication token (or original OTP authentication token) may be returned to authentication interface 525 at step 640. At step 642, authentication interface 525 may return the OTP authentication token to AD+OTP plugin 535, thereby completing the request by AD+OTP plugin 535 (as a relying party) to authenticate the user device using the OTP authentication process.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Zerrad, and Jain before him or her, to modify the scheme of Zerrad by including Jain. The suggestion/motivation for doing so would have been to allow an IdP to perform a multi-factor authentication of user including SMS based OTP to check user really possess the device the user is using for access to a resource.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HEE SONG whose telephone number is (571)270-3260. The examiner can normally be reached on Mon – Fri, 7:30 AM – 5:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Eleni Shiferaw can be reached on (571)272-3867. The fax phone number for the organization where this application or proceeding is assigned is 571-273-7291.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HEE K SONG/Primary Examiner, Art Unit 2497