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 .
Response to Arguments
1. Applicant’s arguments have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Specifically, Smith & Wang et al. (US 20230216849 A1) teaches the elements relating to the addition to a second attester alongside a first attester.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
2. Claims 1-2, 5-6, 8-12, 15-6, 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Faynberg et al. (US 20180213003 A1) in view of Smith & Wang et al. (US 20230216849 A1) and Smith et al. (US 20220245252 A1).
Claim 1 Faynberg teaches an Information Handling System (IHS), comprising:
a processor; (¶0042, a processor) and
a memory coupled to the processor, (¶0042, a memory device) the memory having program instructions stored thereon that, upon execution by the processor, (¶0042, upon execution by the processor) cause the IHS to:
receive, from a workspace orchestrator, (FIG. 1, Attestation Operations Systems (AOS) 114) a request to attest a plurality of workspace components (FIG. 1, Cloud Hosts 112, ¶0024, receiving from the workspace orchestrator AOS 114 a trigger to being the attestation process, i.e. a request to attest workspace components, wherein the plurality of workspace components being attested comprises the Cloud Hosts 112) within a workspace instantiated by a client IHS; (FIG. 1, ¶0021, where Could Host 112 are within a workspace, i.e. Data Centers 110, instantiated by a client; ¶0024, wherein the host comprises the client IHS and boots software of the Data Center 110, i.e. instantiating a workspace)
send an indication of the request to one or more attester; (FIG. 1, ¶0024, AOS 114 directing the ASP 116 to attest, i.e. sending an indication of the request to attester)
receive attestation evidence from the one or more attester. (FIG. 1, ¶0024, receiving from ASP 116 information of the current state of all cloud hosts, i.e. attestation evidence)
However, Faynberg does not explicitly teach wherein the one or more attester comprises a first and second attester;
wherein the first attester is within a first workspace component of the plurality of workspace components within the workspace;
wherein the second attester is within a second workspace component of the plurality of workspace components within the workspace.
wherein the attestation evidence is signed with one of more respective attestation key; and based on the attestation evidence, determine whether the first attester and the second attester correspond to the workspace.
From a related technology, Smith & Wang, teaches wherein the one or more attester comprises a first and second attester; (FIG. 8, Attester Nodes 4-10, ¶0131)
wherein the first attester is within a first workspace component of the plurality of workspace components within the workspace; (FIG. 8, wherein a first attestor Node 4 is within a first workspace component, Domain 821, within the plurality of workspaces)
wherein the second attester is within a second workspace component of the plurality of workspace components within the workspace. (FIG. 8, wherein a second attestor Node 6 is within a first workspace component, Domain 831, within the plurality)
It would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Faynberg to Smith & Wang to incorporate a secondary attester in order to more effectively utilize network resources.
However, Faynberg in view of Smith & Wang does not explicitly teach attestation evidence is signed with one of more respective attestation key; and
based on the attestation evidence, determine whether the first attester and the second attester correspond to the workspace.
Smith teaches attestation evidence signed with an attestation key; (FIG. 9A, block 925, ¶0080, signing the attestation evidence using an attestation key) and
based on the attestation evidence, determine whether the first attester and the second attester correspond to the workspace. (¶0080, wherein based on the attestation evidence the attesters corresponds to the workspace, proceed with the method to step (B))
It would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Faynberg in view of Smith & Wang to incorporate the attestation techniques utilized by Smith in order to more effective utilize network resources.
Claim 2 Faynberg in view of Smith & Wang and Smith teaches Claim 1, and further teaches wherein the workspace orchestrator is configured to receive requests from local management agents executed by each of a plurality of client IHSs to instantiate workspaces. (Smith, FIG. 4, I/O 404, ¶0045, the workspace orchestrator comprising a input element, Faynberg, FIG. 1, ¶0024, receiving an information, i.e. a request, to begin an instantiation process for a workspace, receiving the request from AOS 114, comprising local management agents)
Claim 5 Faynberg in view of Smith & Wang and Smith teaches Claim 1, and further teaches wherein the workspace comprises a plurality of workspace components selected from the group consisting of: an application, (Smith, ¶0024, wherein the workspace component comprises software, i.e. an application) a remote service, and a container.
Claim 6 Faynberg in view of Smith & Wang and Smith teaches Claim 1, and further teaches wherein the attester is configured to provide a first attester identifier (ID) and an orchestrator ID to a keystore. (Smith, FIG. 9A, ¶0079, wherein the attester generates compound device identifiers, i.e. CDIs, i.e. attester and orchestrator IDs, Examiner interprets a keystore as generic memory elements wherein said data would be stored)
Claim 8 Faynberg in view of Smith & Wang and Smith teaches Claim 7, and further teaches receiving attestation evidence from the attester, (Faynberg, FIG. 1, ¶0024, receiving from the ASAP 116 updated information of the current state of all cloud hosts, i.e. attestation evidence) wherein the attestation evidence is signed with the attestation key. (Smith, FIG. 9A, block 925, ¶0080, signing the attestation evidence using an attestation key)
Claim 9 Faynberg in view of Smith & Wang and Smith teaches Claim 8, and further teaches wherein the attestation evidence comprises data provided by at least one of: a Basic Input/Output System (BIOS), an Operating System (OS), (Smith, ¶0056, wherein the attestation evidence comprises root of trust evidence provided by the host’s operating system) an Embedded Controller (EC), or an Out-of-Band (OOB) or Baseband Management Controller (BMC).
Claim 10 is taught by Faynberg in view of Smith & Wang and Smith as described for Claim 1.
Claim 11 is taught by Faynberg in view of Smith & Wang and Smith as described for Claim 5.
Claim 12 Faynberg in view of Smith & Wang and Smith teach Claim 10, and further teaches wherein the workspace component is instantiated under control of a workspace orchestrator, (FIG. 1, ¶0021, wherein the Data Centers 110 are instantiated under control of Attestation Operations Systems (AOS) 114) and wherein the verifier is configured to receive a command from the workspace orchestrator to produce the request. (Smith, FIG. 4, I/O 404, ¶0045, comprising a input element, Faynberg, FIG. 1, ¶0024, wherein the AOS 114 is informed about the presence of the new host 112 and then AOS 114 directs ASP 116 to begin the attestation process, i.e. wherein being informed comprises a request to attest the workspace component, Cloud Hosts 112)
Claim 15 is taught by Faynberg in view of Smith & Wang and Smith as described for Claim 6.
Claim 17 is taught by Faynberg in view of Smith & Wang and Smith as described for Claim 9.
Claim 18 is taught by Faynberg in view of Smith & Wang and Smith as described for Claim 1.
Claim 19 Faynberg in view of Smith & Wang and Smith teaches Claim 18, and further teaches receiving, at the workspace orchestrator from the client IHS, a credential challenge; (Faynberg, FIG. 1, ¶0024, wherein the AOS 114 is informed about the presence of the new host 112 and then AOS 114 directs ASP 116 to begin the attestation process, i.e. wherein the presence of the new host comprises the receiving of a credential challenge) and
in response to the challenge, providing a credential from the workspace orchestrator to the client IHS. (Faynberg, FIG. 1, ¶0024, receiving from the ASAP 116 updated information of the current state of all cloud hosts, i.e. credential)
Claim 20 Faynberg in view of Smith & Wang and Smith teaches Claim 19, and further teaches wherein the client IHS is configured to release an attestation key to the workspace component, (Smith, FIG. 7, ¶0066, wherein attestation key is configured for release to the workspace component)
wherein the workspace component is configured to provide attestation evidence to the verifier, (Faynberg, FIG. 1, ¶0024, receiving from the ASAP 116 updated information of the current state of all cloud hosts, i.e. attestation evidence) and
wherein the attestation evidence is encrypted with the attestation key. (Smith, FIG. 9A, block 925, ¶0080, signing the attestation evidence using an attestation key)
3. Claims 3-4 and 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over Faynberg et al. (US 20180213003 A1) in view of Smith & Wang et al. (US 20230216849 A1) and Smith et al. (US 20220245252 A1) and in further view of Yankovich et al. (US 8214747 B1).
Claim 3 Faynberg in view of Smith & Wang and Smith teaches Claim 2, but does not explicitly teach wherein the workspace orchestrator is configured to, for each request:
create a workspace definition based upon a target; and
transmit one or more files to a local management agent to enable instantiation of the workspace based upon the workspace definition.
Yankovich teaches create a workspace definition based upon a target; (FIG. 11, Col. 11, Lines 39-48, creating a workspace definition; Col. 11, Lines 49-56, the workspace definition based upon an identification of a software application selected by the user) and
transmit one or more files to a local management agent to enable instantiation of the workspace based upon the workspace definition. (Col. 10, Lines 52-67, wherein the workspace definition are processed by application container, i.e. local management agents that receive the workspace definitions, to instantiate workplaces based on the definition)
It would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Faynberg in view of Smith further with the teachings of Yankovich in order to better enable workspaces and therefore utilize network resources in an efficient and effective manner.
Claim 4 Faynberg in view of Smith & Wang, Smith and Yankovich teaches Claim 3 and further teaches wherein the target is calculated, at least in part, based upon at least one of:
an identification of a software application requested by a user of the client IHS (Yankovich, Col. 11, Lines 49-56, the workspace definition based upon an identification of a software application selected by the user) or an identification of a datafile requested by a user of the client IHS, an identification of a locale of the client IHS, an identification of a user of the client IHS, an identification of a network of the client IHS, an identification of hardware of the client IHS, an identification of a requested datafile, an identification of a storage system of the requested datafile, a risk metric associated with a locale of the client IHS, a risk metric associated with a user of the client IHS, a risk metric associated with a network of the client IHS, a risk metric associated with hardware of the client IHS, a risk metric associated with a requested datafile, a regulatory risk metric, a threat monitoring level, a threat detection level, a threat analytics level, a threat response level, a storage confidentiality level, a network confidentiality level, a memory confidentiality level, a display confidentiality level, a user authentication level, an Information Technology (IT) administration level, a regulatory compliance level, a local storage control level, a Central Processing Unit (CPU) access level, a graphics access level, an application usage level, or an application installation level.
Claims 13-14 are taught by Faynberg in view of Smith & Wang, Smith, and Yankovich as described for Claims 3-4.
4. Claims 7 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Faynberg et al. (US 20180213003 A1) in view of Smith & Wang et al. (US 20230216849 A1) and Smith et al. (US 20220245252 A1) and in further view of Fregly et al. (US 10848301 B1).
Claim 7 Faynberg in view of Smith & Wang and Smith teaches Claim 6, and further teacher wherein the keystore is configured to: identify the workspace orchestrator using the orchestrator ID. (Smith, FIG. 9A, ¶0079, wherein the attester generates compound device identifiers, i.e. CDIs, i.e. orchestrator IDs identifies the workspace orchestrator)
However, Faynberg in view of Smith does not explicitly teach receive a second attester ID from the workspace orchestrator in response to a credential challenge; and
provide the attestation key to the attester in response to a match between the second attester ID and the first attester ID.
From a related technology, Fregly teaches receive a second attester ID from a workspace orchestrator in response to a credential challenge; (Col. 7, Lines 30-64, receiving an ID in response to determining device trusted, i.e. credential challenge) and
provide the attestation key to the attester in response to a match between the second attester ID and the first attester ID. (Col. 7, Lines 30-64, providing the key in response to determining the attester identifiers match one another)
It would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Faynberg in view of Smith to incorporate the teachings of Fregly regarding secondary attestors in order to more effectively utilize network resources.
Claim 16 is taught by Faynberg in view of Smith & Wang, Smith, and Fregly as described for Claim 7.
Conclusion
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 CHRISTOPHER PALACA CADORNA whose telephone number is (571)270-0584. The examiner can normally be reached M-F 10:00-7:00.
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, John Follansbee can be reached at (571) 272-3964. 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.
/CHRISTOPHER P CADORNA/Examiner, Art Unit 2444
/JOHN A FOLLANSBEE/Supervisory Patent Examiner, Art Unit 2444
Prosecution Insights