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 12/04/2025. Claims 1-7, 9-10, 12, 14-15, 22-23, and 25, are amended. Claims 16-20 are cancelled. Claims 1-15, and 21-25 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.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission has been entered.
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”.
CLAIM INTERPRETATION
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function.
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “an identity validator configured to… ….”, and “a token generator configured to…” in claim 1 and “the authorization token is configured to …” in claims 4, and 5.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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-6 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) are: “an identity validator configured to… ….”, and “a token generator configured to…” in claim 1 and “the authorization token is configured to …” in claims 4, and 5.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claims limitation “an identity validator configured to… ….”, and “a token generator configured to…” in claim 1 and “the authorization token is configured to …” in claims 4, and 5.
invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Claims 2-3, and 6 do not cure the deficiency of claim 1 and are rejected under 35 USC 112, 2nd paragraph, for their dependency upon claim 1.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Response to Arguments
Applicant's arguments filed 12/04/2025 have been fully considered but they are not persuasive:
Applicant submits on pages 8-9 of remarks filed on 12/04/2025 regarding claim 1 that the cited references do not disclose or suggest at least the above- emphasized features of claim 1 as amended.
Examiner respectfully disagrees with applicant argument for claim 1 filed on 12/04/2025on pages 8-9 of remarks.
Sirnivasan discloses receive from an authorization token manager of a host computing environment of a computing device that is separate from the authorization server[ 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 [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, 32, 34, 62]; and
wherein the application generates the token request and provides the token request to the authorization token manager, and wherein the authorization token represents an attempt by the application to access a resource [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. 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
wherein a trust level assignor of the authorization token manager assigns the trust level to the token request based on whether the application is determined to be trusted
[¶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
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 (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
wherein the authorization token manager provides the authorization token 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 the trust indication, and trust level of the application in different paragraphs, see above underlined clauses) however, does not explicitly disclose trust indication, and trust level of the application, however, Hwang discloses [ 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].
Applicant submits on pages 9-10 of remarks filed on 12/04/2025 regarding claims 7, and 15 that the cited references do not disclose or suggest at least the above- emphasized features of claims 7, and 15 as amended.
Examiner respectfully disagrees with applicant argument for claims 7, and 15 filed on 12/04/2025on pages 9-10 of remarks.
Examiner refers Applicant to claim 1 limitation argument/mapping above which are similar to claims 7, and 15 limitations.
Examiner maintains the 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, and 21-25 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. (US2009/0165133) issued to Hwang.
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 of a token issuer implemented by an authorization server, wherein the identity validator is configured to[¶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 [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
receive ,from an authorization token manager of a host computing environment of a computing device that is separate from the authorization server[ 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 [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, 32, 34, 62]; and
a token request that includes identity information of an entity requesting an authorization token ¶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.
[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 [¶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 [Abstract].
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
wherein the application generates the token request and provides the token request to the authorization token manager, and wherein the authorization token represents an attempt by the application to access a resource [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. 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
receive a trust level, from the authorization token manager, indicating a level of trust of the application, wherein a trust level assignor of the authorization token manager assigns the trust level to the token request based on whether the application is determined to be trusted [¶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
and validate the identity information to determine whether to permit the application to obtain the authorization token allowing access to a resource requested by the application [¶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 [¶66, 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 [¶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 [¶66]; and
and a token generator of the token issuer, wherein the token generator is configured to[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, generate the authorization token that includes a trust indication of the application, 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 (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
and transmit the authorization token that includes the trust indication to the application authorization token manager, wherein the authorization token manager provides the authorization token 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 the trust indication, and trust level of the application in different paragraphs, see above underlined clauses) however, does not explicitly disclose trust indication, and trust level of the application, however, Hwang discloses [ 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].
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 “trust-management module in the root domain”, as taught by Hwang. One could have been motivated to do so in order to periodically measures the trust level of an application program currently being executed in the OS. [ Hwang, 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, 14, and 25, 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, Hwang discloses [ Abstract, ¶¶10, 12-13].
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 “virtual machine monitor”, as taught by Hwang. One could have been motivated to do so in order to executes the application program in one of the domains in consideration of the trust level of the application program [ Hwang, Abstract.].
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].
Furthermore, Hwang discloses [ Abstract, ¶¶10, 12-13].
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, Hwang discloses [ Abstract, ¶¶10, 12-13].
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, Hwang discloses [ Abstract, ¶¶10, 12-13].
Regarding claim 15, this claim is interpreted and rejected for the same reason set forth in claims 1, and 7.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
See relevant references in submitted 892.
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].
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