Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This is in reply to papers filed on 3/10/2025. Claims 1-20 are pending. Claims 1, 11, and 19 is/are independent.
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.
U.S. Patent No. 11,483,355
Claims 1-2, 4-7, 11-12, 14-16, and 19 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claim 2 of U.S. Patent No. 11,483,355 in view of Rykowski et al. U.S. Publication 20160381006 (hereinafter “Rykowski”). Although the claims at issue are not identical, they are not patentably distinct from each other because the combination of the claims of U.S. Patent No. 11,483,355 and the teachings of the Rykowski reference render obvious the claims of the present application. Claim 2 of U.S. Patent No. 11,483,355 contain most elements of claim 1 of the instant application, except the features of
wherein a received certificate is determined to be valid when it matches a previously stored certificate for the device;
Rykowski at para 45 describes certificate validation fails if the received certificate varies from the certificate initially provided to the client device. It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method recited in claim 2 of U.S. Patent No. 11,483,355 to include
wherein a received certificate is determined to be valid when it matches a previously stored certificate for the device, as taught by Rykowski, in order to improve the ability of the system to determine the certificates are matching as a condition for proper validation of the certificate. Instant claim 11 recites limitations analogous to limitations of claim 1 and is also rejected based on claim 11 of U.S. Patent No. 11,483,355 for similar reasons.
Instant claim 19 recites limitations analogous to limitations of claim 1 and is also rejected based on claim 21 of U.S. Patent No. 11,483,355 for similar reasons.
As for dependent claims 2 and 4-6, claim 2 of U.S. Patent No. 11,483,355 discloses the limitations of dependent claims 2 and 4-6.
As for dependent claims 12 and 14-15, claim 11 of U.S. Patent No. 11,483,355 discloses the limitations of dependent claims 12 and 14-15.
As for dependent claims 7 and 16, the claims of U.S. Patent No. 11,483,355 do not disclose the limitations of dependent claims 7 and 16. Rykowski at para. 45-46 discloses the limitations of dependent claims 7 and 16. It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method recited in claim 2 or claim 11 of U.S. Patent No. 11,483,355 to include the features disclosed in Rykowski para. 45-46 for the same reasons as the independent claim.
U.S. Patent No. 12,452,312
Claims 1-2, 4-7, 11-12, 14-16, and 19 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claim 1 of U.S. Patent No. 12,452,312 in view of Rykowski et al. U.S. Publication 20160381006 (hereinafter “Rykowski”). Although the claims at issue are not identical, they are not patentably distinct from each other because the combination of the claims of U.S. Patent No. 12,452,312 and the teachings of the Rykowski reference render obvious the claims of the present application. Claim 1 of U.S. Patent No. 12,452,312 contain most elements of claim 1 of the instant application, except the features of
wherein a received certificate is determined to be valid when it matches a previously stored certificate for the device;
Rykowski at para 45 describes certificate validation fails if the received certificate varies from the certificate initially provided to the client device. It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method recited in claim 1 of U.S. Patent No. 12,452,312 to include
wherein a received certificate is determined to be valid when it matches a previously stored certificate for the device, as taught by Rykowski, in order to improve the ability of the system to determine the certificates are matching as a condition for proper validation of the certificate. Instant claim 11 recites limitations analogous to limitations of claim 1 and is also rejected based on claim 11 of U.S. Patent No. 12,452,312 for similar reasons.
Instant claim 19 recites limitations analogous to limitations of claim 1 and is also rejected based on claim 19 of U.S. Patent No. 12,452,312 for similar reasons.
As for dependent claims 2 and 4-6, claim 1 of U.S. Patent No. 12,452,312 discloses the limitations of dependent claims 2 and 4-6.
As for dependent claims 12 and 14-15, claim 11 of U.S. Patent No. 12,452,312 discloses the limitations of dependent claims 12 and 14-15.
As for dependent claims 7 and 16, the claims of U.S. Patent No. 12,452,312 do not disclose the limitations of dependent claims 7 and 16. Rykowski at para. 45-46 discloses the limitations of dependent claims 7 and 16. It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the method recited in claim 1 or claim 11 of U.S. Patent No. 12,452,312 to include the features disclosed in Rykowski para. 45-46 for the same reasons as the independent claim.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 is/are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claim 1 recites “whether the device is a managed device or not a managed device”. However, claim 1 already recites determining whether the device is a managed device. It is not clear whether the subsequent limitation is referring to the same managed device or some other different managed device. Claims 11 and 19 recite limitations analogous to limitations of claim 1 and are rejected for the same reasons as claim 1.
The dependent claims inherit the limitations of their respective independent claims and are rejected for the same reasons as their respective independent claim.
Appropriate correction is required.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-7, 11-16, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Rykowski et al. U.S. Publication 20160381006 (hereinafter “Rykowski”) in view of Bendersky et al. U.S. Publication 20200380109 (hereinafter “Bendersky”).
As per claim 1, Rykowski discloses
A method [flowchart figure 3]of implementing a security policy, comprising:
[security policy disclosed by the following from para 45, which determines whether device requesting access has authorization: If the identity certificate 138 fails validation, then the process proceeds to completion, as the managed application 147 is not authorized to access the requested resource.
]
receiving a request [the management service 112 can receive a request for content from the installation of the managed application 147] from a device [figure 1, client device 106] to access a service, an application, or a website;
Rykowski [0044] At step 303, the management service 112 can initiate installation of an application as a managed application 147 on the client device 106. The management service 112 can issue a command directing the operating system 143 or the management component 145 to obtain and install the application as a managed application 147 on the client device 106. At step 305, the management service 112 can receive a request for content from the installation of the managed application 147. In some examples, the request for content can be made to third party services. In this scenario, the management service 112 can facilitate providing an authentication key on behalf of a third party service to the installation of the managed application 147 on the client device 106 in response to the third party service transmitting an authentication request to the installation of the managed application 147. The request can include a connect command according to the Kerberos protocol. The request can also include any other type of connection request for a resource from the managed application 147.
sending a certificate request to the device as part of a protocol handshake;
[management service 112 can transmit an authentication request to the managed application 147 in response to receiving the request for content from the managed application 147.
protocol handshake disclosed by the process of receiving the request for content and sending authentication request
]
determining whether the device is a managed device [determine the validity of certificate upon receiving such certificate discloses determining whether the device is a managed device, para 45] based on whether a valid certificate has been received from the device, [“can receive an identity certificate 138 from the client device 106. At step 310, the management service 112 can validate the identity certificate 138 received from the managed application 147”, para 45] wherein a received certificate is determined to be valid when it matches [certificate validation fails if the received certificate varies from the certificate initially provided to the client device, para 45] a previously stored certificate [verify the identity of a client device 106 by confirming that a certificate provided by the client device 106 matches the identity certificate 138 stored in the user data 133] for the device;
[0045] At step 307, the management service 112 can transmit an authentication request to the managed application 147 in response to receiving the request for content from the managed application 147. As noted above, the authentication request can include a HTTP response with status code 401 indicating that the managed application 147 is unauthorized. At step 309, the management service 112 can receive an identity certificate 138 from the client device 106. At step 310, the management service 112 can validate the identity certificate 138 received from the managed application 147. If the identity certificate 138 fails validation, then the process proceeds to completion, as the managed application 147 is not authorized to access the requested resource. The identity certificate 138 can fail validation if the certificate is improperly signed, unsigned, identifies an incorrect user, or contains any other defect that causes the identity certificate 138 to vary from the identity certificate 138 initially provided by the management service 112 to the client device 106 in step 301.
[0030] In the context of this disclosure, a device profile 149 installed on the client device 106 at the direction of the management service 112 can include an identity certificate 138 that is generated or obtained by the management service 112 on behalf of a user account that is associated with the client device 106. Accordingly, upon enrollment of the client device 106 with the management service 112, the management service 112 can transmit a device profile 149 that includes the identity certificate 138 for installation on the client device 106. Because the management service 112 can generate or obtain an identity certificate 138 that is associated with a user account, the management service 112 can also verify the identity of a client device 106 by confirming that a certificate provided by the client device 106 matches the identity certificate 138 stored in the user data 133. The device profile 149 containing the identity certificate 138 can be transmitted to the client device 106 over a secure communication link, such as a secure sockets layer (SSL) connection over the network 118.
Rykowski [0018] The data stored in the data store 121 includes, for example, user data 133. … User data 133 can include information with which a user account can be authenticated, such as user credentials, a username/password pair, or an encrypted form of any type of authentication credentials.
determining a security policy [“If the identity certificate 138 fails validation, then the process proceeds to completion, as the managed application 147 is not authorized to access the requested resource”, para 45; security policy can be disclosed by any rules or procedures for determining whether to grant access, such as here where the security policy is the managed application is not authorized to access the requested resource if the certificate validation fails; receiving and successfully validating or failing to validate the certificate determines whether a device is a managed device or not] for the request from the device based on [in Rykowski if the device certificate is validated it’s a managed device and then determining that the security policy is to allow access, and if the device certificate is not validated successfully then it is not a managed device and then determining that the security policy is to not allow access] whether the device is a managed device [determine the validity of certificate upon receiving such certificate discloses determining whether the device is a managed device, para 45] or not a managed device; and
Rykowski [0046]
If the identity certificate 138 is validated by the management service 112, the process proceeds to FIG. 3B. At step 311 in FIG. 3B, in response to the identity certificate 138 being validated, the management service 112 transmits an authentication key 142 to the installation of the managed application 147 on the client device 106. At step 313, the management service 112 can receive an authentication key 142 from the managed application 147. At step 315, the management service 112 can determine whether the authentication key 142 corresponds to the authentication key 142 that was provided by the management service 112 to the client device 106. In other words, the management service 112 can validate that the installation of the application requesting content through the management service 112 is the same installation to which the authentication key 142 was provided. If the authentication key 142 is validated, then at step 319, the management service 112 can grant access to the requested resource to the managed application 147. If the authentication key 142 is not validated, then at step 317, the management service 112 can refuse access to the requested resource to the installation of the managed application 147.
sending information [ “in response to the identity certificate 138 being validated, the management service 112 transmits an authentication key 142”, para 46; authentication key is sent only when the identity certificate is properly validated, therefore the authentication key discloses information about the determined security policy ] about the determined security policy to the device, wherein the information directs the device [the authentication key is provided to the client device by the management service 112 so that the client device can subsequently submit the authentication key back to the management service 112, and therefore the management service 112 discloses a destination that implements the determined security policy; that implements the determined security policy is disclosed by management service 112 because management service 112 allows access or refuses access based on successful validation of the certificate (para 45, 46)] to a destination that implements the determined security policy.
Rykowski [0046] If the identity certificate 138 is validated by the management service 112, the process proceeds to FIG. 3B. At step 311 in FIG. 3B, in response to the identity certificate 138 being validated, the management service 112 transmits an authentication key 142 to the installation of the managed application 147 on the client device 106. At step 313, the management service 112 can receive an authentication key 142 from the managed application 147. At step 315, the management service 112 can determine whether the authentication key 142 corresponds to the authentication key 142 that was provided by the management service 112 to the client device 106. In other words, the management service 112 can validate that the installation of the application requesting content through the management service 112 is the same installation to which the authentication key 142 was provided. If the authentication key 142 is validated, then at step 319, the management service 112 can grant access to the requested resource to the managed application 147. If the authentication key 142 is not validated, then at step 317, the management service 112 can refuse access to the requested resource to the installation of the managed application 147.
However, Rykowski does not expressly disclose
generating a unique identifier for the request based on an identifier for the service, application, or website;
Bendersky discloses
generating a unique identifier [obtain and make available to an auxiliary device (e.g., mobile phone, tablet, etc.) of the identity a unique session identifier, para 71] for the request based on [under the broadest reasonable interpretation, based on an identifier can mean the identifier was involved in the process of generating the unique identifier; “The identity may request access to an endpoint resource”, para 71; the Rykowski unique session identifier is generated based on the endpoint resource identification because the request for access identifies the endpoint resource as the recipient of the request and therefore the unique session identifier of the reference is generated based on the identifier of the endpoint resource; see below for 2 alternate disclosures that the limitations read on;] an identifier [the Rykowski request for access identifies the endpoint resource for network routing purposes; GUID, UUID, random number, para 104; identity provider provisions an identity, para. 80] for the service, [endpoint resource, para 71] application, or website;
[alternatively, the Bendersky identity provider provisions an identity (para. 80) and that identity is supplied in response to the request and would disclose generating a unique identifier for the request based on an identifier for the service
alternatively, Bendersky para 104 describes “the unique session identifier may be various types of unique character strings, such as a GUID, UUID, random number”. Anyone of GUID, UUID, random number may disclose an identifier for the service
]
[0008] The operations may comprise identifying a request for an identity to access an endpoint computing resource, the endpoint computing resource having an authentication requirement for access by the identity, wherein the request does not include authentication credentials for the identity;
Bendersky [0071] According to the techniques described below, an identity may be authenticated and automatically provisioned with an appropriate level of access rights without being required to supply a password or other credential. The identity may request access to an endpoint resource, where the request does not include authentication credentials. The endpoint may then obtain and make available to an auxiliary device (e.g., mobile phone, tablet, etc.) of the identity a unique session identifier. … The auxiliary device may then transmit the unique session identifier and identifying data to either the endpoint or an intermediary resource, in response to which the particular identity can be verified and an appropriate level of access rights to the endpoint can be determined.
Para 80 in some situations identity provider 105 provisions an identity for use in the session.
[0086] Auxiliary device 101 and endpoint resource 102 may also have various applications 206/214, which may be stored in memories 202/209 and executed by processors 201/208. … applications 214 may include an endpoint application or agent configured to generate or receive unique session identifiers, make available encoded machine-readable codes to auxiliary device 101, receive identity data, and authenticate a requesting identity associated with auxiliary device 101.
Bendersky [0088] As shown in FIG. 2B, endpoint resource 102 may also include a session identifier generator 211. As discussed further below, session identifier generator 211 may be an application or agent configured to generate unique session identifiers for purposes of authenticating identities associated with auxiliary devices 101. For example, session identifier generator 211 may be configured to generate a globally unique identifier (GUID), universally unique identifier (UUID), random string of numbers and/or letters, or other types of unique data elements. As discussed below, this unique session identifier may be made available to auxiliary device 101 through an encoded machine-readable code or transmitted in plaintext to auxiliary device 101. While FIG. 2B illustrates session identifier generator 211 as being a component of endpoint resource 102, in other embodiments, session identifier generator 211 is a component of intermediary resource 104. In that case, intermediary resource 104 may be configured to provide the generated unique session identifier to endpoint resource 102, which in turn may make the session identifier available to auxiliary device 101 for reading and/or decoding.
[0104] Operations 502 and 503 illustrate different techniques for obtaining a unique session identifier in response to the request. Consistent with FIG. 3B above, operation 502 may include accessing a unique session identifier (e.g., locally stored at endpoint resource 102 or retrieved from intermediary resource 104), and operation 503 may include generating the unique session identifier. As discussed above, the unique session identifier may be various types of unique character strings, such as a GUID, UUID, random number, etc. The unique session identifier may or may not have an expiration or time-to-live attribute. For example, in some situations unique session identifiers are used by the endpoint for only one authentication of a particular identity. After that single use, the unique session identifier may be deleted or disabled for future use.
example, identity provider may supply an identity or credentials based on SAML techniques, OpenID techniques, or other identity provisioning techniques.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Rykowski with the technique for generating a unique identifier for the request based on identification of the service requested of Bendersky to include
generating a unique identifier for the request based on an identifier for the service, application, or website;
One of ordinary skill in the art would have made this modification to improve the ability of the system to generate a session identifier for the user so that the user may engage in a session with the resource that the user seeks to assess. The system of the primary reference can be modified to generate a unique session identifier for the user to facilitate user access to a resource.
As per claim 2, the rejection of claim 1 is incorporated herein.
However, Rykowski does not expressly disclose
wherein the unique identifier is also based on one or more of a user account name, a device identifier, a date or time of the request, a type of network connection used to make the request, and a location of the device.
Bendersky discloses wherein the unique identifier is also based on one or more of a user account name, a device identifier, a date or time of the request, a type of network connection used to make the request, and a location of the device.
[0092] As illustrated in FIG. 3B and system 300B, once endpoint resource 102 receives or detects the request 301 for access, endpoint resource 102 may obtain a unique session identifier. This may involve, for example, locally generating the unique session identifier at endpoint resource 102 (e.g., using session ID generator 211 of FIG. 2B) or requesting the unique session identifier from intermediary resource 104. As discussed above, the unique session identifier may be a UUID, GUID, or random alphanumeric, numerical, or alphabetical string of characters, or other types of unique identifiers. In some embodiments, the unique session identifier is both unique and short-lived. For example, the unique session identifier may have a time-to-live parameter, expiration parameter, one-time-use or one-session-use attribute, or other limitations on its period of viability. As an illustration, if the unique session identifier is specified by endpoint resource 102 to have a period of viability of 60 seconds, the authentication process described below (including auxiliary device 101 returning the unique session identifier to endpoint resource 102) may need to be completed in 60 seconds, or else the authentication may fail.
[ universally unique identifier (UUID) and globally unique identifier (GUID) are used to identify information in computer systems. because the UUID, GUID, are unique they identify devices; and a location of the device is also disclosed because the component generating the session identifier is aware that the device requesting access is somewhere connected to a computer network at the time of the request ]
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Rykowski with the technique for generating a unique session identifier based on a UUID or GUID and/or the knowledge that the device requesting access is somewhere that has access to the network at the time of the request of Bendersky to include
wherein the unique identifier is also based on one or more of a user account name, a device identifier, a date or time of the request, a type of network connection used to make the request, and a location of the device.
One of ordinary skill in the art would have made this modification to improve the ability of the system to generate a unique session identifier for the user so that the user may engage in a session with the resource that the user seeks to access. The system of the primary reference can be modified to generate a unique session identifier based on a UUID or GUID and/or the knowledge that the device requesting access is somewhere that has access to and is communicable via the network to facilitate user access to a resource.
As per claim 3, the rejection of claim 1 is incorporated herein.
However, Rykowski does not expressly disclose
wherein determining the security policy for the request from the device further comprises determining that the security policy is one or more of requiring multi-factor authentication to access specific websites, applications, or data sources, allowing, blocking or disallowing specific websites, restricting functionality of webpages or applications, and limiting access to company networks or systems from certain locations or over certain types of networks if the device is a managed device.
Bendersky discloses determining the security policy requires multifactor authentication to access the data source
[0004] Two-factor authentication can offer enhanced security over traditional username-and-password security. By requiring, for example, a password and a biometric verification, some added security may be achieved. Similarly, requiring a user to present a password and a value from a portable fob (e.g., RSA SecurID™, etc.) can add protection over basic username-and-password security. Nevertheless, two-factor authentication also has drawbacks. For example, techniques such as these are unable to concurrently authenticate an identity and the identity's physical presence proximate to an endpoint resource they are attempting to access. In addition, many two-factor authentication techniques are cumbersome or inefficient, which can lead some users to implement workarounds or other insecure approaches to dealing with secure resources. Further, these techniques are unable to dynamically couple an identity to a secure session, such as by provisioning relevant authentication or authorization credentials, or by obtaining an identity from an identity provider.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Rykowski with the technique for determining the security policy requires multifactor authentication to access the data source of Bendersky to include
wherein determining the security policy for the request from the device further comprises determining that the security policy is one or more of requiring multi-factor authentication to access specific websites, applications, or data sources, allowing, blocking or disallowing specific websites, restricting functionality of webpages or applications, and limiting access to company networks or systems from certain locations or over certain types of networks if the device is a managed device.
One of ordinary skill in the art would have made this modification to improve the ability of the system to provide enhanced multifactor authentication security, which would decrease the likelihood of malicious 3rd parties gaining unauthorized access. The system of the primary reference can be modified to determine that a security policy requires multifactor authentication to access a data source.
As per claim 4, the rejection of claim 1 is incorporated herein.
Rykowski discloses wherein the previously stored certificate is for use with a plurality of devices.
[a plurality of devices disclosed by the client device 106 in figure 1 and the server that is in the computing environment 109 that sends the certificate to the client device 106, such a server being described, for example, at para 12.
the Rykowski server is providing the certificate to the client device and the client device sends it back later and therefore discloses previously stored certificate is for use with a plurality of devices.
]
As per claim 5, the rejection of claim 1 is incorporated herein.
Rykowski discloses wherein the information [ the authentication key discloses information about the determined security policy ] about the determined security policy is included in a token or a message.
[ “in response to the identity certificate 138 being validated, the management service 112 transmits an authentication key 142”, para 46; authentication key is sent only when the identity certificate is properly validated]
As per claim 6, the rejection of claim 1 is incorporated herein.
Rykowski discloses
wherein the security policy [security policy can be disclosed by any rules or procedures for determining whether to grant access, such as here where the security policy is the managed application is not authorized to access the requested resource if the certificate validation fails; ] is determined by one or more rules, [ one or more rules disclosed by “in response to the identity certificate 138 being validated, the management service 112 transmits an authentication key 142”, para 46; authentication key is sent only when the identity certificate is properly validated] where each of the one or more rules includes one or more factors [one or more factors disclosed by whether identity certificate is successfully validated, which will determine if the security policy is applied, the security policy is: the managed application is not authorized to access the requested resource if the certificate validation fails] that determine if the security policy is applied.
[“If the identity certificate 138 fails validation, then the process proceeds to completion, as the managed application 147 is not authorized to access the requested resource”, para 45; security policy can be disclosed by any rules or procedures for determining whether to grant access;]
As per claim 7, the rejection of claim 6 is incorporated herein.
Rykowski discloses wherein the security policy [security policy can be disclosed by any rules or procedures for determining whether to grant access, such as here where the security policy is the managed application is not authorized to access the requested resource if the certificate validation fails; ] applied to the device is determined by a first rule [ first rule disclosed by “in response to the identity certificate 138 being validated, the management service 112 transmits an authentication key 142”, para 46; authentication key is sent only when the identity certificate is properly validated; claim 7 depends from claim 6 and claim 6 requires only a minimum of one rule ] to which a status of the device as managed [determine the validity of certificate upon receiving such certificate discloses determining whether the device is a managed device, para 45] or not managed satisfies the one or more factors.[ one or more factors disclosed by whether identity certificate is successfully validated, which will determine if the security policy is applied, the security policy is: the managed application is not authorized to access the requested resource if the certificate validation fails]
As per claim 11, the claim(s) is/are directed to a system with limitations which correspond to limitations of claim 1, and is/are rejected for the reasons detailed with respect to claim 11. Claim 11 also recites
A system [an instruction execution system] to implement a security policy, comprising:
one or more electronic processors configured to execute a set of instructions; and
a non-transitory computer-readable media including the set of instructions, wherein when executed the instructions cause the one or more processors to
[0052] Also, one or more or more of the components described herein that include software or program instructions can be embodied in any non-transitory computer-readable medium for use by or in connection with an instruction execution system such as, a processor in a computer system or other system. The computer-readable medium can contain, store, and/or maintain the software or program instructions for use by or in connection with the instruction execution system.
Rykowski [0047] The sequence diagram and flowchart of FIGS. 2A-2B and 3A-3B show examples of the functionality and operation of implementations of components described herein. The components described herein can be embodied in hardware, software, or a combination of hardware and software. If embodied in software, each element can represent a module of code or a portion of code that includes program instructions to implement the specified logical function(s). The program instructions can be embodied in the form of, for example, source code that includes human-readable statements written in a programming language or machine code that includes machine instructions recognizable by a suitable execution system, such as a processor in a computer system or other system. If embodied in hardware, each element can represent a circuit or a number of interconnected circuits that implement the specified logical function(s).
[security policy disclosed by the following from para 45, which determines whether device requesting access has authorization: If the identity certificate 138 fails validation, then the process proceeds to completion, as the managed application 147 is not authorized to access the requested resource.]
As per claim 12, the claim(s) is/are directed to a system with limitations which correspond to limitations of claim 2, and is/are rejected for the reasons detailed with respect to claim 2.
As per claim 13, the claim(s) is/are directed to a system with limitations which correspond to limitations of claim 3, and is/are rejected for the reasons detailed with respect to claim 3.
As per claim 14, the claim(s) is/are directed to a system with limitations which correspond to limitations of claim 4, and is/are rejected for the reasons detailed with respect to claim 4.
As per claim 15, the claim(s) is/are directed to a system with limitations which correspond to limitations of claim 6, and is/are rejected for the reasons detailed with respect to claim 6.
As per claim 16, the claim(s) is/are directed to a system with limitations which correspond to limitations of claim 7, and is/are rejected for the reasons detailed with respect to claim 7.
As per claim 19, the claim(s) is/are directed to a system with limitations which correspond to limitations of claim 1, and is/are rejected for the reasons detailed with respect to claim 11. Claim 19 also recites, and Rykowski discloses,
A set of one or more non-transitory computer-readable media including a set of computer-executable instructions that when executed by one or more programmed electronic processors, cause the processors to:
Rykowski 0052] Also, one or more or more of the components described herein that include software or program instructions can be embodied in any non-transitory computer-readable medium for use by or in connection with an instruction execution system such as, a processor in a computer system or other system. The computer-readable medium can contain, store, and/or maintain the software or program instructions for use by or in connection with the instruction execution system.
Rykowski [0047] The sequence diagram and flowchart of FIGS. 2A-2B and 3A-3B show examples of the functionality and operation of implementations of components described herein. The components described herein can be embodied in hardware, software, or a combination of hardware and software. If embodied in software, each element can represent a module of code or a portion of code that includes program instructions to implement the specified logical function(s). The program instructions can be embodied in the form of, for example, source code that includes human-readable statements written in a programming language or machine code that includes machine instructions recognizable by a suitable execution system, such as a processor in a computer system or other system. If embodied in hardware, each element can represent a circuit or a number of interconnected circuits that implement the specified logical function(s).
Claims 8-9, 17-18, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Rykowski in view of Bendersky, further in view of Pernicha et al. U.S. Publication 20160191466 (hereinafter “Pernicha”).
As per claim 8, the rejection of claim 6 is incorporated herein.
Rykowski discloses
and wherein the one or more factors include the status of the device as managed or not managed [determine the validity of certificate upon receiving such certificate discloses determining whether the device is a managed device, para 45] and device [certificate validation is performed based on the device submitting the certificate, per digital 45] or session information.
However, the combination of Rykowski and Bendersky does not expressly disclose
wherein the one or more rules are ranked with regards to whether they are selected for determining the security policy applied to the device
Pernicha discloses ordering policy rules based on past usage frequency and removing unused rules
[0049] For example, rules or objects (e.g., addresses or services) that are unused for a long period of time may be recommended for removal or, for performance reasons, the traffic flows containing the unused object may be automatically reordered to place them on the bottom of the security policy. If the unused rules or objects are removed (rather than reordered), in one embodiment, a new security policy optimization is performed.
Pernicha [0059] According to one embodiment, reordering of policy rules can include changing an order of policy rules based on their respective source IP addresses, destination IP addresses, network usage statistics, applications, interfaces, rule tags, priorities and/or parameters. In an example implementation, the order of policy rules may be changed based on frequency of past usage, a manual priority set according to the business needs and/or other predefined or dynamically determined criteria. For example, a policy rule that is observed to be used the most frequently can be reordered to be executed first. In an example implementation, a dynamic priority can be assigned to each policy rule and the order of execution can therefore be dynamically changed.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Rykowski and Bendersky with the technique for ordering policy rules based on past usage frequency and removing unused rules of Pernicha to include
wherein the one or more rules are ranked with regards to whether they are selected for determining the security policy applied to the device, and wherein the one or more factors include the status of the device as managed or not managed and device or session information.
One of ordinary skill in the art would have made this modification to improve the ability of the system to order the rules so that it can determine which rules are most important for determining a security policy and which rules are not needed. The system of the primary reference can be modified to order rules used to determine a security policy.
As per claim 9, the rejection of claim 6 is incorporated herein.
However, the combination of Rykowski and Bendersky does not expressly disclose
wherein the one or more rules include at least one factor that does not have to be matched exactly to determine the security policy to be applied to the device.
Pernicha discloses utilizing a usage threshold to determine whether a rule should be removed and prioritizing rules according to business needs
[0049] For example, responsive to observing that one or more policies of a rule base have been unused over a configurable or predetermined period of time, a warning may be provided to the network administrator along with one or more suggested changes to be made to the rule base (e.g., removal or editing of such rules). For example, rules or objects (e.g., addresses or services) that are unused for a long period of time may be recommended for removal or, for performance reasons, the traffic flows containing the unused object may be automatically reordered to place them on the bottom of the security policy. If the unused rules or objects are removed (rather than reordered), in one embodiment, a new security policy optimization is performed.
Pernicha [0059] According to one embodiment, reordering of policy rules can include changing an order of policy rules based on their respective source IP addresses, destination IP addresses, network usage statistics, applications, interfaces, rule tags, priorities and/or parameters. In an example implementation, the order of policy rules may be changed based on frequency of past usage, a manual priority set according to the business needs and/or other predefined or dynamically determined criteria. For example, a policy rule that is observed to be used the most frequently can be reordered to be executed first. In an example implementation, a dynamic priority can be assigned to each policy rule and the order of execution can therefore be dynamically changed.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Rykowski and Bendersky with the technique for utilizing a usage threshold to determine whether a rule should be removed and prioritizing rules according to business needs of Pernicha to include
wherein the one or more rules include at least one factor that does not have to be matched exactly to determine the security policy to be applied to the device.
One of ordinary skill in the art would have made this modification to improve the ability of the system to order the rules so that it can determine which rules are most important for determining a security policy and which rules are not needed. The system of the primary reference can be modified to order rules used to determine a security policy. A usage threshold is not an exact match because there is a wide range above the threshold that can invoke application of a rule or removal of a rule. Also prioritizing according to business needs is not an exact match.
As per claim 17, the claim(s) is/are directed to a system with limitations which correspond to limitations of claim 8, and is/are rejected for the reasons detailed with respect to claim 8.
As per claim 18, the claim(s) is/are directed to a system with limitations which correspond to limitations of claim 9, and is/are rejected for the reasons detailed with respect to claim 9.
As per claim 20, the claim(s) is/are directed to a set of one or more non-transitory computer-readable media with limitations which correspond to limitations of claims 6 and 8, and is/are rejected for the reasons detailed with respect to claims 6 and 8.
Claim 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Rykowski in view of Bendersky, further in view of Kavantzas et al. U.S. Publication 20130086652 (hereinafter “Kavantzas”).
As per claim 10, the rejection of claim 1 is incorporated herein.
However, the combination of Rykowski and Bendersky does not expressly disclose
wherein the identifier for the service, the application, or the website is a URL.
Kavantzas discloses that the service resource locator is a URL
[0023] In one embodiment, the service resource locator may comprise a Uniform Resource Locator ("URL") associated with the one or more services. In one embodiment, the web service environment information, the request information, or a combination thereof may comprise a client reference identifier, a service resource locator, and security credentials associated with a user, and the processor may be further configured to combine the client reference identifier, the service resource locator, and the security credentials associated with the user to produce the session identifier.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Rykowski and Bendersky with the teaching that that the service resource locator is a URL of Kavantzas to include wherein the identifier for the service, the application, or the website is a URL.
One of ordinary skill in the art would have made this modification to improve the ability of the system to comply with networking standards so that the service can be identified and located. The system of the primary reference can be modified so that the service is identified by a URL in order to be in compliance with networking standards.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HOWARD H LOUIE whose telephone number is 571-272-0036. The examiner can normally be reached on Monday-Friday 9 AM-5 PM EST.
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, Jung W. Kim can be reached on 571-272-3804. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HOWARD H. LOUIE/Examiner, Art Unit 2494
/THEODORE C PARSONS/Primary Examiner, Art Unit 2494
Prosecution Insights