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 .
This application has been examined. Claims 1-20 are pending.
The Group and/or Art Unit location of your application in the PTO has changed. To aid in correlating any papers for this application, all further correspondence regarding this application should be directed to Group Art Unit 2175.
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.
Claim Rejections - 35 USC § 112
The following is a quotation of the second paragraph of 35 U.S.C. 112:
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-20 are rejected under 35 U.S.C. 112(b) as failing to particularly point out and distinctly claim the subject matter regarded as the invention.
(a) Claim 1 - singular/plural antecedent mismatch (“self-encrypting disks”)
The preamble of claim 1 recites “a self-encrypting disk” (singular). The body then recites “encryption and decryption tasks of the self-encrypting disks” and “encryption keys for encrypting the self-encrypting disks” (plural, with definite article). There is insufficient antecedent basis for the plural limitation “the self-encrypting disks.” It is unclear whether the claim requires one disk or a plurality of disks, and therefore unclear whether the later-recited step of “unlocking the self-encrypting disk” unlocks all disks or only the single disk of the preamble. Claims 13, 14, and 20 contain the same defect and are rejected for the same reason.
(b) Claim 1- “the unlocking disk function”
Claim 1 recites “loading an unlock disk function” and later recites “the unlocking disk function.” The terms “unlock disk function” and “unlocking disk function” are not identical, and it is unclear whether they refer to the same element or to two different functions. For examination purposes the Examiner treats them as the same element. Claims 14 and 20 contain the same defect.
(c) Claim 4 - “loosing”
Claim 4 recites “upon loosing electric power.” The term “loosing” is grammatically incorrect and renders the claim indefinite. It appears “losing” is intended. Correction is required.
(d) Claim 6 - “the communication device”
Claim 6 recites “synchronizing the deployment module and the CMDB module via the communication device.” Parent claim 5 recites only “a communication module.” There is insufficient antecedent basis for “the communication device.” It is unclear whether the “communication device” is the previously recited “communication module” or an additional, distinct structure. Claim 18 contains the same defect.
(e) Claim 11 - “features taken from among at least one of”
Claim 11 recites “providing features taken from among at least one of the operations: logging, monitoring, auditing, and security.” The phrase “taken from among at least one of” is an improper Markush-type construction of indeterminate scope; it is unclear whether the claim requires one, several, or all of the listed operations, and “security” is not an “operation” of the same category as logging, monitoring, and auditing. See MPEP § 2173.05(h).
(f) Claim 14 - preamble/body inconsistency in the SED connection path
Claim 14 recites “a self-encrypting disk connected to the customer network through the host,” whereas claim 1 recites the disk connected “through a network switch and a host,” and claim 14 separately recites “a network switch” as an element. It is unclear whether the network switch is in the connection path of the self-encrypting disk in claim 14. This inconsistency renders the scope of claim 14 indefinite.
(g) Claim 5 - mixed statutory class recitation
Claim 5 is a method claim (depending from claim 1) but recites the “automated deployment phase” as “comprising” a series of structural modules (“a CMDB module configured to…,” “a deployment module configured to…”) rather than as a series of steps. It is unclear whether infringement of claim 5 occurs upon assembling the recited modules or upon performing the recited acts. See IPXL Holdings v. Amazon.com, 430 F.3d 1377 (Fed. Cir. 2005). Claims 6-8, which depend from claim 5, are rejected for the same reason.
(h) Claims 2 and 15 - “after, soft rebooting of the host”
Claims 2 and 15 recite “after, soft rebooting of the host, the server management module, removes the configuration…” The stray commas make it unclear whether “soft rebooting” is a step performed after an unrecited event, or whether the removal occurs after the soft reboot recited in claim 1. Correction is required.
10. Claims 2-13 and 15-19 are further rejected under 35 U.S.C. § 112(b) as depending from a rejected base claim and incorporating the deficiencies thereof.
Note regarding claim 20
11. Claim 20 is presented in independent form. The Examiner notes that claim 20 recites a subset of the limitations of claim 1 (it omits the orchestrator module, the server management module, the file transfer module, and the IPMI module as claimed elements, reciting the corresponding acts without attributing them to those modules). Claim 20 is therefore broader than claim 1 and is properly independent. No rejection under 35 U.S.C. § 112(d) is made.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1: Claims 1-12 and 20 recite a method. Claim 13 recites a computer-readable storage medium. Claims 14-19 recite a processing system. Therefore, claims 1-12 and 20 are directed to a process, claim 13 is directed to a manufacture, and claims 14-19 are directed to a machine.
With respect to claims 1, 13, 14 and 20:
2A Prong 1: the claim recites a judicial exception.
• reconfigure the network switch to connect the host of the customer network to the provisioning network; (certain methods of organizing human activity - following rules or instructions)
• loading an unlock disk function by the control plane component; (mental process - evaluation or judgement)
• obtaining a password of the host from the key management module that is stored by the key management system; (mental process - observation or evaluation)
• receiving the password from the server management module; (mental process - observation)
• unlocking the self-encrypting disk using the password, the encryption key associated with the password, and the unlocking disk function; (mental process - evaluation or judgement)
• soft rebooting the host (certain methods of organizing human activity - following rules or instructions)
2A Prong 2: This judicial exception is not integrated into a practical application.
• (claim 1) accessing a computer-readable medium comprising instructions which, upon being operated by at least one processor, causes the execution of software components comprising an orchestrator module configured to orchestrate compute resources of the computing infrastructure; a server management module comprising a control plane component and a management module comprising an agent embedded in an operating system; a key management module comprising a key management system; a file transfer module; and an Intelligent Platform Management Interface (IPMI) module (claim 13) a computer-readable storage medium storing instructions that, upon being executed by a processing system, cause the processing system to perform the method (claim 14) a customer network; a provisioning network; a network switch; a host; a self-encrypting disk (mere instructions to apply an exception - see MPEP 2106.05(f), and does not reflect an improvement to the functioning of a computer or to any other technology - see MPEP 2106.05(a))
• initiate a bare-metal node by connecting the bare-metal node to a provisioning network (insignificant extra-solution activity - see MPEP 2106.05(g), mere data gathering)
• booting the host over the provisioning network by the IPMI module; (insignificant extra-solution activity - see MPEP 2106.05(g), mere data gathering)
• downloading an image of the embedded agent by the file transfer module and executing the downloaded agent image on the host by the management module; (insignificant extra-solution activity - see MPEP 2106.05(g), mere data gathering)
2B: The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception.
• (claim 1) accessing a computer-readable medium comprising instructions which, upon being operated by at least one processor, causes the execution of software components comprising an orchestrator module configured to orchestrate compute resources of the computing infrastructure; a server management module comprising a control plane component and a management module comprising an agent embedded in an operating system; a key management module comprising a key management system; a file transfer module; and an Intelligent Platform Management Interface (IPMI) module (claim 13) a computer-readable storage medium storing instructions that, upon being executed by a processing system, cause the processing system to perform the method (claim 14) a customer network; a provisioning network; a network switch; a host; a self-encrypting disk (mere instructions to apply an exception - see MPEP 2106.05(f))
• initiate a bare-metal node by connecting the bare-metal node to a provisioning network (insignificant extra-solution activity - see MPEP 2106.05(g), mere data gathering, and WURC: receiving or transmitting data over a network - see MPEP 2106.05(d)(II)(i))
• booting the host over the provisioning network by the IPMI module; (insignificant extra-solution activity - see MPEP 2106.05(g), mere data gathering, and WURC: receiving or transmitting data over a network - see MPEP 2106.05(d)(II)(i))
• downloading an image of the embedded agent by the file transfer module and executing the downloaded agent image on the host by the management module; (insignificant extra-solution activity - see MPEP 2106.05(g), mere data gathering, and WURC: receiving or transmitting data over a network - see MPEP 2106.05(d)(II)(i))
With respect to claims 2 and 15:
2A Prong 1: the claim recites a judicial exception.
• prior to soft rebooting of the host, the server management module receives an indication of successful unlocking of the self-encrypting disk; (mental process - observation or evaluation)
• after, soft rebooting of the host, the server management module, removes the configuration of the network switch to connect the host from the provisioning network to the customer network (certain methods of organizing human activity - following rules or instructions)
With respect to claims 3 and 16:
2A Prong 1: the claim recites a judicial exception.
• receiving, by the orchestrator module, a deletion command for the self-encrypting disk, from a customer; (certain methods of organizing human activity - managing interactions between people)
• receiving, by the server management module, a deletion request for the self-encrypting disk, from the orchestrator module; (certain methods of organizing human activity - following rules or instructions)
• sending, by the server management module, a stop command to the host; (certain methods of organizing human activity - following rules or instructions)
• reconfiguring the network switch to connect the host from the customer network to the provisioning network; (certain methods of organizing human activity - following rules or instructions)
• sending a request, by the control plane component, to the agent image to reset the self-encrypting disk to factory settings; (certain methods of organizing human activity - following rules or instructions)
• resetting the self-encrypting disk to factory settings, by the agent image; and encrypting the self-encrypting disk using a new encryption key associated with a password, by the agent image (mental process - evaluation or judgement)
2A Prong 2: This judicial exception is not integrated into a practical application.
• booting the host over the provisioning network via the IPMI module (insignificant extra-solution activity - see MPEP 2106.05(g), mere data gathering)
2B: The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception.
• booting the host over the provisioning network via the IPMI module (insignificant extra-solution activity - see MPEP 2106.05(g), mere data gathering, and WURC: receiving or transmitting data over a network - see MPEP 2106.05(d)(II)(i))
With respect to claim 4:
2A Prong 1: the claim recites a judicial exception.
• wherein the computing infrastructure comprises a plurality of self-encrypting disks that are configured to be unlocked in a predetermined order and, upon loosing electric power, perform automatically locking (mental process - evaluation or judgement)
With respect to claims 5 and 17:
2A Prong 1: the claim recites a judicial exception.
• calculating data for initializing the CMDB module that comprises at least one Internet Protocol (IP) address of the at least one switch; (mental process - evaluation, or mathematical calculations)
• initializing the CMDB module using the calculated data; (mental process - evaluation or judgement)
• configuring the DNS module with configurations from the CMDB module; (certain methods of organizing human activity - following rules or instructions)
• determining, using the CMDB module, configurations for the communication module on the IPMI module and on at least one management network and the at least one switch configured to be provisioned based on the calculated data from the CMDB module; (mental process - evaluation or judgement)
• declaring at least one network in the deployment module; (mental process - evaluation or judgement)
• synchronizing the deployment module with the CMDB module to start a server discovery process by the deployment module using the communication module (mental process - evaluation or judgement)
2A Prong 2: This judicial exception is not integrated into a practical application.
• accessing a computer-readable medium comprising instructions which, upon being operated by a processor, causes the execution of software components comprising a Configuration Management DataBase (CMDB) module configured to manage and store inventory data; a deployment module configured to deploy the computing infrastructure; a communication module configured to enable communications between the CMDB module and the deployment module and manage at least one Dynamic Host Configuration Protocol (DHCP) interface module; a configuration module; a Network Operations Gateway (NOG) module; and a Domain Name System (DNS) module (mere instructions to apply an exception - see MPEP 2106.05(f), and does not reflect an improvement to the functioning of a computer or to any other technology - see MPEP 2106.05(a))
• provisioning at least one network stack with provisioning data from the CMDB module, the provisioning data comprising data relating to network devices, interfaces, networks and the configurations determined by the CMDB module, the provisioning comprising provisioning the DNS module; and provisioning the NOG module; (insignificant extra-solution activity - see MPEP 2106.05(g), mere data gathering)
• booting, via the IPMI module, the at least one un-provisioned server to be discovered by the deployment module (insignificant extra-solution activity - see MPEP 2106.05(g), mere data gathering)
2B: The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception.
• accessing a computer-readable medium comprising instructions which, upon being operated by a processor, causes the execution of software components comprising a Configuration Management DataBase (CMDB) module configured to manage and store inventory data; a deployment module configured to deploy the computing infrastructure; a communication module configured to enable communications between the CMDB module and the deployment module and manage at least one Dynamic Host Configuration Protocol (DHCP) interface module; a configuration module; a Network Operations Gateway (NOG) module; and a Domain Name System (DNS) module (mere instructions to apply an exception - see MPEP 2106.05(f))
• provisioning at least one network stack with provisioning data from the CMDB module, the provisioning data comprising data relating to network devices, interfaces, networks and the configurations determined by the CMDB module, the provisioning comprising provisioning the DNS module; and provisioning the NOG module; (insignificant extra-solution activity - see MPEP 2106.05(g), mere data gathering, and WURC: receiving or transmitting data over a network - see MPEP 2106.05(d)(II)(i))
• booting, via the IPMI module, the at least one un-provisioned server to be discovered by the deployment module (insignificant extra-solution activity - see MPEP 2106.05(g), mere data gathering, and WURC: receiving or transmitting data over a network - see MPEP 2106.05(d)(II)(i))
With respect to claims 6 and 18:
2A Prong 1: the claim recites a judicial exception.
• an Initialization Phase comprising powering off server that is unknown to the deployment module and to the CMDB module; (certain methods of organizing human activity - following rules or instructions)
• configuring network interfaces in a discovery virtual local area network mode (VLAN) by the network virtualisation and orchestration component; (certain methods of organizing human activity - following rules or instructions)
• generating a report comprising results of the analysis and forwarding the report to the deployment module; (mental process - evaluation or judgement)
• synchronizing the deployment module and the CMDB module via the communication device; (mental process - evaluation or judgement)
• an End of Discovery Phase: powering the server off; and unconfiguring the network interfaces from discovery of the virtual local area network mode (VLAN) via the network virtualisation and orchestration component and placing the network interfaces in an isolation quarantine state (certain methods of organizing human activity - following rules or instructions)
2A Prong 2: This judicial exception is not integrated into a practical application.
• wherein the deployment module comprises a network virtualisation and orchestration component configured to create and manage virtual networks, subnets, routers, firewalls, load balancers, and associated networking components within the deployment module (mere instructions to apply an exception - see MPEP 2106.05(f))
• a Discovery Phase comprising powering on server; booting the server through the network; loading the server with at least one agent for analysing the server and the at least one switch; (insignificant extra-solution activity - see MPEP 2106.05(g), mere data gathering)
2B: The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception.
• wherein the deployment module comprises a network virtualisation and orchestration component configured to create and manage virtual networks, subnets, routers, firewalls, load balancers, and associated networking components within the deployment module (mere instructions to apply an exception - see MPEP 2106.05(f))
• a Discovery Phase comprising powering on server; booting the server through the network; loading the server with at least one agent for analysing the server and the at least one switch; (insignificant extra-solution activity - see MPEP 2106.05(g), mere data gathering, and WURC: receiving or transmitting data over a network - see MPEP 2106.05(d)(II)(i))
With respect to claim 7:
2A Prong 1: the claim recites a judicial exception.
• wherein deletion of a server from the deployment module results in deletion of the corresponding entry in the CMDB module and resetting the discovery process (mental process - evaluation or judgement)
With respect to claims 8 and 19:
2A Prong 1: the claim recites a judicial exception.
• presenting the at least one unprovisioned server to the deployment module as a computing resource using the server management module; (mental process - evaluation or judgement)
• integrating self-encrypting drives into the server management module; and (certain methods of organizing human activity - following rules or instructions)
• assigning unique encryption keys to each host and/or disk and/or client of the computing infrastructure and managing the assigned unique encryption keys by the key management module (mental process - evaluation or judgement)
2A Prong 2: This judicial exception is not integrated into a practical application.
• discovering at least one unprovisioned server using the server management module; (insignificant extra-solution activity - see MPEP 2106.05(g), mere data gathering)
2B: The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception.
• discovering at least one unprovisioned server using the server management module; (insignificant extra-solution activity - see MPEP 2106.05(g), mere data gathering, and WURC: receiving or transmitting data over a network - see MPEP 2106.05(d)(II)(i))
With respect to claims 9 and 10:
2A Prong 1: the claim recites a judicial exception.
• generating unique signatures for operating system images; (mental process - evaluation or judgement)
• validating that only signed operating system images are loaded during the booting of the at least one server by a deployment module by executing an integrated mechanism into the server management module (mental process - evaluation or judgement)
• (claim 10) wherein the integrated mechanism is configured to manage signatures and versions of associated data (mental process - evaluation or judgement)
2A Prong 2: This judicial exception is not integrated into a practical application.
• storing the unique signatures in a key management module; (insignificant extra-solution activity - see MPEP 2106.05(g), mere data gathering)
2B: The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception.
• storing the unique signatures in a key management module; (insignificant extra-solution activity - see MPEP 2106.05(g), mere data gathering, and WURC: storing and retrieving information in memory - see MPEP 2106.05(d)(II)(iii))
With respect to claims 11 and 12:
2A Prong 1: the claim recites a judicial exception.
• further comprising providing features taken from among at least one of the operations: logging, monitoring, auditing, and security (certain methods of organizing human activity - following rules or instructions)
2A Prong 2: This judicial exception is not integrated into a practical application.
• (claim 12) wherein the computing infrastructure comprises a private network for server discovery (generally linking the use of the judicial exception to a particular technological environment or field of use - see MPEP 2106.05(h))
2B: The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception.
• (claim 12) wherein the computing infrastructure comprises a private network for server discovery (generally linking the use of the judicial exception to a particular technological environment or field of use - see MPEP 2106.05(h))
Therefore, claims 1-20 are not patent eligible.
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 t which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 11-16, 20 are rejected under AIA 35 U.S.C. § 103 as being unpatentable over Vincent et al. (“Vincent”) (US No. 8,774,213) in view of Chen et al. (“Chen”) (US No. 10,069,625).
In order to expedite and avoid piecemeal prosecution, the following rejection is made to the extent that the claims are understood, by considering those elements which are understood and interpreting their function in a manner which is consistent with the recited goals of the claims, and then applying the best available art.
The examiner relies on the entire teachings of Vincent and Chen references; the applicant should carefully consider the entire teachings of the above-mentioned references to better understand the examiner’s position.
In regard to claim 1, Vincent teaches a computer-implemented method for managing a computing infrastructure comprising a self-encrypting disk (as shown in Fig. 3, which is reproduced below for ease of reference and convenience, Vincent discloses a method of managing a cloud computing infrastructure of host devices 302 arranged in racks 308, each host connected through at least one network switch 306 to authorized customer networks 328. (Vincent, FIG. 3; description of FIG. 3: host devices 302, network ports 304, network switch 306, rack of servers 308, authorized customer networks 328. Vincent discloses that each server includes an operating system providing executable program instructions and “a computer-readable medium storing instructions that, when executed by a processor of the server, enable the server to perform its intended functions.” (Vincent, description of FIG. 1.) Chen likewise discloses processor 404 executing instructions stored in system memory 416. (Chen, FIG. 4))
PNG
media_image1.png
886
607
media_image1.png
Greyscale
comprising: an orchestrator module configured to orchestrate compute resources of the computing infrastructure (in Vincent, discloses a cloud manager database and system 330 that instructs the provisioning systems 326, console network 316, and rack components to perform actions, and a control plane 208 including resource allocation managers 210 “responsible for tasks such as validating the user or client associated with the request and obtaining or allocating access to the appropriate resource(s).” (Vincent, FIG. 3: cloud manager 330; FIG. 2: control plane 208, resource allocation manager 210);
a server management module comprising: (in Vincent, discloses a control plane 208 that manages provisioning and access to resources, and provisioning systems 326 that receive provisioning images containing provisioning code. (Vincent, FIG. 2; FIG. 3));
a management module comprising in Vincent, discloses booting the machine into a RAM disk over the network, wherein “A RAM disk with specialized drivers in one embodiment can be used to boot and/or run an untrusted or unknown image,” i.e., an executable agent image running in an operating environment on the host that carries out provisioning operations under direction of the provisioning/control systems. (Vincent, description of FIG. 3));
a key management module comprising a key management system for storing passwords associated with encryption keys for encrypting the self-encrypting disks;
a file transfer module configured to manage the transfer of files (in Vincent, discloses that “Provisioning images thus can be received, over the network to the PXE, which contain provisioning code or firmware flashing code,” transferred from the provisioning systems 326 to the host. (Vincent, description of FIG. 3: provisioning systems 326, PXE); and
wherein, upon the server management module receiving a request from the orchestrator module, the method causes: the server management module to initiate a bare-metal node by connecting the bare-metal node to a provisioning network and reconfigure the network switch to connect the host of the customer network to the provisioning network (in Vincent, expressly discloses this switching operation: “When the switch 306 is configured to connect a host machine 302 to the provisioning systems, the PXE can connect the device to the provisioning systems and boot the machine…” and “The provisioning and control systems can control the switch in real time with no humans involved, as the automatic switching of that path can be based on provisioning events and external coordination.” The coordination “can be provided and/or managed by an external system, such as a cloud manager database and system 330… which can instruct the provisioning system(s) 326, console network 316, and rack components to perform certain actions.” (Vincent, description of FIG. 3: switch 306, host machine 302, provisioning systems 326, cloud manager 330). Vincent further discloses that the host machines 302 are provided to customers with “native or ‘bare metal’ access to the resource,” i.e., a bare-metal node. (Vincent, description of FIG. 2));
booting the host over the provisioning network by the IPMI module (in Vincent, discloses that “power can be cycled using the console and when the machine boots the PXE code can execute on the network port,” and that the hosts “can be powered on and off by running a line to the console controller from the rack PDU with relays or other such components to power cycle each device.” (Vincent, description of FIG. 3: console controller 314, rack PDU 320, PXE));
downloading an image of the embedded agent by the file transfer module and executing the downloaded agent image on the host by the management module (in Vincent discloses that upon PXE boot the host is booted “into a RAM (random access memory) disk or other block of storage… which enables control operations such as firmware flashing or provisioning of a new customer image,” and that “Provisioning images thus can be received, over the network to the PXE, which contain provisioning code or firmware flashing code.” The received image is then executed on the host to perform the control operations. (Vincent, description of FIG. 3));
(in Vincent, discloses that “power can be cycled using the console and when the machine boots the PXE code can execute on the network port,” and that the hosts “can be powered on and off by running a line to the console controller from the rack PDU with relays or other such components to power cycle each device.” (Vincent, description of FIG. 3: console controller 314, rack PDU 320, PXE));
soft rebooting the host (in Vincent, discloses that after provisioning is completed the machine is returned to customer service, and describes rebooting of the physical system in connection with provisioning operations and reboots that are “allowed from local images on the host for customer initiated reboots.” (Vincent, description of FIG. 3)). Vincent does not expressly teach a self-encrypting disk connected to a customer network through a network switch and a host; the control plane component integrates encryption and decryption functions; the agent performs encryption and decryption tasks on self-encrypting disks; a key management module storing passwords for self-encrypting disks; out-of-band management interface as IPMI; loading an unlock disk function; obtaining a password from a key management system; receiving the password from the server management module; unlocking the self-encrypting disk using the password, the encryption key associated with the password, and the unlocking disk function. In the same field of endeavor, Chen expressly discloses a self-encrypting disk connected to a customer network through a network switch and a host (as shown in Fig. 3, which is reproduced below for ease of reference and convenience, Chen discloses the self-encrypting disk connected to and managed within a rack-mounted server: “server 102 can include one or more self-encrypting drive such as self-encrypting drive 106… Server 102 and 104 can transmit data via layers of switch fabrics that are built into the rack's architecture.” (Chen, FIG. 1A; col. describing FIG. 1A);
the control plane component integrates encryption and decryption functions (in Chen, supplies a service controller (BMC 204) that executes a key management program to request, receive and transmit authentication keys, and a storage controller 210 that performs the encryption/decryption-enabling unlock. (Chen, FIG. 2 — BMC 204, storage controller 210.);
PNG
media_image2.png
499
488
media_image2.png
Greyscale
the agent performs encryption and decryption tasks on self-encrypting disks (in Chen, supplies the encryption/decryption task performance: storage controller 210 receives the authentication key and “can create a hash of the received authentication key and compare it with the stored hash of the key. If the two keys or passwords match, the self-encrypting drive is unlocked,” and “the matched authentication key can also decrypt the data encryption key, which can be used to encrypt and decrypt the user data.” (Chen, FIG. 2; FIG. 3 step 312));
a key management module storing passwords for self-encrypting disks (in Chen, supplies key management server 216, “an external key server that is configured to generate and manage encryption keys 218 using… key manager 220,” which “can also be configured to store encryption keys 218 in a storage medium such as a hard disk,” wherein “Encryption keys 218 can include authentication keys and data encryption keys” and the authentication key is compared against “a pre-configured password of self-encrypting drive 106.” (Chen, FIG. 2: key management server 216, encryption keys 218, key manager 220; FIG. 1A));
out-of-band management interface as IPMI (in Chen, supplies the express IPMI identification: “BMC 204 can communicate with processor 206 or self-encrypting controller 210 via Intelligent Platform Management Interface (IPMI) messages,” and “A BMC is an independent and embedded microcontroller that… is responsible for the management and monitoring of the main central processing unit and peripheral devices on the motherboard.” (Chen, FIG. 2: BMC 204; Summary));
booting the host over the provisioning network by the IPMI module (in Chen supplies the IPMI attribution for the boot-time key operation: “Upon each booting process of server 102, the service controller can send a key request to key management server 108.” (Chen, description of FIG. 1A));
loading an unlock disk function (in Chen supplies this: during the initiation process BMC 204 “can execute a key management program… to request, receive and transmit the authentication keys for self-encrypting drive 212 and 214,” and transmits the key “to storage controller 210 for either unlocking a locked self-encrypting drive 212 or configuring an unlocked self-encrypting drive 212.” (Chen, FIG. 2; FIG. 3 steps 302-312));
obtaining a password from a key management module that is stored by the key management system (in Vincent does not teach obtaining a password from a key management system. Chen supplies this: “BMC 204 can transmit the key request to key management server 216, using the IP address of key management server 216,” and “If an authentication key has been previously created and stored for self-encrypting drive 212, key manager 220 can retrieve the corresponding encryption key and send it to BMC 204 in a key response.” Chen expressly equates the authentication key with a password: the storage controller compares the received key hash “with the stored hash of the key. If the two keys or passwords match, the self-encrypting drive is unlocked.” (Chen, FIG. 2; FIG. 3 steps 306-310));
receiving the password from the server management module (in Chen supplies it: “At step 312, the service controller can transmit the security key to the self-encrypting drive controller,” which receives it. (Chen, FIG. 3 step 312.)
unlocking the self-encrypting disk using the password, the encryption key associated with the password, and the unlocking disk function (in Chen supplies it: “After receiving the authentication key from BMC 204, storage controller 210 can create a hash of the received authentication key and compare it with the stored hash of the key. If the two keys or passwords match, the self-encrypting drive is unlocked and can read/write like an unencrypted hard disk. Further, the matched authentication key can also decrypt the data encryption key.” (Chen, FIG. 2; FIG. 3 step 312));
soft rebooting the host (in Chen further discloses that after the drive is unlocked, “processor 206 can execute BIOS 208 for a second time to start from the actual self-encrypting drive (e.g., self-encrypting drive 212) and self-encrypting drive 212 can be accessed like a regular disk” i.e., a second boot of the host following unlock, without power cycling. (Chen, description of FIG. 2)).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the bare-metal provisioning architecture of Vincent in which a network switch is automatically reconfigured to move a host between a customer network and a provisioning network so that a provisioning agent image may be network-booted and executed on the host to incorporate the self-encrypting drive and centralized key-management-server unlock mechanism of Chen, such that the provisioning agent obtains the drive password from the key management server and unlocks the self-encrypting drive before the host is returned to the customer network. A person of ordinary skill applying Chen's automated unlock to Vincent's multi-tenant rack-scale infrastructure would therefore have been motivated by Chen's own stated purpose: eliminating manual credential entry at each host in a data centre containing many drives. Vincent independently supplies the motivation of avoiding human involvement, teaching that “The provisioning and control systems can control the switch in real time with no humans involved.”
In regard to claim 2, Chen teaches wherein: prior to soft rebooting of the host, the server management module receives an indication of successful unlocking of the self-encrypting disk; and after, soft rebooting of the host, the server management module, removes the configuration of the network switch to connect the host from the provisioning network to the customer network (in Chen teaches that the service controller receives status confirming the outcome of the key/unlock process: “BMC 204 can generate a third status message to storage controller 210 indicating the key is ready,” and BMC 204 generates status messages “reporting a status of the key generation or retrieval process.” Vincent teaches the return step: “Once provisioning is completed, authorized customer networks 328 can interact with the devices 302 via the switch 306,” i.e., the switch configuration is removed so the host is reconnected from the provisioning path to the customer network). It would have been obvious to confirm successful unlock before returning the host to the customer network, in order to avoid handing a customer a host whose data disk is still locked.
In regard to claim 3, Vincent teaches further implementing a recycling phase comprising: receiving, by the orchestrator module, a deletion command for the self-encrypting disk, from a customer; receiving, by the server management module, a deletion request for the self-encrypting disk, from the orchestrator module; sending, by the server management module, a stop command to the host; reconfiguring the network switch to connect the host from the customer network to the provisioning network; booting the host over the provisioning network via the IPMI module; sending a request, by the control plane component, to the agent image to reset the self-encrypting disk to factory settings; resetting the self-encrypting disk to factory settings, by the agent image; and encrypting the self-encrypting disk using a new encryption key associated with a password, by the agent image (in Vincent discloses that a customer may be given a resource “for any desired period of time, such as a matter of hours or even minutes,” after which the resource must be returned to a known state: a subsequent user cannot utilize the resource “without first re-imaging or otherwise verifying the state of the resource,” and the provisioning systems boot the machine into a RAM disk “which enables control operations such as firmware flashing or provisioning of a new customer image,” with the switch 306 reconfigured to connect the host to the provisioning systems. Vincent's cloud manager 330 instructs the provisioning systems and rack components to perform these actions, i.e., the deletion/stop and reconfiguration commands). Vincent does not teach resetting a self-encrypting disk to factory settings and re-encrypting it with a new key. Chen supplies the cryptographic-erase mechanism: “erasing the data encryption key can render all encrypted data unreadable, thus providing a complete and irreversible deletion of the encrypted data,” and further teaches configuring an unlocked drive with a newly received authentication key such that “self-encrypting drive 212 can lock itself at the next shut-down” and “When self-encrypting drive 212 is powered on again, it will remain locked until a correct authentication key is provided”. It would have been obvious to perform Chen's key regeneration during Vincent's inter-customer reclamation, for the predictable result of rendering the prior tenant's data permanently unreadable before the host is reissued which is precisely the residual-state concern Vincent raises.
In regard to claim 4, Chen teaches wherein the computing infrastructure comprises a plurality of self-encrypting disks that are configured to be unlocked in a predetermined order and, upon loosing electric power, perform automatically locking (in Chen teaches the auto-lock-on-power-loss limitation: storage controller 210 configures the drive with the received authentication key “so that self-encrypting drive 212 can lock itself at the next shut-down. When self-encrypting drive 212 is powered on again, it will remain locked until a correct authentication key is provided.” Chen further teaches a plurality of self-encrypting drives on a single server (self-encrypting drive 212 and self-encrypting drive 214) that are unlocked in sequence, the service controller handling each drive's key request in turn by its unique identifier). Performing a sequential set of unlock operations in a determinate order is the ordinary result of iterating over an enumerated list of drives, and would have been obvious to one of ordinary skill.
In regard to claim 11, Vincent teaches further: providing features taken from among at least one of the operations: logging, monitoring, auditing, and security (in Vincent discloses “at least one monitoring component 214” in the control plane 208, wherein “information for the resource can be written to a data store accessible to the control plane, such as a monitoring data store 216,” and that “A monitoring component can constantly monitor the usage of each resource by a user, client, etc.” Chen discloses that “system memory 416 includes a log manager, a log buffer, or a log repository”).
In regard to claim 12, Vincent teaches wherein the computing infrastructure comprises a private network for server discovery (in Vincent discloses a dedicated “console network 316” that is separate from the production network and used for out-of-band management, and separate provisioning systems 326 reached through router 324, wherein “network traffic within a rack is aggregated in order to minimize the number of cables leaving each rack.” This is a private management network not exposed to the customer).
In regard to claim 13, Vincent teaches a computer-readable storage medium storing instructions that, upon being executed by a processing system, cause the processing system to perform the method according to claim 1 (in Vincent discloses “a computer-readable medium storing instructions that, when executed by a processor of the server, enable the server to perform its intended functions,” and Chen discloses system memory 416 storing executable instructions and enumerates non-transitory computer readable media). Claim 13 is therefore rejected for the reasons given for claim 1.
Independent claim 14 (system) recites the same operative limitations as method claim 1 in method form. Vincent discloses the physical arrangement in FIG. 3 (host devices 302, network ports 304, switch 306, rack 308, console port 312, console controller 314, console network 316, PSU 318, rack PDU 320, data center PDU 322, router 324, provisioning systems 326, customer networks 328, cloud manager 330), and Chen discloses the server-side arrangement in FIG. 2 (server 202, BMC 204, processor 206, BIOS 208, storage controller 210, self-encrypting drives 212 and 214, key management server 216, encryption keys 218, key manager 220, server management device 222). The method/system/medium distinction does not impart patentability where the underlying operative steps are the same. See MPEP § 2114. Therefore, claim 14 is rejected on the same basis and mapping as claim 1 above.
Claims 15 and 16 correspond to claims 2 and 3 respectively and are rejected for the reasons given for those claims.
Claim 20 recites the method of claim 1 with the recited acts stated without attribution to the named modules. It is therefore broader than claim 1 and is rejected for the reasons given for claim 1.
6. Claims 5-8 and 17-19 are rejected under 35 U.S.C. § 103 as being unpatentable over Vincent in view of Chen and further in view of Abali et al., (“Abali”) (US 10,834,178).
The examiner relies on the entire teachings of Vincent and Chen and Abali references; the applicant should carefully consider the entire teachings of the above-mentioned references to better understand the examiner’s position.
In regard to claims 5 and 17, Vincent in view of Chen teaches the method of claim 1 and the system of claim 14. Vincent further teaches maintaining a central inventory record of infrastructure state that the “cloud manager database and system 330” which coordinates the provisioning systems, console network, and rack components, and the monitoring data store 216 and administrative data store to which “information for the resource can be written.” Vincent teaches provisioning the network stack, including router 324 connecting host devices to provisioning systems 326 and the switch 306 whose configuration is pushed automatically. The recitation of DHCP, DNS, and switch-configuration modules recites only the ordinary and expected constituents of any provisioned data-center network stack. Vincent already teaches PXE network boot, which necessarily requires DHCP address assignment and a network boot server, and Vincent teaches allocating “an IP address (derived from DNS mappings)” to resources. Naming these long-conventional network services as discrete “modules” does not distinguish the claim over the prior art. Vincent and Chen do not expressly teach the named CMDB module, deployment module, communication module managing a DHCP interface module, configuration module, Network Operations Gateway (NOG) module, and DNS module, nor the step of calculating an IP address of the switch for CMDB initialization. In the same field of endeavor, Sharma teaches the CMDB module, deployment module, communication module managing a DHCP interface module, configuration module, Network Operations Gateway (NOG) module, and DNS module, nor the step of calculating an IP address of the switch for CMDB initialization (as shown in Fig. 3, which is reproduced below for ease of reference and convenience, Sharma supplies the automated bare-metal deployment framework in which an inventory of physical bare-metal servers and network equipment is maintained and consulted to identify, enable, disable, and configure those physical resources in response to a provisioning request, and in which the network configuration is applied automatically — classified expressly in H04L 41/08, configuration management of networks or network elements. (Sharma, description of the bare-metal server provisioning workload 1296, customer portal 260, secure management tool 250).
PNG
media_image3.png
897
689
media_image3.png
Greyscale
It would have been obvious to a person of ordinary skill in the art before the effective filing date to implement the infrastructure-state database of Vincent's cloud manager 330 as the structured configuration-management database and automated deployment framework of Sharma, and to derive the network addresses of the managed switches from that database. Rationale: use of a known technique (structured configuration management databases with automated network provisioning, as in Sharma) to improve a similar device or method (Vincent's cloud manager coordination of provisioning and switch reconfiguration) in the same way. MPEP § 2143(C) and (D).
In regard to claims 6 and 18, Vincent teaches wherein the deployment module comprises a network virtualisation and orchestration component configured to create and manage virtual networks, subnets, routers, firewalls, load balancers, and associated networking components within the deployment module, such that the server discovery process further comprises: an Initialization Phase comprising: powering off server that is unknown to the deployment module and to the CMDB module; and configuring network interfaces in a discovery virtual local area network mode (VLAN) by the network virtualisation and orchestration component; a Discovery Phase comprising: powering on server; booting the server through the network; loading the server with at least one agent for analysing the server and the at least one switch; generating a report comprising results of the analysis and forwarding the report to the deployment module; synchronizing the deployment module and the CMDB module via the communication device; an End of Discovery Phase: powering the server off; and unconfiguring the network interfaces from discovery of the virtual local area network mode (VLAN) via the network virtualisation and orchestration component and placing the network interfaces in an isolation quarantine state (in Vincent teaches the isolation-by-switching principle that underlies the recited phases: the host is powered off and powered on under control of the console controller 314 and rack PDU 320; the switch 306 places the host on the provisioning path where it is not reachable by customer networks; the host network-boots and runs an agent image; and “Once provisioning is completed, authorized customer networks 328 can interact with the devices 302 via the switch 306,” i.e., the host leaves the isolated state. Vincent further teaches that “the offload device can enforce specific VLAN (virtual local area network) tags or otherwise add VLAN tags,” and that segregation “can happen at a higher level in the network than the first tier of switches”. The additional recitation that the agent analyses the server and switch hardware and generates a report forwarded to the deployment module is taught in substance by Vincent's RAM-disk agent performing control operations and by the cloud manager's monitoring data store to which resource information is written. Sharma further teaches identifying and configuring physical bare-metal server resources from a maintained inventory). It would have been obvious to place a newly discovered, not-yet-trusted server in an isolated VLAN during hardware inventory and to quarantine it afterward, for the predictable and expressly recognized benefit of preventing an unidentified device from reaching the production network.
In regard to claim 7, Sharma teaches wherein deletion of a server from the deployment module results in deletion of the corresponding entry in the CMDB module and resetting the discovery process (in Sharma, teaches maintaining referential consistency between a deployment record and an inventory record when a record is deleted is the ordinary and expected behaviour of a configuration management database, and is taught in substance by Sharma's maintained inventory of enabled and disabled physical resources. It would have been obvious to a person of ordinary skill in the art before the effective filing date to implement the infrastructure-state database of Vincent's cloud manager 330 as the structured configuration-management database and automated deployment framework of Sharma, and to derive the network addresses of the managed switches from that database. Rationale: use of a known technique (structured configuration management databases with automated network provisioning, as in Sharma) to improve a similar device or method (Vincent's cloud manager coordination of provisioning and switch reconfiguration) in the same way. MPEP § 2143(C) and (D).
In regard to claim 8, Chen teaches further: managing resources of the computing infrastructure, comprising: discovering at least one unprovisioned server using the server management module; presenting the at least one unprovisioned server to the deployment module as a computing resource using the server management module; integrating self-encrypting drives into the server management module; and assigning unique encryption keys to each host and/or disk and/or client of the computing infrastructure and managing the assigned unique encryption keys by the key management module (in Chen expressly teaches per-drive unique keys, wherein “Each self-encrypting drive can be associated with a unique identifier, such as a globally unique identifier (GUID) or a universally unique identifier (UUID),” and the key management server creates and stores an authentication key “based on the unique identifier” of each drive).
In regard to claim 19, Chen teaches further: managing resources of the computing infrastructure, configured to: discover at least one unprovisioned server using the server management module; present the at least one unprovisioned server to the deployment module as a computing resource using the server management module; integrate self-encrypting drives into the server management module; and assign unique encryption keys to each host and/or disk and/or client of the computing infrastructure and managing the assigned unique encryption keys by the key management module (in Chen expressly teaches per-drive unique keys, wherein “Each self-encrypting drive can be associated with a unique identifier, such as a globally unique identifier (GUID) or a universally unique identifier (UUID),” and the key management server creates and stores an authentication key “based on the unique identifier” of each drive).
Examiner's note:
Examiner has cited particular columns and line numbers in the references applied to the claims above for the convenience of the Applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the Applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passages as taught by the prior art or disclosed by the Examiner.
Allowable Subject Matter
7. Claims 9-10 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 112, 2nd paragraph, set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
8. The following is an Examiner's statement of reasons for the indication of allowable subject matter:
Claim 9 requires generating unique signatures for operating system images, storing those unique signatures in the key management module, and validating that only signed operating system images are loaded during booting of the server by the deployment module by executing an integrated mechanism into the server management module. The prior art of record does not teach or suggest storing operating-system-image signatures in the same key management module that holds the self-encrypting-disk passwords, nor validating image signatures by a mechanism integrated into the server management module that performs the bare-metal provisioning.
Chen's key management server 216 stores only authentication keys and data encryption keys for self-encrypting drives; Chen contains no disclosure of image signatures or of signature validation at boot. Vincent teaches booting “an untrusted or unknown image” on a RAM disk and expressly identifies the risk that a customer may flash malicious firmware, but Vincent's proposed responses are re-imaging and state verification, Vincent does not teach signing images or validating signatures before load. Vincent's discussion of a Trusted Platform Module and Static/Dynamic Root of Trust is presented as background context describing existing measures, not as a teaching of storing image signatures in a provisioning key manager. Sharma is directed to inventory-driven configuration of physical resources and does not address image signing.
The Examiner's search did not locate a reference teaching the specific architectural relationship recited a single key management module serving both the SED password function and the OS image signature function, with validation integrated into the bare-metal server management module in combination with the remaining limitations of claim 1.
Claim 10, which further requires that the integrated mechanism manage signatures and versions of associated data, is allowable for the same reasons.
Applicant is advised that this indication is based on the prior art of record and the search described below. It does not constitute an indication that claims 9 and 10 are allowable under 35 U.S.C. § 101, which rejection stands against all pending claims and must be separately overcome.
Conclusion
9. All claims are rejected.
10. The prior arts made of record and not relied upon are considered pertinent to applicant's disclosure.
Lyakhovitskiy et al., U.S. Patent No. 8,856,553 teach provisioning a self-encrypting drive with locking ranges, authority objects, and locking range objects, and a boot manager including a key manager that uses key information from a data store to unlock a volume and boot the operating system. Relevant to the disk-provisioning and unlock-at-boot limitations.
Allo et al., U.S. Patent No. 11,120,151, teach a UEFI BIOS that establishes a secure connection to a KMIP server, requests an encrypted key for a registered drive or band by its unique stored identifier, receives the key, and unlocks the registered drives during boot, iterating over multiple registered drives. Highly relevant to the plural-disk sequential unlock of claim 4.
Allo et al., U.S. Patent No. 10,382,201, teach OS-driven KMIP key retrieval and drive unlock, including a lock-on-power-cycle (LOPC) setting.
Allo et al., U.S. Patent No. 10,678,953, teach a drive information table, TPM-gated access to stored SED credentials, and unlocking all registered drives during the boot process.
Allo et al., U.S. Patent No. 10,460,110,) - relevant to local key management system architecture for SED unlock.
Ponnusamy et al., U.S. Patent No. 11,196,549, teach a remote access controller retrieving a locking key for a locked managed device from a key management server system over an out-of-band network during boot of the managed server, with BIOS fallback when the controller is unavailable. Directly relevant to the IPMI/BMC-mediated key retrieval of claim 1.
Koning et al., U.S. Pub No. 2015/0052369, teach distributing an SED access key across multiple drives in an array using a secret sharing scheme so the array self-unlocks.
Kumar et al., U.S. Patent No. 10,609,006, - Relevant to key management application architecture.
11. Any inquiry concerning this communication or earlier communications from the examiner should be directed to examiner Raymond Phan, whose telephone number is (571) 272-3630. The examiner can normally be reached on Monday-Friday from 6:30AM- 3:00PM. The Group Fax No. (571) 273-8300.
Communications via Internet e-mail regarding this application, other than those under 35 U.S.C. 132 or which otherwise require a signature, may be used by the applicant and should be addressed to [raymond.phan@uspto.gov].
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, Andrew Jung can be reached at (571) 270-3779. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
All Internet e-mail communications will be made of record in the application file. PTO employees do not engage in Internet communications where there exists a possibility that sensitive information could be identified or exchanged unless the record includes a properly signed express waiver of the confidentiality requirements of 35 U.S.C. 122. This is more clearly set forth in the Interim Internet Usage Policy published in the Official Gazette of the Patent and Trademark on February 25, 1997 at 1195 OG 89.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see hop://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Any inquiry of a general nature or relating to the status of this application should be directed to the TC 2100 central telephone number is (571) 272-2100.
/RAYMOND N PHAN/
Primary Examiner, Art Unit 2175
Prosecution Insights