DETAILED ACTION
This office action has been issued in response to communications received on 6/25/2026. Claims 1-2, 6-9 and 11-20 are amended. No new claims are cancelled and no claims were cancelled. Claims 1-20 are presented for examination. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s amendments to claims 17-20 correcting their claim dependency is sufficient to overcome the objection to the aforementioned claims. Therefore, the objections from the Non-Final Rejection are withdrawn.
Applicant’s remarks regarding the rejection of Claims 1, 11 and 16 as rejected on the ground of non-statutory double patenting as being unpatentable over claims 1, 7 and 13 of Patent No. 10,404,476; claims 1, 11 and 21 of Patent No. 10,985,925; Claims 1, 10, 15 and 18 of Patent No. 11,711,222 and claims 1, 14 and 18 of Patent No. 12,010,248 have been considered but were found unpersuasive. The newly added amendment “wherein the application is executed on an executing device, the executing device being distinct from the challenge device;” is not anticipated by the other patents, however it would have been obvious to one of ordinary skill in the art to add the method disclosed in Rosati (US 2013/0046976) of sending by the authentication server to a mobile device a challenge as part of authenticating a VPN client 20 on the computing device, wherein the VPN client 20 is executing on the computing device which is physically separate from the mobile device (paras. [0027]-[0028], Fig. 1) to the functionality of the patents in order to increase the security of the system by requiring the user to successfully pass two-factor authentication by demonstrating that they possess an additional second user device (mobile device) previously registered as the user device which can correctly respond to the user challenge before permitting their first original user device (i.e. the laptop) from being authorized to access a resource. Therefore the double patent rejection is sustained in view of the patents in combination with Rosati.
Applicant’s amendments to claims 1, 11 and 16 clarifying how each step flows into the next step and are linked together as a whole are sufficient to overcome the rejection of the aforementioned claims under 35 USC 112, second paragraph. Accordingly, the rejection of claims 1, 11 and 16 under 112, second paragraph, are withdrawn.
Applicants amendments to claims 8, 15 and 20 clarifying what the level of trust comprises is sufficient to overcome the rejection of the aforementioned claims under 112, second paragraph. Accordingly, the rejection of claims 8, 15 and 20 under 112, second paragraph, is withdrawn.
Applicant’s Remarks with respect to the rejection of the claims under 35 USC 103 have been considered, but are found unpersuasive.
Applicant’s arguments filed 6/25/2026, with respect to the rejection of claims 1-20 under 35 USC § 103(a) have been fully considered but are moot because newly added claim limitations requiring “sending, by the server computer system to a device, a challenge to a challenge device as part of authentication of the application, wherein the application is executed on an executing device, the executing device being distinct from the challenge device” require new grounds of rejection necessitated by amendments.
The remaining arguments fail to comply with 37 C.F.R. 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references.
Consequently, the rejection of the claims under 35 U.S.C. 103 is sustained.
OBJECTIONS
Claims 1, 11 and 16 are objected to for the following informalities: it is unclear what is meant by the “usage context comprising at least one of …the executing device”? Does this mean that the executing device itself is usage context or anything regarding the executing device is usage context? This seems to be missing further details. Appropriate clarification/correction is required.
Double Patenting
The non-statutory 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 non-statutory 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, 11 and 16 are rejected on the ground of non-statutory double patenting as being unpatentable over claims 1, 7 and 13 of Patent No. 10,404,476; claims 1, 11 and 21 of Patent No. 10,985,925; Claims 1, 10, 15 and 18 of Patent No. 11,711,222 and claims 1, 14 and 18 of Patent No. 12,010,248 in view of Rosati (US 2013/0046976). Although the claims at issue are not identical, they are not patentably distinct from each other because all the claims of the current independent claims are anticipated by the independent claims of the parent claims, which were narrower in scope than the current set of claims under examination herein.
The newly added amendment “wherein the application is executed on an executing device, the executing device being distinct from the challenge device;” is not anticipated by the other patents, however it would have been obvious to one of ordinary skill in the art to add the method disclosed in Rosati (US 2013/0046976) of sending by the authentication server to a mobile device a challenge as part of authenticating a VPN client 20 on the computing device, wherein the VPN client 20 is executing on the computing device which is physically separate from the mobile device (paras. [0027]-[0028], Fig. 1) to the functionality of the patents in order to increase the security of the system by requiring the user to successfully pass two-factor authentication by demonstrating that they possess an additional second user device (mobile device) previously registered as the user device which can correctly respond to the user challenge before permitting their first original user device (i.e. the laptop) from being authorized to access a resource.
Current Application
16/235,509 (10,404,476)
16/518,557 (10,985,925)
A method ofby a server computer system, comprising:
sending, by the server computer systemto a challenge device as part of authentication of the application, wherein the application is executed on an executing device, the executing device being distinct from the challenge device;
receiving, by the server computer systemfrom the challenge device;
verifying, by the server computer system, the response is correct based on the challenge;
subsequent to verifying the response is correct, analyzing, by the server computer system, a usage context associated with the application, the usage context comprising at least one of a location at which the application will be executed, a role of a user of the application, a permission associated with a user of the application, the executing device
based on the analysis of the usage context, selecting, by the server computer systemthe [[an]] organization, wherein the level of trust comprises at least one of: a permission level of the application, a user permission level of a user of the application, an operation permission level associated with a first privilege available to the application for performing an operation, and an access permission level that establishes a second privilege to a resource accessible to the application;
generating, by the server computer system, authentication information having the selected level of trust for the application;
and transmitting, by the server computer systemto the executing device, wherein the authentication information establishesto interact
A method for a certificate authority system providing authentication to a plurality of devices associated with an organization, the method comprising:
receiving, at the certificate authority system, a request from a device to sign authentication information of the device, wherein the device is associated with the organization and is a virtual device provisioned at a cloud services provider for the organization;
sending a challenge to the device to perform an action with a system other than the certificate authority system, wherein the action causes the device to obtain a response to the challenge as a result of performing the action;
receiving the response to the challenge from the device;
verifying, by the certificate authority system, the response was generated correctly based on the challenge;
verifying, by the certificate authority system in response to verification of the response, at least one additional trustworthiness requirement associated with the device by verifying, with the cloud services provider, that one or more trusted configuration parameters were used to initialize the virtual device;
analyzing one or more factors corresponding to the device, the one or more factors comprising a location of the device, a role of a user of the device within the organization, one or more permissions associated with the user of the device, one or more privileges of the user within the organization, a type of the device, a purpose of the device, or a combination thereof;
selecting a key of the certificate authority system associated with a level of trust based on the analysis of the one or more factors; and
signing, in response to the verification of the response and verification of the at least one additional trustworthiness requirement, the authentication information of the device with one or more keys of the certificate authority system as an authentication of an identity of the device, wherein the one or more keys includes the key selected by the certificate authority system and signing the authentication information of the device with the selected key certifies the device as a trusted device having the level of trust when interacting with one more other devices within the organization.
A method for a certificate authority system providing authentication to a plurality of devices associated with an organization, the method comprising:
receiving, at the certificate authority system, a request from a device to sign authentication information of the device, wherein the device is associated with the organization and is a physical device having a trusted platform module;
sending a challenge to the device to perform an action with a cloud services provider system, wherein the cloud services provider generates a response to the challenge as a result of performing the action at the request of the device;
receiving the response to the challenge from the device;
verifying, by the certificate authority system, the response was generated correctly based on the challenge;
verifying, by the certificate authority system in response to verification of the response, at least one additional trustworthiness requirement associated with the device by obtaining, by the certification authority system from the trusted platform module, an attestation that one or more device configuration parameters are consistent with predetermined trusted device configuration parameters;
analyzing one or more factors corresponding to the device, the one or more factors comprising a location of the device, a role of a user of the device within the organization, one or more permissions associated with a user of the device, one or more privileges of the user within the organization, a type of the device, a purpose of the device, or a combination thereof;
selecting a key of the certificate authority system associated with a level of trust based on the analysis of the one or more factors; and
signing, in response to the verification of the response and verification of the at least one additional trustworthiness requirement, the authentication information of the device with one or more keys of the certificate authority system as an authentication of an identity of the device, wherein the one or more keys includes the key selected by the certificate authority system and signing the authentication information of the device with the selected key certifies the device as a trusted device having the level of trust when interacting with one or more other devices within the organization.
Current Application
17/234,456 (11,711,222)
18/216,992 (12,010,248)
A method ofby a server computer system, comprising:
sending, by the server computer systemto a challenge device as part of authentication of the application, wherein the application is executed on an executing device, the executing device being distinct from the challenge device;
receiving, by the server computer systemfrom the challenge device;
verifying, by the server computer system, the response is correct based on the challenge;
subsequent to verifying the response is correct, analyzing, by the server computer system, a usage context associated with the application, the usage context comprising at least one of a location at which the application will be executed, a role of a user of the application, a permission associated with a user of the application, the executing device
based on the analysis of the usage context, selecting, by the server computer systemthe [[an]] organization, wherein the level of trust comprises at least one of: a permission level of the application, a user permission level of a user of the application, an operation permission level associated with a first privilege available to the application for performing an operation, and an access permission level that establishes a second privilege to a resource accessible to the application;
generating, by the server computer system, authentication information having the selected level of trust for the application;
and transmitting, by the server computer systemto the executing device, wherein the authentication information establishesto interact
A method for a certificate authority system providing authentication to a plurality of devices associated with an organization, the method comprising:
receiving, at the certificate authority system, a request from a device to sign authentication information of the device, wherein the device is associated with the organization;
sending a challenge to the device comprising a request for a certificate signed by a manufacturer of the device;
receiving a response to the challenge from the device comprising a certificate purported to be signed by the manufacturer of the device;
verifying, by the certificate authority system with a system of the manufacturer of the device, that the certificate purported to be signed by the manufacturer of the device is a valid manufacturer certificate;
analyzing one or more factors associated with the device, the one or more factors comprising a location of the device, a role of a user of the device within the organization, one or more permissions associated with a user of the device, one or more privileges of the user within the organization, a type of device, a purpose of the device, or a combination thereof;
selecting a key of the certificate authority system associated with a level of trust based on the analysis of the one or more factors; and
signing, in response to the verification that the certificate purported to be signed by the manufacturer of the device is the certificate signed by the manufacturer of the device, the authentication information of the device with one or more keys of the certificate authority system as a certificate authority system authentication of an identity of the device, wherein the one or more keys includes the key selected by the certificate authority system and signing the authentication information of the device with the selected key certifies the device as a trusted device having the level of trust when interacting with one or more other devices associated with the organization.
A method for a certificate authority system providing authentication to a device associated with an organization, the method comprising:
receiving, at the certificate authority system, a request from the device to sign authentication information of the device;
sending a challenge to the device comprising a request to perform an action;
receiving a response to the challenge from the device as a result of performing the action;
verifying, by the certificate authority system, the response was correctly generated based on the challenge;
analyzing a factor associated with the device, the factor comprising at least one of a location of the device, a role of a user of the device within the organization, one or more permissions associated with a user of the device, one or more privileges of the user within the organization, a type of device, and a purpose of the device;
selecting, based on the analysis of the factor, a key from among a plurality of keys of the certificate authority system associated with a level of trust associated with the device wherein the level of trust encompasses at least one of: a device permission level of the device within the organization, a user permission level of a user of the device, an operation permission level associated with a privilege available to the device for performing an operation within the organization, and an access permission level that establishes a privilege to a resource; and
signing, in response to verifying the response and selecting the key, the authentication information of the device with at least the selected key of the certificate authority system as a certificate authority system authentication of an identity of the device that certifies the device as a trusted device having the level of trust when interacting with another device associated with the organization.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Mahaffey (US 2014/0189808) in view of Unnikrishnan (US 2016/0094531) and Rosati (US 2013/0046976).
Regarding claim 1, Mahaffey discloses the limitations of claim 1 substantially as follows:
A method by a server computer system, comprising:
sending, by the server computer system to a challenge device (paras. [0041], [0047], [0057], [0059]-[0060], [0063], [0082], [0137], Figs. 1, 3A: sending by a server to a client device a challenge as part of authenticating a “website, mobile or desktop application, or other service needing authentication”);
receiving, by the server computer system from the challenge device (paras. [0041], [0057], [0059]-[0060], [0063], [0082], Figs. 1, 3A: system 100 comprising servers receives a response to the challenge from the client device);
verifying, by the server computer system, the response is correct based on the challenge (paras. [0041], [0047], [0057], [0059]-[0060], [0063], [0082], Figs. 1, 3A: verifying by the system whether the response to the challenge contains the proper credentials);
subsequent to verifying the response is correct, analyzing, by the server computer system, a usage context associated with the application, the usage context comprising at least one of a location at which the application will be executed, a role of a user of the application, a permission associated with a user of the application, the executing device (paras. [0041], [0046], [0060], [0072], [0074]-[0076], [0078], [0104], [0137]: analyzing by the servers of the system additional context to verify type of identity/role of the client requesting the application identified in the application identity information, where the client has different identities for work, shared team identity, public, private (i.e. role of a user), in addition to verifying the location of the device executing the application, type of device and the level of access of a user account of a user of the application (i.e. role/permission of the user));
based on the analysis of the usage content, selecting, by the server computer system the [[an]] organization, wherein the level of trust comprises at least one of: a permission level of the application, a user permission level of a user of the application, an operation permission level associated with a first privilege available to the application for performing an operation, and an access permission level that establishes a second privilege to a resource accessible to the application (paras. [0065]-[0066], [0078], [0172]-[0173], [0104], [0155]: generating by the servers of the system a token and/or user-defined images for use in an organization/enterprise, based on analyzing the context information such as location and level of access, where the token indicates the level of access of a user of the application for performing an action and the token can be used to access additional resources in conjunction with the application (i.e. second privilege to a resource accessible to the application));
generating, by the server computer system, authentication information having the selected level of trust for the application (paras. [0065], [0155]: generating by servers of the system an authorization (i.e. authentication information) including the token granting access); and
transmitting, by the server computer system to the executing device (paras. [0065], [0078], [0155]: sending the token or user-defined image as part of the authentication information to the user device indicating the level of access the user will obtain).
Mahaffey does not explicitly disclose the remaining limitations of claim 1 as follows:
by a server computer system;
sending, by the server computer system to a challenge device as part of authentication of the application, wherein the application is executed on an executing device, the executing device being distinct from the challenge device;
wherein the authentication information establishes to interact
However, in the same field of endeavor Unnikrishnan discloses the limitations of claim 1 as follows:
by a server computer system (paras. [0015], [0018], [0020], [0029]: authentication component comprising server performs “authentication of clients and client services (e.g., applications)”);
sending, by the server computer system to a device, a challenge as part of authentication of the application (paras. [0015], [0017], [0020], [0029]-[0030]: authentication component comprising server uses challenges to authenticate client components such as client services/applications);
wherein the authentication information establishes to interact (paras. [0015], [0017], [0020]-[0021], [0029]-[0030]: issuing the validation result comprising a security authorization (i.e. authentication information) to the client establishing the client application/services as trusted to communicate with the server to obtain the requested resources).
Unnikrishnan is combinable with Mahaffey because both are from the same field of endeavor of using the OAuth protocol and challenge-response exchanges to securely exchange key information for authenticating a user device’s request for access to resources. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to integrate Unnikrishnan’s method of using a challenge-response protocol to authenticate an application with the system of Mahaffey in order to increase the security of the system by ensuring that the application a user is using is authenticated in addition to the user and the user device to prevent falsified applications from stealing user data.
Neither Mahafffey or Unnikrishnan teaches the remaining limitations of claim 1 as follows:
wherein the application is executed on an executing device, the executing device being distinct from the challenge device;
However, in the same field of endeavor, Rosati teaches the remaining limitations of claim 1 as follows:
authenticating an application associated with an organization by a server computer system (paras. [0024], [0027]-[0028]: authenticating a VPN client 20 associated with an enterprise network by an authentication server);
sending, by the server computer system to a challenge device as part of authentication of the application, wherein the application is executed on an executing device, the executing device being distinct from the challenge device (paras. [0027]-[0028], [0030]-[0031], Figs. 1-2: sending by the authentication server to a mobile device a challenge as part of authenticating a VPN client 20 on the computing device, wherein the VPN client 20 is executing on the computing device which is physically separate from the mobile device);
Rosati is combinable with Mahaffey and Unnikrishnan because all are from the same field of endeavor of using challenge-response exchanges to securely exchange key information for authenticating a user device’s request for access to resources. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to integrate Rosati’s method of using a separate challenge device to receive and generate a challenge response from the device executing the application with the system of Mahaffey and Unnikrishnan in order to increase the security of the system by requiring the user to successfully pass two-factor authentication by demonstrating that they possess an additional second user device (mobile device) previously registered as the user device which can correctly respond to the user challenge before permitting their first original user device (i.e. the laptop) from being authorized to access a resource.
Regarding claims 2, 12 and 17, Mahaffey, Unnikrishnan and Rosati teach the limitations of the method of claim 1, the non-transitory computer readable storage medium of claim 11 and the server computer system of claim 16.
Mahaffey teaches the limitations of claims 2, 12 and 17 as follows:
wherein selecting the level of trust associated with the organization
selecting, based on the analysis of the usage context, a unique code from among a plurality of unique identifiers of the server computer system associated with the level of trust (paras. [0065], [0078], [0155]: servers of the system generate, based on analysis of the context information, authentication information (i.e. select what key information to include in the authentication information) comprising a secret token or user-defined image from among a plurality of token types or user-defined images (unique to user, unique to message, digitally signed data bundle as plurality of unique identifiers of the server) which grant a level of access to the receiving user (i.e. are associated with a level of trust)) (see also Unnikrishnan paras. [0071], [0092]: selecting, based on criteria included in the challenge, authentication credentials uniquely identifying an issuer of the authentication credential (i.e. a unique code of multiple codes identifying the server); and
adding, by the server computer system to the authentication information to establish the application as the trusted application having the level of trust (paras. [0065], [0078], [0155]: sending the token or user-defined image as part of the authentication information to the user device).
Regarding claim 3, Mahaffey, Unnikrishnan and Rosati teach the limitations of the method of claims 1-2.
Mahaffey teaches the limitations of claim 3 as follows:
The method of claim 2, wherein the unique code comprises a key selected from among a plurality of keys of the server computer system (paras. [0065], [0078], [0155]: servers of the system generate, based on analysis of the context information, authentication information comprising a secret token/key or user-defined image from among a plurality of token types or user-defined images (unique to user, unique to message, digitally signed data bundle as plurality of unique identifiers).
Regarding claim 4, Mahaffey, Unnikrishnan and Rosati teach the limitations of the method of claims 1-2.
Mahaffey teaches the limitations of claim 4 as follows:
The method of claim 2, further comprising: compartmentalizing, by the server computer system, the selected unique code and its associated trust level by at least one of: a geographic region, a user role, a set of user privileges, a device type, or a device purpose (paras. [0065], [0072], [0074]-[0076], [0078], [0163]: generating and storing tokens granting requested level of access based on location, a user role/identity and access level associated with the client identity and a device type).
Regarding claim 5, Mahaffey, Unnikrishnan and Rosati teach the limitations of the method of claim 1.
Mahaffey teaches the limitations of claim 5 as follows:
The method of claim 1, wherein the application comprises a virtual resource associated with the organization (paras. [0178], [0184]: applications may be virtual) (see also Unnikrishnan, paras. [0017], [0078]: client components comprise virtual machine for applications).
Regarding claims 6, 13 and 18, Mahaffey, Unnikrishnan and Rosati teach the limitations of the method of claim 1, the non-transitory computer readable storage medium of claim 11 and the server computer system of claim 16.
Mahaffey teaches the limitations of claims 6, 13 and 18 as follows:
wherein the usage context comprises a geographical location associated with where the application will be used by the user, further wherein (paras. [0072], [0076], [0078]: context information includes location of device on which the application will be used by the user where the level access granted to the application is specific to a location).
Regarding claims 7, 14 and 19, Mahaffey, Unnikrishnan and Rosati teach the limitations of the method of claim 1, the non-transitory computer readable storage medium of claim 11 and the server computer system of claim 16.
Mahaffey teaches the limitations of claims 7, 14 and 19 as follows:
wherein the usage context comprises a user role within the organization, further wherein [[and]] one or more privileges are specific to the user role (paras. [0046], [0075], [0078], [0163], [0165]: context information includes different identities for a user for work, shared team identity, public, private and authorization levels for a user based on the user identity).
Regarding claims 8, 15 and 20, Mahaffey, Unnikrishnan and Rosati teach the limitations of the method of claim 1, the non-transitory computer readable storage medium of claim 11 and the server computer system of claim 16.
Mahaffey teaches the limitations of claims 8, 15 and 20 as follows:
wherein the level of trust comprises the operation permission level associated with the first privilege or the access permission level of the second privilege (paras. [0065]-[0066], [0078], [0172]-[0173], [0104], [0155]: generating by the servers of the system a token and/or user-defined images for use in an organization/enterprise, based on analyzing the context information such as location and level of access, where the token indicates the level of access of a user of the application for performing an action and the token can be used to access additional resources in conjunction with the application (i.e. second privilege to a resource accessible to the application)); and
wherein the first or second privilege is a limited privilege, and a limit of the limited privilege comprises at least one of a time limit or a geography limit (paras. [0072], [0078], [0090], [0136]: level of authorization includes time limits and geographic location).
Regarding claim 9, Mahaffey, Unnikrishnan and Rosati teach the limitations of the method of claim 1.
Mahaffey teaches the limitations of claim 9 as follows:
The method of claim 1, wherein the usage context associated with the application is comprised in at least one of a hardware component or a software component of the [[a]] executing device (paras. [0063], [0082], [0135]: context information includes hardware identifiers of the device executing the application).
Regarding claim 10, Mahaffey, Unnikrishnan and Rosati teach the limitations of the method of claim 1.
Mahaffey teaches the limitations of claim 10 follows:
The method of claim 1, further comprising: revoking the authentication information causing the application to be no longer the trusted application having the level of trust (paras. [0106]-[0108], [0142]: revoking access and rotating passwords so that applications can no longer use the old password to access services after they have been changed/rotated).
Regarding claim 11, Mahaffey teaches the limitations substantially as follows:
A non-transitory computer readable storage medium including instructions that, when executed by a processor, cause the processor to perform operations for a server computer system, the operations comprising:
sending, by the server computer system to a challenge device (paras. [0041], [0047], [0057], [0059]-[0060], [0063], [0082], [0137], Figs. 1, 3A: sending by a server to a client device a challenge as part of authenticating a “website, mobile or desktop application, or other service needing authentication”);
receiving, by the server computer system from the challenge device (paras. [0041], [0057], [0059]-[0060], [0063], [0082], Figs. 1, 3A: system 100 comprising servers receives a response to the challenge from the client device);
verifying, by the server computer system, the response is correct based on the challenge (paras. [0041], [0047], [0057], [0059]-[0060], [0063], [0082], Figs. 1, 3A: verifying by the system whether the response to the challenge contains the proper credentials);
subsequent to verifying the response is correct, analyzing, by the server computer system, a usage context associated with the application, the usage context comprising at least one of a location at which the application will be executed, a role of a user of the application, a permission associated with a user of the application, the executing device (paras. [0041], [0046], [0060], [0072], [0074]-[0076], [0078], [0104], [0137]: analyzing by the servers of the system additional context to verify type of identity/role of the client requesting the application identified in the application identity information, where the client has different identities for work, shared team identity, public, private (i.e. role of a user), in addition to verifying the location of the device executing the application, type of device and the level of access of a user account of a user of the application (i.e. role/permission of the user));
based on the analysis of the usage content, selecting, by the server computer system the [[an]] organization, wherein the level of trust comprises at least one of: a permission level of the application, a user permission level of a user of the application, an operation permission level associated with a first privilege available to the application for performing an operation, and an access permission level that establishes a second privilege to a resource accessible to the application (paras. [0065]-[0066], [0078], [0172]-[0173], [0104], [0155]: generating by the servers of the system a token and/or user-defined images for use in an organization/enterprise, based on analyzing the context information such as location and level of access, where the token indicates the level of access of a user of the application for performing an action and the token can be used to access additional resources in conjunction with the application (i.e. second privilege to a resource accessible to the application));
generating, by the server computer system, authentication information having the selected level of trust for the application (paras. [0065], [0155]: generating by servers of the system an authorization (i.e. authentication information) including the token granting access); and
transmitting, by the server computer system to the executing device (paras. [0065], [0078], [0155]: sending the token or user-defined image as part of the authentication information to the user device indicating the level of access the user will obtain).
Mahaffey does not explicitly disclose the remaining limitations of claim 11 as follows:
by a server computer system;
sending, by the server computer system to a challenge device as part of authentication of the application, wherein the application is executed on an executing device, the executing device being distinct from the challenge device;
wherein the authentication information establishes to interact
However, in the same field of endeavor Unnikrishnan discloses the remaining limitations of claim 11 as follows:
by a server computer system (paras. [0015], [0018], [0020], [0029]: authentication component comprising server performs “authentication of clients and client services (e.g., applications)”);
sending, by the server computer system to a device, a challenge as part of authentication of the application (paras. [0015], [0017], [0020], [0029]-[0030]: authentication component comprising server uses challenges to authenticate client components such as client services/applications);
wherein the authentication information establishes to interact (paras. [0015], [0017], [0020]-[0021], [0029]-[0030]: issuing the validation result comprising a security authorization (i.e. authentication information) to the client establishing the client application/services as trusted to communicate with the server to obtain the requested resources).
Unnikrishnan is combinable with Mahaffey because both are from the same field of endeavor of using the OAuth protocol and challenge-response exchanges to securely exchange key information for authenticating a user device’s request for access to resources. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to integrate Unnikrishnan’s method of using a challenge-response protocol to authenticate an application with the system of Mahaffey in order to increase the security of the system by ensuring that the application a user is using is authenticated in addition to the user and the user device to prevent falsified applications from stealing user data.
Neither Mahafffey or Unnikrishnan teaches the remaining limitations of claim 11 as follows:
wherein the application is executed on an executing device, the executing device being distinct from the challenge device;
However, in the same field of endeavor, Rosati teaches the remaining limitations of claim 11 as follows:
authenticating an application associated with an organization by a server computer system (paras. [0024], [0027]-[0028]: authenticating a VPN client 20 associated with an enterprise network by an authentication server);
sending, by the server computer system to a challenge device as part of authentication of the application, wherein the application is executed on an executing device, the executing device being distinct from the challenge device (paras. [0027]-[0028], [0030]-[0031], Figs. 1-2: sending by the authentication server to a mobile device a challenge as part of authenticating a VPN client 20 on the computing device, wherein the VPN client 20 is executing on the computing device which is physically separate from the mobile device);
Rosati is combinable with Mahaffey and Unnikrishnan because all are from the same field of endeavor of using challenge-response exchanges to securely exchange key information for authenticating a user device’s request for access to resources. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to integrate Rosati’s method of using a separate challenge device to receive and generate a challenge response from the device executing the application with the system of Mahaffey and Unnikrishnan in order to increase the security of the system by requiring the user to successfully pass two-factor authentication by demonstrating that they possess an additional second user device (mobile device) previously registered as the user device which can correctly respond to the user challenge before permitting their first original user device (i.e. the laptop) from being authorized to access a resource.
Regarding claim 16, Mahaffey teaches the limitations substantially as follows:
A server computer system, comprising:
a memory; and
a processor coupled with the memory, the processor configured to:
send to a challenge device (paras. [0041], [0047], [0057], [0059]-[0060], [0063], [0082], [0137], Figs. 1, 3A: sending by a server to a client device a challenge as part of authenticating a “website, mobile or desktop application, or other service needing authentication”);
receive from the challenge device (paras. [0041], [0057], [0059]-[0060], [0063], [0082], Figs. 1, 3A: system 100 comprising servers receives a response to the challenge from the client device);
verify the response is correct based on the challenge (paras. [0041], [0047], [0057], [0059]-[0060], [0063], [0082], Figs. 1, 3A: verifying by the system whether the response to the challenge contains the proper credentials);
subsequent to verifying the response is correct, analyze a usage context associated with the application, the usage context comprising at least one of a location at which the application will be executed, a role of a user of the application, a permission associated with a user of the application, the executing device (paras. [0041], [0046], [0060], [0072], [0074]-[0076], [0078], [0104], [0137]: analyzing by the servers of the system additional context to verify type of identity/role of the client requesting the application identified in the application identity information, where the client has different identities for work, shared team identity, public, private (i.e. role of a user), in addition to verifying the location of the device executing the application, type of device and the level of access of a user account of a user of the application (i.e. role/permission of the user));
based on the analysis of the usage content, select the [[an]] organization, wherein the level of trust comprises at least one of: a permission level of the application, a user permission level of a user of the application, an operation permission level associated with a first privilege available to the application for performing an operation, and an access permission level that establishes a second privilege to a resource accessible to the application (paras. [0065]-[0066], [0078], [0172]-[0173], [0104], [0155]: generating by the servers of the system a token and/or user-defined images for use in an organization/enterprise, based on analyzing the context information such as location and level of access, where the token indicates the level of access of a user of the application for performing an action and the token can be used to access additional resources in conjunction with the application (i.e. second privilege to a resource accessible to the application));
generate authentication information having the selected level of trust for the application (paras. [0065], [0155]: generating by servers of the system an authorization (i.e. authentication information) including the token granting access); and
transmit to the executing device (paras. [0065], [0078], [0155]: sending the token or user-defined image as part of the authentication information to the user device indicating the level of access the user will obtain).
Mahaffey does not explicitly disclose the remaining limitations of claim 16 as follows:
send to a challenge device as part of authentication of the application associated with an organization, wherein the application is executed on an executing device, the executing device being distinct from the challenge device;
wherein the authentication information establishes to interact
However, in the same field of endeavor Unnikrishnan discloses the remaining limitations of claim 16 as follows:
send to a challenge device as part of authentication of the application associated with an organization (paras. [0015], [0017], [0020], [0029]-[0030]: authentication component comprising server uses challenges to authenticate client components such as client services/applications);
wherein the authentication information establishes to interact (paras. [0015], [0017], [0020]-[0021], [0029]-[0030]: issuing the validation result comprising a security authorization (i.e. authentication information) to the client establishing the client application/services as trusted to communicate with the server to obtain the requested resources).
Unnikrishnan is combinable with Mahaffey because both are from the same field of endeavor of using the OAuth protocol and challenge-response exchanges to securely exchange key information for authenticating a user device’s request for access to resources. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to integrate Unnikrishnan’s method of using a challenge-response protocol to authenticate an application with the system of Mahaffey in order to increase the security of the system by ensuring that the application a user is using is authenticated in addition to the user and the user device to prevent falsified applications from stealing user data.
Neither Mahafffey or Unnikrishnan teaches the remaining limitations of claim 16 as follows:
wherein the application is executed on an executing device, the executing device being distinct from the challenge device;
However, in the same field of endeavor, Rosati teaches the remaining limitations of claim 16 as follows:
authenticating an application associated with an organization by a server computer system (paras. [0024], [0027]-[0028]: authenticating a VPN client 20 associated with an enterprise network by an authentication server);
sending, by the server computer system to a challenge device as part of authentication of the application, wherein the application is executed on an executing device, the executing device being distinct from the challenge device (paras. [0027]-[0028], [0030]-[0031], Figs. 1-2: sending by the authentication server to a mobile device a challenge as part of authenticating a VPN client 20 on the computing device, wherein the VPN client 20 is executing on the computing device which is physically separate from the mobile device);
Rosati is combinable with Mahaffey and Unnikrishnan because all are from the same field of endeavor of using challenge-response exchanges to securely exchange key information for authenticating a user device’s request for access to resources. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to integrate Rosati’s method of using a separate challenge device to receive and generate a challenge response from the device executing the application with the system of Mahaffey and Unnikrishnan in order to increase the security of the system by requiring the user to successfully pass two-factor authentication by demonstrating that they possess an additional second user device (mobile device) previously registered as the user device which can correctly respond to the user challenge before permitting their first original user device (i.e. the laptop) from being authorized to access a resource.
Prior art not relied upon but applied/considered includes:
1) Forster (US 2011/0162046) disclosing selecting role contexts, receiving a challenge based upon the selected role context and selecting credentials based upon the selected role context (Fig. 4, paras. [0031], [0038].
Conclusion
For the above reasons, claims 1-20 are rejected.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHARON S LYNCH whose telephone number is (571)272-4583. The examiner can normally be reached on 10AM-6PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Taghi T Arani can be reached on 571-272-3787. 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.
/SHARON S LYNCH/Primary Examiner, Art Unit 2438
Prosecution Insights