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 .
Response to Arguments
Applicant's arguments filed 10/24/2025 have been fully considered but they are not persuasive.
Applicant argues Alewine et al. (US Pat. No. 9,626,166 B1) fails to disclose applying an encryption setting to the already generated virtual machine (VM) by "copying, to a memory included in the host computer apparatus, an initial file system loaded to the physical storage corresponding to the virtual machine to load a root file system to the physical storage such that an initial setting of the physical storage associated with the initial file system is backed up, loading an actual file system of the virtual machine to the physical storage, initializing the physical storage and applying the encryption setting to the physical storage to encrypt data of the physical storage" and restarting the hooked booting process for booting the generated virtual machine". However, Alewine teaches encrypting an appliance image (mapped to the virtual machine image) through a process similar to that as claimed in the present invention. The claim as drafted recites “applying the encryption setting to the generated virtual machine by performing the following steps”. It should be noted, “applying an encryption setting” is not the same as claiming “encrypting the virtual machine” itself, as the VM is simply a software that emulates a physical machine for running system image. Instead, as claimed, “applying an encryption setting” is a process limited to the recited steps of copying, initializing and restarting, which are all taught by Alewine, thus Alewine teaches the limitation.
Applicant argues the prior art fails to disclose “initializing the physical storage and applying the encryption setting to the physical storage to encrypt data of the physical storage. Alewine teaches “Fig. 4 #426, [Col. 5 ln. 60-67] Initial ram disk. The host container system may execute the program /init from the mounted initial ram disk. The /init script changes root to the encrypted partition and executes the programs within the encrypted partition that comprise the appliance runtime. [Col 3 lines 45-62][Col 4 lines 7-18]”. Alewine teaches initialize the storage and encrypt data of the storage. Alewine teaches applying the encryption setting for the contingency, as Alewine teaches applying the encryption setting when it has not already been applied.
Applicant argues that Alewine fails to teach “copying, to a memory included in the host computer apparatus, an initial file system loaded to the physical storage corresponding to the virtual machine to load a root file system to the physical storage such that an initial setting of the physical storage associated with the initial file system is backed up,". However, this is taught by Tan. Please see the 35 USC 103 rejection.
Applicant argues that Alewine fails to teach "loading an actual file system of the virtual machine to the physical storage”. However, this is taught by Feng. Please see the 35 USC 103 rejection.
Applicant argues that Alewine also fails to disclose "restarting the hooked booting process for booting the generated virtual machine" after applying the encryption setting.
The Examiner does not concede. Joshi teaches “restarting the booting process for booting the generated virtual machine”. Joshi discloses “Activating and deactivating the encryption feature may require restarting or rebooting the storage device server and/or the drive [0003]”. Furthermore, there is no applying the encryption setting to the restarting the hooked booting process for booting the generated virtual machine nor an encrypted data of the physical storage being done at the restart.
Claim Interpretation
Re. claim 1, the claim recites “if the encryption setting is not applied to the generated virtual machine, then applying the encryption setting to the generated virtual machine”. These are contingent limitation since the broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed and does not include steps that are not required to be performed because the condition (i.e., “if”) precedent are not met. Please see MPEP §2111.04.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1, 3-7, 9-10 and 12-14 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Re. claims 1, 9 and 10; the claims recite “copying, to a memory included in the host computer apparatus, an initial file system loaded to the physical storage corresponding to the virtual machine to load a root file system to the physical storage such that an initial setting of the physical storage associated with the initial file system is backed up”. The specification does not have support of copying an initial file system loaded to the physical storage corresponding to the virtual machine to lead a root file system to the physical storage such that an initial setting of the physical storage associated with the initial file system is backed up. According to the specification in paragraph 76 discloses “A root file system loading 640 may be an example of a process in which the computer apparatus 200 loads a root file system for the virtual machine 340. Here, if the virtual machine 340 requires encryption application, the computer apparatus 200 may execute process O or @ of FIG. 6”. The specification just states mounting the root file system, the specification does not mention copying an initial file system loaded to the physical storage corresponding to the virtual machine to load a root file system to the physical storage.
Re. claims 1, 9 and 10; the claims recite “loading an actual file system of the virtual machine to the physical storage”. In paragraph [0063] of the specifciaon recites “n operation 440, the computer apparatus 200 may copy, to the memory 210, an initial file system that is temporarily loaded to the physical storage 350 before loading an actual file system of the virtual machine, based on the encryption setting operation. The actual file system is a file system of the virtual machine 340, and the term "actual" is used to distinguish the actual file system from the initial file system. That is, the computer apparatus 200 may back up initially set data of the physical storage 350 that requires deletion of existing data in response to the application of the encryption setting”. The specification only discloses loading an actual file system of the virtual machine and not loading an actual file system of the virtual machine to the physical storage. Therefore there is no support for loading an actual file system of the virtual machine to the physical storage
Claims 3-7 and 12-14 fall together accordingly as they do not cure the deficiencies of the independent claims.
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, 3-7, 9-10 and 12-14 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claims 1, 9 and 10, the phrase "such that" renders the claim indefinite because it is unclear whether the limitations following the phrase are part of the claimed invention. See MPEP § 2173.05(d).
Claims 3-7 and 12-14 fall together accordingly as they do not cure the deficiencies of the independent claims.
Claim Rejections - 35 USC § 103
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.
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.
Claim(s) 1, 5-6, 9-10, and 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over Feng (US 2018/0295105 A1) in view of Joshi et al. (US 2021/0200881 A1) in view of Alewine et al. (US Pat. No. 9,626,166 B1) and in further view of Tan et la. (US 2018/0060180 A1), hereinafter Feng, Joshi, Alewine and Tan.
Regarding claim 1, Feng disclose An encryption setting application method in a cloud environment including a host computer apparatus and physical storage, the method executed by at least one processor of the host computer apparatus, and comprising: (Feng, [0053] “The host client program may create a cryptographic storage volume using local or remote storage (or a portion thereof) accessible to a host computer, e.g., a physical disk drive, a logical partition, a volume, or cloud storage.”)
acquiring a virtual machine image including a script that describes a hooking operation of a booting process for booting a virtual machine (Feng, [0050] “system initialization script”) and an encryption setting operation for the virtual machine; (Feng, [0122] “LINUX Unified Key Setup (LUKS)”)
hooking the booting process based on the hooking operation after booting of the virtual machine starts; (Feng, [0049] “After being powered on, the gadget can load the LINUX OS from its non-transitory memory storage medium device 130 and execute system initialization scripts to create (504) a virtual drive (e.g., a virtual CD drive).”; [00114] “On the encryption server side, after being powered on (1950), the server may boot a Linux operating system the non-volatile storage device 1708 into the RAM 1706, to be executed by the CPU 1702.”)
applying an encryption setting to the generated virtual machine based on the encryption setting operation (Feng, [0123]-[0124] “The following example programming instructions can set up the LUKS device header on the NBD block device and encrypt the master-key with the default cryptographic options (e.g., a default encryption algorithm): # cryptsetup -y luksFormat /dev/nbd0.”)
verifying whether the encryption setting is applied to the generated virtual machine, (Feng, [0122] “With the NBD server/client connection operational, the encryption server program first receives the target crypto device name from the encryption client in step 5070 and proceeds in step 5080 to read the first 2 sectors of the target crypto device. The 2 sectors shall contain a Linux Unified Key Setup (LUKS) header if the target device is already a cryptographic volume. LUKS specifies a platform-independent standard on-disk format for disk encryption. The LUKS presence indication is subsequently sent by the encryption server program to the encryption client program in step 5090.”)
loading an actual file system of the virtual machine to the physical storage (Feng, [0051] “The “modprobe” command can load the LINUX kernel g_multi module and instantiate the USB Multifunction Composite Gadget with one of its mass storage devices being the virtual CD drive. The virtual CD drive is backed up in the “vcd_file” file, which is stored in the gadget's RAM”, [0079] “method for encrypting data. A host writes (430) (e.g., using a SCSI WRITE command) data to a virtual disk drive, the host transmits the clear-text (e.g., unencrypted) data to the gadget, e.g., through an IP-over-USB link” [0101][0058]).
Feng fails to explicitly teach but Joshi teaches restarting the booting process for booting the generated virtual machine. (Joshi, [0003] “Activating and deactivating the encryption feature may require restarting or rebooting the storage device server and/or the drive.”).
Feng is directed to setting up encryption and decryption of virtual storage, while Joshi is directed to activating data encryption at rest in a storage device server in a cloud storage. It should also be noted, it is known in the art that encryption features such as LUKS and BitLocker® require a restart for activation as is taught by Joshi. Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Feng to incorporate the teachings of Joshi to include restarting the booting process for booting the virtual machine. Such modifications would be motivated to ensure proper activation of encryption.
Feng and Joshi do not explicitly teach but Alewine teaches generating the virtual machine based on the virtual machine image; booting the generated virtual machine based on the booting process; (Alewine, Col. 5 ln. 20-29 “In some embodiments, the encrypted partition 330 may have been secured with two-factor encryption with a system, such as a disk encryption specification, such as Linux Unified Key Setup (LUKS). Once the encrypted partition 330 is unlocked, the platform aware init program may load the second kernel 332 and use kexec to boot into it. The common image architecture 300 may be flashed or written to the boot device of a computer, imported as the virtual disk of a virtual machine, or mounted as a file system within a software container.”)
wherein the applying of the encryption setting to the generated virtual machine by performing the following steps:
initializing the physical storage and applying the encryption setting to the physical storage to encrypt data of the physical storage; and (Alewine, Fig. 4 #426, [Col. 5 ln. 60-67] “Initial ram disk. The host container system may execute the program /init from the mounted initial ram disk. The /init script changes root to the encrypted partition and executes the programs within the encrypted partition that comprise the appliance runtime.”[Col 3 lines 45-62][Col 4 lines 7-18] encrypt data of the storage).
Alewine is directed to a system for a common secure cloud appliance image and deployment, including loading an image from physical storage to memory to run as a virtual machine, encrypting the storage, and managing encryption keys with a key management server. Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Feng in view of Joshi to incorporate the teachings of Alewine to include generating the virtual machine based on the virtual machine image; booting the generated virtual machine based on the booting process. Such modification(s) would be motivated to secure and deploy a system image on a virtual machine to execute the boot loader, (Alewine, Col. 5 ln. 1-29) and to load a secure image from a physical storage into memory (Alewine, Col. 4 ln. 61-Col. 5 ln. 19).
Feng-Joshi-Alewine teach copying files, the Feng-Joshi-Alewine do not explicitly but Tan teaches copying, to a memory included in the host computer apparatus, an initial file system loaded to a physical storage corresponding to the virtual machine to load a root file system to the physical storage such that an initial set data of the physical storage associated with the initial file system is backed up (Tan [0060], The computing devices 110, 112, 114, 116 may produce respective manifests that indicate the data files of the computing device 102 being backed up. The cloud storage service 116 stores a backup copy of the fourth data file 128. The manifests 302, 304, 306, 308 may be computer-readable data files that may be used to determine the data files of the computing device 102 that are backed up on a particular backup storage device 110, 112, 114, 116. The manifests 302, 304, 306, 308, in some scenarios, may be text documents indicating the data files of the computing device 102 that are backed up on a particular backup storage device 110, 112, 114, 116);
restoring the initial file system copied to the memory so that the initial set data of the physical storage is restored (Tan [0061], the backup data system 118 may access the manifests of computing device storing backup copies of the data files stored by the memory to restore data files that may no longer be accessible to the computing device. [0063][0024]).
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Feng-Joshi-Alewine to incorporate the teachings of Tan to include copying an initial file system loaded to a physical storage corresponding to the virtual machine before loading an actual file system of the virtual machine such that an initial set data of the physical storage associated with the initial file system is backed up and restoring the initial file system copied to the memory so that the initial set data of the physical storage is restored. Such modification(s) would be motivated to backup files and recover data. Restoring data in case of corruption or loss (Tan [0003][0017][0059]).
Regarding claim 5, Feng-Joshi-Alewine-Tan disclose the method of claim 1, but fails to disclose wherein the virtual machine image further comprises a code for a remote access function, and the method further comprises:
setting communication with a key management service that manages a key of an owner of the virtual machine based on the remote access function.
However, Alewine teaches wherein the virtual machine image further comprises a code for a remote access function, and the method further comprises:
setting communication with a key management service that manages a key of an owner of the virtual machine based on the remote access function. (Alewine, Fig. 2 #220, Col. 3 ln. 34-40, “In some embodiments, the client agent 215 may generate a request for an appliance image and transmit the request to an image server 230. In some embodiments, the client agent 215 may communicate with a key management server 220 to obtain a universally unique identifier corresponding to a passphrase provided by the user via the client agent 215.”)
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Feng in view of Joshi to incorporate the teachings of Alewine to include wherein the virtual machine image further comprises a code for a remote access function, and the method further comprises: setting communication with a key management service that manages a key of an owner of the virtual machine based on the remote access function. Such modification(s) would be motivated to maintain keys associated with different users or clients by the computer apparatus. (Alewine, Col. 3 ln. 45-48)
Regarding claim 6, Feng-Joshi-Alewine-Tan disclose the method of claim 5, wherein the applying of the encryption setting to the virtual machine comprises acquiring the key of the owner from the key management service. (Alewine, Col. 3 ln. 59-62, “The program/bin/mnt-encrypted-img may use the UUID at runtime to retrieve the passphrase from the key management server 220 in order to mount the encrypted partition.”)
Regarding article claim 9 is drawn to the corresponding method claimed in claim 1. Therefore, the instructions of article claim 9 correspond(s) to the steps of method claim 1 and is rejected or the same reasons of obviousness as used above for method claim 1 over Feng-Joshi-Alewine-Tan.
Regarding apparatus claim 10 is drawn to the corresponding method claimed in claim 1. Therefore, the method of using apparatus claim 10 correspond(s) to the method of claim 1 and is rejected for the same reasons of obviousness as used above for method claim 1 over Feng in view of Joshi, Alewine and Tan.
Regarding apparatus claims 13-14 are drawn to the corresponding method claimed in claims 5-6. Therefore, method of using apparatus of claims 13-14 correspond(s) to the method of claims 5-6 and are rejected for the same reasons of obviousness as used above for method claims 5-6 over Feng in view of Joshi, Alewine and Tan.
Claims 3-4 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Feng in view of Joshi, in view of Alewine, in view of Tan as applied to claims 1 and 10 above, and further in view of Muniswamy-Reddy et al. (US 2021/0089662 A1), hereinafter Muniswamy.
Regarding claim 3, Feng-Joshi-Alewine-Tan disclose the method of claim 1, and wherein the initializing of the physical storage and the applying of the encryption setting comprises:
However, Feng-Joshi-Alewine-Tan fail to disclose generating a first key to be used to encrypt data of the physical storage.
Muniswamy teaches wherein the initializing of the physical storage and the applying of the encryption setting comprises:
generating a first key to be used to encrypt data of the physical storage; (Muniswamy, [0039] “For example, an instance 132 may provide a first key (e.g., a “customer” key) to the key management service 190 when creating a volume, and the key management service 190 may select for the volume a volume key.”)
generating a key file by encrypting the first key using a second key of an owner of the virtual machine; and storing the generated key file on a local storage. (Muniswamy, [0039] “The key management service 190 can then encrypt the volume key using the customer key, and provide that encrypted volume key to the storage node 150 for storage as metadata related to the volume.”)
It should be noted, while Feng does teach using a “user-provided passphrase” as an encryption key for a volume(Feng, [0089]). One of ordinary skill in the art would recognize the advantage of combining a user passphrase with a generated key to provide additional security.
Muniswamy is directed to creating virtualized block storage devices. Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Feng-Joshi-Alewine-Tan to incorporate the teachings of Muniswamy to include generating a first key to be used to encrypt data of the physical storage. Such modifications would be motivated to provide an additional layer of security for the volume encryption key.
Regarding claim 4, Feng-Joshi-Alewine-Tan-Muniswamy disclose The method of claim 3, wherein the applying of the encryption setting to the virtual machine comprises:
in response to the encryption setting being already applied to the virtual machine, decrypting the key file using the second key of the owner of the virtual machine. (Muniswamy, [0039] “When an instance 132 attempts to “attach” the volume as a hard disk, the node 150 may provide the encrypted key to a host device of the instance 132, which may in turn submit a request to the key management service 190 to decrypt the encrypted key.”)
Regarding apparatus claim 12 is drawn to the corresponding method claimed in claim 3. Therefore, the method of using the apparatus of claim 12 correspond(s) to the method of claim 3 and is rejected for the same reasons of obviousness as used above for method claim 3 over Feng in view of Joshi, Alewine, Tan and Muniswamy.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Feng in view of Joshi, in view of Alewine, in view of Tan as applied to claim 5 above, and further in view of Pieczul et al. (US Pat. No. 10,834,081 B2), hereinafter Pieczul.
Regarding claim 7, Feng-Joshi-Alewine-Tan disclose The method of claim 5, but fails to disclose wherein the setting of the communication with the key management service comprises using an access control list (ACL) of a secure shell (SSH)-based public key registration scheme based on the remote access function..
However, Pieczul teaches wherein the setting of the communication with the key management service comprises using an access control list (ACL) (Pieczul, [0064] “An access control system 130 , 140 is provided comprising a server access control system 130 provided in the secure environment 102 and a client access control system 140 provided at a user system 108 external to the secure environment. A user session 132 is activated when a user attempts to access a server 120 in the secure environment 102 providing a service or application required by the user.”; [0073] “Verifying 203 access permissions of a user may be carried out by referencing access control permissions that may be stored in the same central repository as the encrypted files in the secure environment or in a separate access control permissions repository.”) of a secure shell (SSH)-based (Pieczul, [0059] “A user system 108 may be provided outside the secure perimeter 104 and may access the secure environment via a secure connection or channel 106 . In one embodiment, the secure channel is a Secure Shell (SSH) cryptographic network protocol that uses socket forwarding that forwards a GPG agent's socket. However, any other secure channel that allows remote system to access user's private key on their workstation may be used.) public key registration scheme based on the remote access function. (Pieczul, [0068] “User credentials in the form of files may be provided for various tools, for example, in the form of services, applications, etc., hosted by servers in the secure environment and may be encrypted with a public key of a user's key pair. The encrypted file may be transferred and stored into a file distribution server in the secure environment.”)
Pieczul is directed to secure access management for tools within a secure environment, including using a secure shell (SSH) for gaining access to credentials for secure services or resources. Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Feng-Joshi-Alewine-Tan to incorporate the teachings of Pieczul to include wherein the setting of the communication with the key management service comprises using an access control list (ACL) of a secure shell (SSH)-based public key registration scheme based on the remote access function. Such modification(s) would be motivated to provide an extra layer of security to the encrypted key file.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Nellitheertha et al. (US 20150220745 A1) – Regarding protecting the security of data stored on a remote resource such as a cloud storage system.
THIS ACTION IS MADE FINAL. 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 KEVIN A AYALA whose telephone number is (571)270-3912. The examiner can normally be reached Monday-Thursday 8AM-5PM; Friday: Variable EST.
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.
/KEVIN AYALA/ Primary Examiner, Art Unit 2496
Prosecution Insights