DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . In communications filed on 04/13/2026. Claims 1, 4-5, 7, 13, and 15 are amended. Claims 16-20, and 25 are cancelled. Claim 26 newly added. Claims 1-15, and 21-26 are pending in this examination.
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. This examination is in response to US Patent Application No. 19/012,068.
Examiner Note
Claim 15 recites “computer-readable storage medium”. The computer-readable storage medium has been described in Paragraph 87 of specification as: refer to physical hardware media such as the hard disk associated with hard disk drive 714, removable magnetic disk 718, removable optical disk722, other physical hardware media such as RAMs, ROMs, flash memory cards, digital video disks, zip disks, MEMs, nanotechnology-based storage devices, and further types of physical/tangible hardware storage media.
Applicant is encouraged to review the relevant references mentioned at the conclusion section of this office action.
Specification
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed. The independent or dependent claims are not directed to a “MITIGATION OF RANSOMWARE IN INTEGRATED, ISOLATED APPLICATIONS”.
Response to Argument
Applicant’s amendment to claims 1, and 4-5 obviates previously raised claims 1-6 , 35 U.S.C .112(b) , second paragraph , and claim interpretation.
Applicant’s arguments with respect to independent claims for newly added limitation have been considered but are moot because the arguments do not apply to any of the references being used in the current rejection.
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.
Claims 1-15, 21-24, and 26 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. US2019/0103968 issued to Sirnivasan, and in view of US Patent No. (US2012/0054847) issued to Schultz.
Regarding claim 1, Srinivasan discloses a system for providing an authorization token with a trust indication, the system comprising: one or more processors; and one or more memory devices that store program code configured to be executed by the one or more processors, the program code comprising[ see FIG. 1 and corresponding text for more details], and [¶25, The present disclosure relates to access management techniques. More particularly, an infrastructure is provided that enables a client requester to acquire a properly scoped access token (equated to trust indication) issued by a token issuer authority in a secure manner. The client requestor may be a non-confidential client or public client, i.e., an application that is not capable of storing or keeping a secret. For example, a public or non-confidential client is an application that is not capable of keeping a client password confidential. Various inventive embodiments are described herein, including methods, systems, non-transitory computer-readable storage media storing programs, code, or instructions executable by one or more processors, and the like]; and
an identity validator that performs operation comprising: in response to validation, by the identity validator, of the identity information; validating the identity information to determine whether to permit the application to obtain the authorization token to [¶14, in certain embodiments, prior to transmitting the second request to the token issuer system, the token relay system may perform processing including validating the anti-CSRF information/token, and verifying that the client is allowed to request a token for the scope identified in the first request] , and [¶32, A token request received by the token relay system(equated to identity validator ) from a client requestor may include various pieces of information that are used by the token relay system to request a properly scoped token on behalf of the client requestor. For example, in certain embodiments, the token request received by the token relay system from the client requestor (e.g., JavaScript application) may include context information for the token request. This context information may include, for example, information identifying a scope for which the token is being requested, single sign-on (SSO) information for a session during which the token request is generated, client identifier information, information identifying the client's origin, etc.], and [¶34, The token relay system may also use the information received from the client in the token request to ensure that the requested token is of the proper scope for the requesting client. As indicated above, the information received from the client requestor may include information identifying a scope for the access token The token relay system may check the requested scope for the access token and then request an access token from the token issuer authority that is properly scoped corresponding to the scope information identified in the token request received from the client], and [see FIG.2, [¶66,Token relay system 102 identifies the requesting client based upon the client ID included in the request received in 206. Token relay system 102 then verifies that the client associated with that client ID is allowed to request the specified scopes as identified in the scoped information (requires token relay specific provisioning) in the request received in 206. In some embodiments, token relay system 102 is configured with information identifying clients and, for each client, the allowable scope(s) for the client. Token relay system 102 may use this preconfigured information to verify if the scope requested in the request received in 206 is appropriate or valid or allowed for that client], and [see FIGS.1 and 2, ¶69, at 212, token issuer authority 110 (or IDCS 114) verifies if the scopes requested in the token request received in 210 are allowed for token relay system 102], and [¶93, As described above, the token relay system may serve multiple applications, each one with access granted to potentially different audiences/scopes. In certain embodiments, token relay system 102 provides a way for a user (e.g., an administrator) to register client applications that it trusts and to set the audiences/scopes that each application is entitled to. This enables token relay system 102 to, when an access token request comes in from a particular client, to check the access token scope requested by that request with the scope registered for that client application. If the scope requested by the client application is outside the scope registered for that client, then that access token request may not be further processed. In this manner, a client is prevented from requesting an access token of a scope that is not appropriate for that client]; and
receiving, from an authorization token manager of a host computing environment of a computing device a token request that includes identity information of an entity requesting an authorization token [ Abstract, A token relay system is provided that enables a client requester to acquire a properly scoped access token issued by a token issuer authority in a secure manner. The client requestor may be a non-confidential client (e.g., a JavaScript application). The token relay system is a trusted and confidential client of the token issuer authority. Upon receiving an access token request from a client, the token relay system is configured to send a request to the token issuer authority (e.g., OAuth server) requesting an access token on behalf of the requestor. The token issuer authority may then respond by issuing an access token with the appropriate scope to the token relay system], and[¶30, In certain embodiments, the token relay system (or a component of the token relay system that requests access tokens from the token issue authority) is a trusted and confidential client of the token signature authority (e.g., an OAuth server), and is trusted by the token issuer authority to assert a user identity on behalf of a user requesting an access token], and ¶32, A token request received by the token relay system(equated to identity validator ) from a client requestor may include various pieces of information that are used by the token relay system to request a properly scoped token on behalf of the client requestor. For example, in certain embodiments, the token request received by the token relay system from the client requestor (e.g., JavaScript application) may include context information for the token request. This context information may include, for example, information identifying a scope for which the token is being requested, single sign-on (SSO) information for a session during which the token request is generated, client identifier information, information identifying the client's origin, etc.], and [see FIG.2, ¶66, Token relay system 102 identifies the requesting client based upon the client ID included in the request received in 206…]; and, and [see FIG.s, ¶68, upon successfully passing all the checks/verifications/validations, token relay system 102 creates a client assertion that is communicated to token issuer authority 110 in 210], and [see FIGS.1 and 2, ¶69, at 212, token issuer authority 110 (or IDCS 114) verifies if the scopes requested in the token request received in 210 are allowed for token relay system 102], and [¶¶10, 34, 62]; and
and an indication that the token request was initiated by an application executing in a virtual computing environment of the computing device at least partially isolated from the host computing environment[¶7, A token relay infrastructure or system is provided that enables a client requester to acquire a properly scoped access token issued by a token issuer authority in a secure manner. The client requestor may be a non-confidential client. Examples of non-confidential clients include browser-based applications such as JavaScript applications. In certain embodiments, the token relay system is a trusted and confidential client of the token issuer authority. Upon receiving an access token request from a client, the token relay system is configured to send a request to the token issuer authority (also sometimes referred to as a token signatory authority) (e.g., OAuth server) requesting an access token on behalf of the requestor. The token issuer authority may then respond by issuing an access token with the appropriate scope to the token relay system. The token issuer authority may, for example, issue an OAuth token. The token relay system may then forward the access token received from the token issuer to the requesting client, who may then use the access token to access a protected resource (e.g., a REST resource).], and [0038] In the embodiment depicted in FIG. 1, the non-confidential client is a JavaScript application 104 executed by a client application such as a browser 106 that may be running on a client data processing system 122. In alternative embodiments, other types of client, including other types of non-confidential clients other than JavaScript applications, may use the services of token relay system 102], and [see FIG 2, ¶60, the request communicated in 206 also includes an OIDC (OpenID Connect) token added by Cloud Gate 112 as a custom HTTP header. The OIDC token is an identity token and may be represented as a JWT (JavaScript Object Notation (JSON)) assertion about the user requestor and/or a reference to the client], and [ see FIG 4, ¶117, In certain embodiments, server 412 may also provide other services or software applications that can include non-virtual and virtual environments…], and [¶122, Server 412 can include one or more virtual machines running virtual operating systems], and [¶152, In instances where computer system 600 is executing one or more virtual machines, one or more processing units may be allocated to each virtual machine.], and [¶162], and[ see FIG.s, ¶68, upon successfully passing all the checks/verifications/validations, token relay system 102 creates a client assertion that is communicated to token issuer authority 110 in 210], and [ see FIGS.1 and 2, ¶69, at 212, token issuer authority 110 (or IDCS 114) verifies if the scopes requested in the token request received in 210 are allowed for token relay system 102]; and[ ¶26]; and
and a token generator of the token issuer that performs operation comprising [see FIGs 1, 2, token issuer authority]; and [¶37, In the embodiment depicted in FIG. 1, a client, such as non-confidential client 104, may use the services provided by token relay system 102 to acquire a properly scoped access token from a token issuer authority 110 in a secure manner. Non-confidential client 104 may then use the acquired access token to access a protected resource 108]; and
in response to validation, by the identity validator, of the identity information, wherein the trust indication is indicative of and based on the trust level of the application as provided to the token issuer by the authorization token manager [¶66, (3) Token relay system 102 identifies the requesting client based upon the client ID included in the request received in 206. Token relay system 102 then verifies that the client associated with that client ID is allowed to request the specified scopes as identified in the scoped information (requires token relay specific provisioning) in the request received in 206. In some embodiments, token relay system 102 is configured with information identifying clients and, for each client, the allowable scope(s) for the client. Token relay system 102 may use this preconfigured information to verify if the scope requested in the request received in 206 is appropriate or valid or allowed for that client], and [¶34, The token relay system may also use the information received from the client in the token request to ensure that the requested token is of the proper scope for the requesting client. As indicated above, the information received from the client requestor may include information identifying a scope for the access token The token relay system may check the requested scope for the access token and then request an access token from the token issuer authority that is properly scoped corresponding to the scope information identified in the token request received from the client], and [¶93, As described above, the token relay system may serve multiple applications, each one with access granted to potentially different audiences/scopes. In certain embodiments, token relay system 102 provides a way for a user (e.g., an administrator) to register client applications that it trusts and to set the audiences/scopes that each application is entitled to. This enables token relay system 102 to, when an access token request comes in from a particular client, to check the access token scope requested by that request with the scope registered for that client application. If the scope requested by the client application is outside the scope registered for that client, then that access token request may not be further processed. In this manner, a client is prevented from requesting an access token of a scope that is not appropriate for that client]; and
and transmitting the authorization token that includes the trust indication to the application[¶71, At 216, token relay system 102 relays the access token received from IDCS 114 (or token issuer authority 110) in 214 all the way back to non-confidential client 104].
While Srinivasan discloses receiving a trust level, from the authorization token manager, indicating a level of trust of the application [¶66, (3) Token relay system 102 identifies the requesting client based upon the client ID included in the request received in 206. Token relay system 102 then verifies that the client associated with that client ID is allowed to request the specified scopes as identified in the scoped information (equating to trust level) (requires token relay specific provisioning) in the request received in 206. In some embodiments, token relay system 102 is configured with information identifying clients and, for each client, the allowable scope(s) for the client. Token relay system 102 may use this preconfigured information to verify if the scope requested in the request received in 206 is appropriate or valid or allowed for that client], and [¶34, The token relay system may also use the information received from the client in the token request to ensure that the requested token is of the proper scope for the requesting client. As indicated above, the information received from the client requestor may include information identifying a scope for the access token (equated to trust indication). The token relay system may check the requested scope for the access token and then request an access token from the token issuer authority that is properly scoped corresponding to the scope information identified in the token request received from the client], and [¶93, As described above, the token relay system may serve multiple applications, each one with access granted to potentially different audiences/scopes( equating to trust level). In certain embodiments, token relay system 102 provides a way for a user (e.g., an administrator) to register client applications that it trusts and to set the audiences/scopes that each application is entitled to (equating to trust level). This enables token relay system 102 to, when an access token request comes in from a particular client, to check the access token scope requested by that request with the scope registered for that client application. If the scope requested by the client application is outside the scope registered for that client, then that access token request may not be further processed. In this manner, a client is prevented from requesting an access token of a scope that is not appropriate for that client]; and
Sirnivasan, does not explicitly disclose , however Schultz disclose receiving a trust level, from the authorization token manager, indicating a level of trust of the application,
Generating authorization token, wherein the authorization token includes a trust identification field that includes a trust indication of the application and is separate from any resource scope associated with the authorization token
[¶12, Systems and/or methods, described herein, may enable a trust level application (hereinafter referred to as "trust application") to obtain context information associated with a user device and to use the context information and/or information associated with the user device to identify a level of trust to be assigned to the user device. The trust application may use the identified level of trust to determine whether and/or at what level the user device is to be granted access to a network. The trust application may also, or alternatively, use the identified level of trust to determine whether a potential security event, associated with the network, has occurred that may cause the trust application to perform a containment operation in order to avoid and/or minimize effects caused by the security event. The trust application may communicate with a proxy server that enables the identified level of trust to be determined and/or maintained with the user device. The trust application may communicate with the proxy server in the event that the potential security event has been detected, in order to prevent the security event from compromising the security and/or data associated with the network], and [¶¶17, 20], and [¶¶23-24, Based on a level of trust identified for user device 110, the trust application may grant a level of access, to service provider network 160 and/or information associated with another user device 110, that corresponds to the identified level of trust. For example, the trust application may generate a token that is to be used by user device 110 to access service provider network and/or the information associated with the other user device 110. The token may identify a level of access, a time period for which the access is granted, terms of renewing the token (e.g., within a renewal period of time after the time period expires, etc.), etc. Trust application may cause SCGW 140 to send the token to user device 110, via SCP 120, to be used to access service provider network 160 and/or the information associated with the other user device 110], and [¶¶52-53], and [ see FIG 6, and associated text for more details, ¶¶60-63, FIG. 6 is a diagram of an example trust level data structure 600 (hereinafter referred to as trust data structure 600) according to an implementation described herein. Trust data structure 600 may be used by the trust application, hosted by SCGW 140 to determine a level of trust to assign to user device … Score field 610 may store values corresponding to a relative measure of trustworthiness (hereinafter referred to as trust values), associated with a particular user device 110… The trust application may assign a trust value for a particular entry based on whether or not the entry stores information. For example, user info field 406 may store information associated with a user of the particular user device 110 (e.g., user1) and the trust application may store a particular trust value (e.g., 1) in score field 610-1 that corresponds to user info field 406 based on the determination that user info field 406 stores the information associated with the user. In another example, user info field 406 may not store information associated with the user and the trust application may store a trust value that is less than the particular trust value (e.g., 0) in score field 610-P that corresponds to user info field 406 based on the determination that user info field 406 does not store the information associated with the user], and [¶66, Based on the values stored in the level of trust fields 620, the trust application may, in one example, determine whether to authorize user device 110 to access service provider network 160 based on whether the level of trust, associated with user device 110, is greater than a threshold. In another example, the trust application may deny access to user device 110 when the level of trust, associated with user device 110, is less than the threshold and may detect a potential security event if the level of trust is below a minimum threshold. If a potential security event is detected, the trust application may determine that user device 110 poses a substantial and/or immediate security threat to the integrity of the service provider network 160, such as when an imposter user device 110 is identified, when a potential virus is detected, when a user device associated with a suspended account is being used, etc. Based on the detection of the potential security event, the trust application may perform an operation to contain the security event in a manner described above (e.g., with respect to FIGS. 2 and 3). In still another example, the trust application may grant limited access if the level of trust is greater than the threshold, but less than another threshold. The trust application may grant higher levels of access that correspond to higher levels of trust], and [¶80, The access token may be sent to SCP 120 and/or user device 110 that enables user device 110 to use the access token in order to access service provider network 160. The access token may, for example, identity a level of access (minimum, medium, maximum, etc.), a period of time during which the access is authorized, information on which access is authorized (e.g., information associated with user device 110 and/or context information associated with user device 110), whether and/or a manner in which the period of time may be extended, etc.], and [see FIG 7 and corresponding text , ¶¶76-79, if a level of trust is not less than a threshold (block 720--NO), then process 700 may include generating a token based on the level of trust (block 735) and sending the token to the user device 110 (block 740). For example, the trust application may determine that a potential security event has not occurred based on a determination that the level of trust is not less than the threshold. For example, the level of trust may not be less than the threshold when a quantity of entries (e.g., within the trust data structure), that store data items associated with information associated with user device 110 or context information associated with user device 110, are greater than an entry threshold (e.g., when none or only a few entries are empty relative to the entry threshold). The trust application may, in this example, assign a trust value, to a data item stored within an entry, that is greater than a trust value that corresponds to an entry that does not store a data item…].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Sirnivasan, by incorporating “ by measuring the security risk of a trust application associated with the user device”, as taught by Schultz. One could have been motivated to do so in order to obtain information associated with the user device that includes an identifier associated with the user device and context information associated with the user device; determine a level of trust associated with the user device based on the identifier and the context information, where the level of trust is a measure of security risk associated with the user device; generate an access token based on the level of trust, where the access token identifies a level at which the user device is authorized to access the network; and send, to the user device via the proxy server, the access token that enables the proxy server to authorize the user device to access the network at the level identified by the access token [ Schultz, Abstract.].
Regarding claim 2, Srinivasan discloses wherein the trust indication comprises an indication that the application executing in the virtual computing environment is not trusted [¶4, when a client is a non-confidential client, the security of its environment cannot be guaranteed or trusted like for a confidential client], and [see FIG 4, ¶117, In certain embodiments, server 412 may also provide other services or software applications that can include non-virtual and virtual environments…], and [¶122, Server 412 can include one or more virtual machines running virtual operating systems], and [¶152, In instances where computer system 600 is executing one or more virtual machines, one or more processing units may be allocated to each virtual machine.], and [¶162].
Regarding claims 3, and 14, wherein the virtual computing environment comprises a virtual machine hosted in the host computing environment
While Srinivasan discloses: [see FIG 4, ¶117, In certain embodiments, server 412 may also provide other services or software applications that can include non-virtual and virtual environments…], and [¶122, Server 412 can include one or more virtual machines running virtual operating systems], and [¶152, In instances where computer system 600 is executing one or more virtual machines, one or more processing units may be allocated to each virtual machine.], and [¶162].
Furthermore, Schultz discloses [ ¶40, , security configuration manager 340 may reestablish one or more virtual environments, by recreating, configuring and/or starting up one or more virtual machines associated with SCP server 120. In still another example, security configuration manager 340 may communicate with another server device (e.g., administrative server 150) to obtain a copy and/or image of the contents of SCP server 120 and/or SCGW 140 in order to perform the restore and/or reinstall operation].
Regarding claim 4, Sirnivasan discloses, wherein the authorization token is configured to permit the application executing in the virtual computing environment to access a secured resource in the host computing environment[ see Paragraphs 11,122,152, and 162, visualization, virtual machine, hypervisor], and[ ¶3, the OAuth standard defines a set of interactions (protocol flows) for clients (e.g., applications) to acquire tokens, which can then be used to securely access protected resources such as REST based web resources. The most secure posture that an OAuth client can assume is that of a "confidential client," where the client is required to be able to securely maintain a secret (e.g., client identifying credentials such as a certificate/key pair). A confidential client can validate itself using the secret information and then get an access token to access a protected resource.], and [see FIG 4, ¶117, In certain embodiments, server 412 may also provide other services or software applications that can include non-virtual and virtual environments…], and [¶122, Server 412 can include one or more virtual machines running virtual operating systems], and [¶152, In instances where computer system 600 is executing one or more virtual machines, one or more processing units may be allocated to each virtual machine.], and [¶162].
Regarding claim 5, Sirnivasan discloses, wherein the authorization token is configured to permit the application executing in the virtual computing environment to access a secured resource over a network [¶3, the OAuth standard defines a set of interactions (protocol flows) for clients (e.g., applications) to acquire tokens, which can then be used to securely access protected resources such as REST based web resources. The most secure posture that an OAuth client can assume is that of a "confidential client," where the client is required to be able to securely maintain a secret (e.g., client identifying credentials such as a certificate/key pair). A confidential client can validate itself using the secret information and then get an access token to access a protected resource], and [see FIG., items #218(Use access token and CALL REST resource endpoint) and item#220(permit access to protected resource], and [see FIG 4, ¶117, In certain embodiments, server 412 may also provide other services or software applications that can include non-virtual and virtual environments…], and [¶122, Server 412 can include one or more virtual machines running virtual operating systems], and [¶152, In instances where computer system 600 is executing one or more virtual machines, one or more processing units may be allocated to each virtual machine.], and [¶162].
Furthermore, Schultz discloses [ ¶12, The trust application may use the identified level of trust to determine whether and/or at what level the user device is to be granted access to a network.], and [¶62, 0062] Level of trust field 620 may store a value that represents a sum of the trust values, stored in score field 610, associated with user device 110. The value stored in level of trust field 620 may correspond to a measure of trustworthiness (e.g., a level of trust) associated with the particular user device 110 that the trust application may use to determine whether to permit the particular user device 110 to access services provided by provider network 160. Additionally, or alternatively, the trust application may use the value, stored in level of trust field 620, to determine a level of access, to service provider network 160, that is authorized for the particular user device 110, such as no access (e.g., no access to any services), limited access (e.g., access to particular services and no access to other services), full access (e.g., access to all services), etc. The trust application may also, or alternatively, determine whether a potential security event has been detected (e.g., when a level of trust is below a threshold)],
Regarding claim 6, Sirnivasan discloses, wherein the access of the secured resource by the application executing in the virtual computing environment comprises a read-only access of the secured resource [ see table A, A Client ID Origin Scopes ABC_ReadWrite_App
http://www.abc.com read, write ABC_Read_App http://www.abc.com read
XYZ_ReadWrite_App http://www.xyz.com read, write], and [¶¶105-108], and [see FIG 4, ¶117, In certain embodiments, server 412 may also provide other services or software applications that can include non-virtual and virtual environments…], and [¶122, Server 412 can include one or more virtual machines running virtual operating systems], and [¶152, In instances where computer system 600 is executing one or more virtual machines, one or more processing units may be allocated to each virtual machine.], and [¶162].
Regarding claim 7, this claim is interpreted and rejected for the same rational set forth in claim 1.
Regarding claims 8, and 21, Sirnivasan discloses wherein said obtaining the authorization token comprises: transmitting the token request and the assigned trust level to the token issuer; receiving the authorization token that includes the trust indication corresponding to the trust level from the token issuer [¶66, (3) Token relay system 102 identifies the requesting client based upon the client ID included in the request received in 206. Token relay system 102 then verifies that the client associated with that client ID is allowed to request the specified scopes as identified in the scoped information (equating to trust level) (requires token relay specific provisioning) in the request received in 206. In some embodiments, token relay system 102 is configured with information identifying clients and, for each client, the allowable scope(s) for the client. Token relay system 102 may use this preconfigured information to verify if the scope requested in the request received in 206 is appropriate or valid or allowed for that client], and [¶34, The token relay system may also use the information received from the client in the token request to ensure that the requested token is of the proper scope for the requesting client. As indicated above, the information received from the client requestor may include information identifying a scope for the access token (equated to trust indication). The token relay system may check the requested scope for the access token and then request an access token from the token issuer authority that is properly scoped corresponding to the scope information identified in the token request received from the client], and [¶93, As described above, the token relay system may serve multiple applications, each one with access granted to potentially different audiences/scopes( equating to trust level). In certain embodiments, token relay system 102 provides a way for a user (e.g., an administrator) to register client applications that it trusts and to set the audiences/scopes that each application is entitled to (equating to trust level). This enables token relay system 102 to, when an access token request comes in from a particular client, to check the access token scope requested by that request with the scope registered for that client application. If the scope requested by the client application is outside the scope registered for that client, then that access token request may not be further processed. In this manner, a client is prevented from requesting an access token of a scope that is not appropriate for that client], and [ see FIG.s, ¶68, upon successfully passing all the checks/verifications/validations, token relay system 102 creates a client assertion that is communicated to token issuer authority 110 in 210], and [ see FIGS.1 and 2, ¶69, at 212, token issuer authority 110 (or IDCS 114) verifies if the scopes requested in the token request received in 210 are allowed for token relay system 102]; and
Regarding claims 9, and 22, Sirnivasan discloses, wherein the trust indication comprises an indication that the application executing in the virtual computing environment is not trusted [¶4, when a client is a non-confidential client, the security of its environment cannot be guaranteed or trusted like for a confidential client], and [see FIG 4, ¶117, In certain embodiments, server 412 may also provide other services or software applications that can include non-virtual and virtual environments…], and [¶122, Server 412 can include one or more virtual machines running virtual operating systems], and [¶152, In instances where computer system 600 is executing one or more virtual machines, one or more processing units may be allocated to each virtual machine.], and [¶162].
Regarding claims 10, and 23, Sirnivasan discloses, wherein the resource is stored in the host computing environment; and wherein the method further comprises: receiving the authorization token from the application executing in the second computing environment[ see FIG.s, ¶68, upon successfully passing all the checks/verifications/validations, token relay system 102 creates a client assertion that is communicated to token issuer authority 110 in 210], and [ see FIGS.1 and 2, ¶69, at 212, token issuer authority 110 (or IDCS 114) verifies if the scopes requested in the token request received in 210 are allowed for token relay system 102]; and [see FIG 2, ¶60, the request communicated in 206 also includes an OIDC (OpenID Connect) token added by Cloud Gate 112 as a custom HTTP header. The OIDC token is an identity token and may be represented as a JWT (JavaScript Object Notation (JSON)) assertion about the user requestor and/or a reference to the client], and [ see FIG 4, ¶117, In certain embodiments, server 412 may also provide other services or software applications that can include non-virtual and virtual environments…], and [¶122, Server 412 can include one or more virtual machines running virtual operating systems], and [¶152, In instances where computer system 600 is executing one or more virtual machines, one or more processing units may be allocated to each virtual machine.], and [¶162]; and
and performing a precautionary action in the host computing environment to protect the resource in response to receiving the authorization token [¶141, a virus scanning and whitelist service, a high availability, backup and recovery service].
Regarding claims 11, and 24, Sirnivasan discloses, wherein the precautionary action includes creation of a backup of the resource in response to receiving the authorization token [¶141, a virus scanning and whitelist service, a high availability, backup and recovery service].
Regarding claim 12, Sirnivasan discloses, further comprising: granting a read-only access to the resource by the host computing environment in response to receiving the authorization token [ see table A, A Client ID Origin Scopes ABC_ReadWrite_App http://www.abc.com read, write ABC_Read_App http://www.abc.com read XYZ_ReadWrite_App http://www.xyz.com read, write], and [¶¶105-108].
Regarding claim 13, Sirnivasan discloses, wherein the resource is stored in a server that is configured to perform a precautionary action in response to: receiving the authorization token [ see FIG., items #218(Use access token and CALL REST resource endpoint) and item#220(permit access to protected resource]; and
and determining the precautionary action is to be performed based on the extracted trust indication [¶141, a virus scanning and whitelist service, a high availability, backup and recovery service]; and
extracting the trust indication from the authorization token [¶66, (3) Token relay system 102 identifies the requesting client based upon the client ID included in the request received in 206. Token relay system 102 then verifies that the client associated with that client ID is allowed to request the specified scopes as identified in the scoped information (equating to trust level) (requires token relay specific provisioning) in the request received in 206. In some embodiments, token relay system 102 is configured with information identifying clients and, for each client, the allowable scope(s) for the client. Token relay system 102 may use this preconfigured information to verify if the scope requested in the request received in 206 is appropriate or valid or allowed for that client], and [¶34, The token relay system may also use the information received from the client in the token request to ensure that the requested token is of the proper scope for the requesting client. As indicated above, the information received from the client requestor may include information identifying a scope for the access token (equated to trust indication). The token relay system may check the requested scope for the access token and then request an access token from the token issuer authority that is properly scoped corresponding to the scope information identified in the token request received from the client], and [¶93, As described above, the token relay system may serve multiple applications, each one with access granted to potentially different audiences/scopes( equating to trust level). In certain embodiments, token relay system 102 provides a way for a user (e.g., an administrator) to register client applications that it trusts and to set the audiences/scopes that each application is entitled to (equating to trust level). This enables token relay system 102 to, when an access token request comes in from a particular client, to check the access token scope requested by that request with the scope registered for that client application. If the scope requested by the client application is outside the scope registered for that client, then that access token request may not be further processed. In this manner, a client is prevented from requesting an access token of a scope that is not appropriate for that client].
Regarding claim 14, Sirnivasan disclose, wherein the virtual computing environment comprises a virtual machine hosted in the first computing environment [¶122, Server 412 can include one or more virtual machines running virtual operating systems], and [¶152, In instances where computer system 600 is executing one or more virtual machines, one or more processing units may be allocated to each virtual machine.], and [¶162].
Furthermore, Schultz discloses [¶40, security configuration manager 340 may reestablish one or more virtual environments, by recreating, configuring and/or starting up one or more virtual machines associated with SCP server 120. In still another example, security configuration manager 340 may communicate with another server device (e.g., administrative server 150) to obtain a copy and/or image of the contents of SCP server 120 and/or SCGW 140 in order to perform the restore and/or reinstall operation].
Regarding claim 15, this claim is interpreted and rejected for the same reason set forth in claims 1, and 7.
Regarding claim 26, Sirnivasan disclose wherein validating the identify information comprises performing, by the identity validator, a look up in a data store to compare the identity information to identity information stored in the data store [¶66, (3) Token relay system 102 identifies the requesting client based upon the client ID included in the request received in 206. Token relay system 102 then verifies that the client associated with that client ID is allowed to request the specified scopes as identified in the scoped information (requires token relay specific provisioning) in the request received in 206. In some embodiments, token relay system 102 is configured with information identifying clients and, for each client, the allowable scope(s) for the client. Token relay system 102 may use this preconfigured information to verify if the scope requested in the request received in 206 is appropriate or valid or allowed for that client], and [¶34, The token relay system may also use the information received from the client in the token request to ensure that the requested token is of the proper scope for the requesting client. As indicated above, the information received from the client requestor may include information identifying a scope for the access token The token relay system may check the requested scope for the access token and then request an access token from the token issuer authority that is properly scoped corresponding to the scope information identified in the token request received from the client], and [¶93, As described above, the token relay system may serve multiple applications, each one with access granted to potentially different audiences/scopes. In certain embodiments, token relay system 102 provides a way for a user (e.g., an administrator) to register client applications that it trusts and to set the audiences/scopes that each application is entitled to. This enables token relay system 102 to, when an access token request comes in from a particular client, to check the access token scope requested by that request with the scope registered for that client application. If the scope requested by the client application is outside the scope registered for that client, then that access token request may not be further processed. In this manner, a client is prevented from requesting an access token of a scope that is not appropriate for that client]; and
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
See relevant references in submitted 892.
Dill ( US2015/0032627) [ SYSTEMS AND METHODS FOR COMMUNICATING TOKEN ATTRIBUTES ASSOCIATED WITH A TOKEN VAULT, see table 1, ¶¶1,46,98, 226, 267 and more].
Powell( US 2015/0127547) [ Network Token system, ¶¶30. 37. 42-44, 46, 51, 55, 80, 87, 11].
Hwang (US2009/016513) [ Abstract, A system for executing a program using a virtual machine monitor and a method of controlling the system are provided. The system includes a virtual machine monitor which divides an operating system (OS) into at least one root domain and a plurality of domains having different trust levels, and a trust-management module which is included in the root domain and periodically measures the trust level of an application program currently being executed in the OS. The virtual machine monitor executes the application program in one of the domains in consideration of the trust level of the application program. The method includes dividing an OS into at least a root domain and a plurality of domains having different trust levels by using a virtual machine monitor, enabling the root domain to periodically measure the trust level of an application program currently being executed in the OS, and executing the application program in one of the domains according to the trust level of the application program.], and [¶10, The present invention provides a system for executing a program using a virtual machine monitor and a method of controlling the system in which the stability of a system can be improved by periodically measuring the trust level of an application program.]; and [¶¶12-13, According to an aspect of the present invention, there is provided a system for executing a program using a virtual machine monitor, the system including a virtual machine monitor which divides an OS into at least one root domain and a plurality of domains having different trust levels; and a trust-management module which is included in the root domain and periodically measures the trust level of an application program currently being executed in the OS, wherein the virtual machine monitor executes the application program in one of the domains in consideration of the trust level of the application program. According to another aspect of the present invention, there is provided a method of controlling a system for executing a program using a virtual machine monitor, the method including dividing an OS into at least a root domain and a plurality of domains having different trust levels by using a virtual machine monitor; enabling the root domain to periodically measure the trust level of an application program currently being executed in the OS; and executing the application program in one of the domains according to the trust level of the application program].
Curtis (US2018/0247055) [ Abstract, A method is provided for protecting a host device from untrusted applications. Upon detecting an initial installation and/or execution of an application, the application is executed within a first virtual machine having a first level of monitoring and/or operating constraints. The application may be executed alone in the first virtual machine. Operation of the application may be monitored to ascertain the level of trust for the application. Upon ascertaining a change in a level of trust in the application, the application may be migrated to execute within a second virtual machine having a second level of monitoring and/or operating constraints, wherein the second level of monitoring and/or operating constraints has different operating restrictions than the first level of monitoring and/or operating constraints].
Abraham (US2013/0024929) [0022] The system 100 has an isolation execution environment 104 and a trust activation engine 106. The isolation execution environment 104 may be configured to execute a low-privilege application 102 in a user process 108. The user process 108 may be associated with a token 110 that identifies the application 102 running in the user process 108 and the permissions or capabilities that the application 102 is permitted to access. The token 110 may include a user secure identifier (SID), a package SID, and the capabilities of the application. The user SID identifies the user process, and the package SID identifies the application. The capabilities are the user-permitted accesses to resources that the application 102 requires].
[0034] Referring to FIG. 5, the process determines the privilege level associated with the application requesting access to a trust level component (block 170). A trust activation engine 106 receives an API call from a user process 108 making the request and determines the identity of the user process 108. The trust activation engine 106 may determine the identity of the user process 108 from the token 110 passed in the API call. If the package SID in the token 110 matches an entry in the operating system registry for processes executing within an isolation execution environment 104, then the trust activation engine 106 determines that the calling application has a low privilege level. Otherwise, the trust activation engine 106 determines that the calling application has a high privilege level].
Barbir (US2015/0106895) [ 0026-0027] In step S302, the network server 204 send transmit back a "security token" with the level of trust authentication to the API of the application. In one aspect, the "security token" is provided for authentication to a grouped application based on applicable trust criteria. In one aspect, when a user interacts with one application in the group, the trust is elevated through the application internal authentication application program interface (API). The trust is then included in the security token to make available to other applications in the group. Applications can be in multiple groups with variable level of authentication based on network location or source IP address, geographic location and other transactions variable.
Folley (US2009/0204964) [0161] An important UI requirement for any MIEP that simultaneously supports trusted and untrusted VMs and application software is to indicate to the user the trust level of the application and/or VM he is interacting with. We call the overall capability of securely displaying to the user the trust state of the MIEP "visual attestation".
Yeakley (US2016/0294779) [0023] FIG. 2A illustrates one embodiment of the present invention. Application 210 is installed on device 110 in its own trust level, an application trust level, which is separate and distinct from the operating system trust level. The separate trust levels offer security on the device 110 so that applications cannot make changes to the hardware settings of the device 110 except through the mechanisms described in the present invention].
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 SHAHRIAR ZARRINEH whose telephone number is (571)272-1207. The examiner can normally be reached Monday-Friday, 8:30am-5:30pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jorge Ortiz-Criado can be reached at 571-272-7624. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SHAHRIAR ZARRINEH/Primary Examiner, Art Unit 2496
Prosecution Insights