DETAILED ACTION
This office action has been issued in response to communications received on 5/17/2024. 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 .
Drawings
The drawings filed 5/17/2024 are acknowledged.
Priority
Priority to CON 15/480,057 filed 4/05/2017 is acknowledged.
Objections
Claims 17-20 are objected to for miscellaneous errors. The claims state that they are dependent upon claim 11, but claim 11 is a non-transitory medium claim while these claims are not directed to a server computer system. In addition, there are already a duplicate set of these dependent claims for independent claim 11. Claims 17-20 also claim to be dependent upon the server computer system, but the server computer system is disclosed in independent claim 16. The Examiner recommends that the dependencies of these claims be corrected to claim dependency upon the server computer system of claim 16. 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 nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1, 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. 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.
Current Application
16/235,509 (10,404,476)
16/518,557 (10,985,925)
A method for a server computer system authenticating an application associated with an organization, comprising:
sending, by the server computer system to a device, a challenge as part of authentication of the application;
receiving, by the server computer system from the device, a response to the challenge;
verifying, by the server computer system, the response is correct based on the challenge;
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, a type of device that will execute the application, or a purpose of the application;
selecting, by the server computer system based on the analysis of the usage context, a level of trust associated with 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 server computer system to the device, the authentication information establishing the application as a trusted application having the level of trust when interacting with another device or application associated with 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 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 for a server computer system authenticating an application associated with an organization, comprising:
sending, by the server computer system to a device, a challenge as part of authentication of the application;
receiving, by the server computer system from the device, a response to the challenge;
verifying, by the server computer system, the response is correct based on the challenge;
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, a type of device that will execute the application, or a purpose of the application;
selecting, by the server computer system based on the analysis of the usage context, a level of trust associated with 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 server computer system to the device, the authentication information establishing the application as a trusted application having the level of trust when interacting with another device or application associated with 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;
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 § 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, 8, 11, 15-16 and 20 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 applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1, 11 and 16 are rejected as indefinite because they appear to be missing claim steps. Right now the claims of the instant application currently comprise two parts that are not linked together. The first part comprises sending, receiving and verifying a challenge. The second subsequent part involves analyzing a usage context and generating authentication information having a selected level of trust. It is unclear how these two parts relate to one another. No product or result from the steps involving the challenge are used in the subsequent part of the claim. Appropriate clarification/correction is required.
Claims 8, 15 and 20 are rejected as indefinite because they claim limitations from their parent claim that may never occur. Claims 8, 15 and 20 are dependent each upon a different independent claim, but each independent claim discloses selecting a level of trust, “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. Since the independent claims only require one of the list for the level of trust, the one selected may be the permission level of the application or the user permission level – in which case there would be no first or select privilege. Yet claims 8, 15 and 20 assume both the operation permission level with the first privilege or the access permission level with the second privilege are picked for the level of trust. The Examiner recommends amending claims 8, 15 and 20 to specify “when the level of trust comprises the operation permission level associated with the first privilege or the access permission level that establishes the second privilege” to clarify that these claims refer to the scenario where those levels make up the level of trust. Appropriate clarification/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 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).
Regarding claim 1, Mahaffey discloses the limitations of claim 1 substantially as follows:
A method for a server computer system, comprising:
sending, by the server computer system to a device, a challenge (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 device, a response to the challenge (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);
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, a type of device that will execute the application, or a purpose of the application (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));
selecting, by the server computer system based on the analysis of the usage context, a level of trust associated with 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 server computer system to the device, the authentication information (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:
server computer system authenticating an application associated with an organization;
sending, by the server computer system to a device, a challenge as part of authentication of the application;
the authentication information establishing the application as a trusted application having the level of trust when interacting with another device or application associated with the organization.
However, in the same field of endeavor Unnikrishnan discloses the limitations of claim 1 as follows:
server computer system authenticating an application associated with an organization (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);
the authentication information establishing the application as a trusted application having the level of trust when interacting with another device or application associated with the organization (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.
Regarding claims 2, 12 and 17, Mahaffey and Unnikrishnan 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, further comprises:
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);
adding, by the server computer system to the authentication information, the unique code 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 and Unnikrishnan 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 and Unnikrishnan 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 and Unnikrishnan 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 and Unnikrishnan 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 and the permission level of the application is specific to the geographical location (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 and Unnikrishnan 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 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 and Unnikrishnan 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 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 and Unnikrishnan 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 a device executing the application (paras. [0063], [0082], [0135]: context information includes hardware identifiers of the device executing the application).
Regarding claim 10, Mahaffey and Unnikrishnan 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 device, a challenge (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 device, a response to the challenge (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);
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, a type of device that will execute the application, or a purpose of the application (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));
selecting, by the server computer system based on the analysis of the usage context, a level of trust associated with 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 server computer system to the device, the authentication information (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:
a server computer system authenticating an application associated with an organization
sending, by the server computer system to a device, a challenge as part of authentication of the application;
the authentication information establishing the application as a trusted application having the level of trust when interacting with another device or application associated with the organization.
However, in the same field of endeavor Unnikrishnan discloses the remaining limitations of claim 11 as follows:
a server computer system authenticating an application associated with an organization(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);
the authentication information establishing the application as a trusted application having the level of trust when interacting with another device or application associated with the organization (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.
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 device, a challenge (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 device, a response to the challenge(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);
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, a type of device that will execute the application, or a purpose of the application (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));
select, based on the analysis of the usage context, a level of trust associated with 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 device, the authentication information (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 device, a challenge as part of authentication of an application associated with an organization;
authentication information establishing the application as a trusted application having the level of trust when interacting with another device or application associated with the organization.
However, in the same field of endeavor Unnikrishnan discloses the remaining limitations of claim 16 as follows:
send, to a device, a challenge as part of authentication of an 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);
authentication information establishing the application as a trusted application having the level of trust when interacting with another device or application associated with the organization (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.
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.
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