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 .
DETAILED ACTION
Status of Claims
Claims 1-19 are subject to examination.
Continued Examination
In view of the Appeal Brief filed on 11/17/25. PROSECUTION IS HEREBY REOPENED. New grounds of rejection are set forth below.
To avoid abandonment of the application, appellant must exercise one of the following two options:
(1) file a reply under 37 CFR 1.111 (if this Office action is non-final) or a reply under 37 CFR 1.113 (if this Office action is final); or,
(2) initiate a new appeal by filing a notice of appeal under 37 CFR 41.31 followed by an appeal brief under 37 CFR 41.37. The previously paid notice of appeal fee and appeal brief fee can be applied to the new appeal. If, however, the appeal fees set forth in 37 CFR 41.20 have been increased since they were previously paid, then appellant must pay the difference between the increased fees and the amount previously paid.
A Supervisory Patent Examiner (SPE) has approved of reopening prosecution by signing below:
/JORGE L ORTIZ CRIADO/ Supervisory Patent Examiner, Art Unit 2496
Information Disclosure Statement
The information disclosure statement filed on 10/17/25, 9/17/25 and 7/28/25 is in compliance with the provisions of 37 CFR 1.97, and has been considered and a copy is enclosed with this Office Action.
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-19 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.
Claims 1, 10, 11, recites, “detecting an encrypted disk associated with a workload in a cloud computing environment”, however the specification does not support how the detecting is implemented.
The specification merely contains,
[0020] A system and method for inspecting encrypted disks includes an inspection cloud environment which detects encrypted disks in a production computing environment.
Claim 1 recites ‘detecting an encrypted disk associated with a workload.’ The specification discusses selection/determination by use of an inspection/service account; however, the specification does not disclose any detection algorithm, system structure, or sequence that performs a ‘detection’ operation. Therefore, it is unclear how the specification disclose a detection mechanism sufficient to support the full scope of the claim. The verb “selecting” — standing alone — is ambiguous as broadly described, and is read as a human decision (manual selection). The spec explicitly describes a human operator using, as possible embedment, an account to view/use metadata and then select a disk, the disclosure supports a manual selection/determination step.
The Federal Circuit has explained that a specification cannot always support expansive claim language and satisfy the requirements of 35 U.S.C. 112 "merely by clearly describing one embodiment of the thing claimed." LizardTech v. Earth Resource Mapping, Inc., 424 F.3d 1336, 1346, 76 USPQ2d 1731, 1733 (Fed. Cir. 2005). The issue is whether a person skilled in the art would understand the inventor to have invented, and been in possession of, the invention as broadly claimed.
The verb “detecting” when read as a functional, computer‑implemented limitation implies an computer operation scope performed by the claimed step. Under MPEP § 2161 and § 2162, functional computer‑implemented claim elements must have corresponding support in the specification: concrete structure, algorithm, flow, or sufficient detail showing possession so that a person skilled in the art.
In other words, the claims can cover manual methods (human-in-the-loop) and those are patentable subject matter (avoid other issues), but the scope must mirror the disclosure. A claim that reads on both manual human acts and broad automated acts but the spec only teaches the human act is vulnerable to written‑description/enablement and indefiniteness objections.
With regards to claim 10 and 11, more evidently Claims 10 and 11 are directed to computer-readable medium and system claims. That means the applicant’s claimed is expressly claiming th narrow scope of a computer-implemented detection function — not a human using a computer as a tool.
As above noted, for a computer-implemented invention, MPEP §§ 2161 and 2162 require that when a claim recites a computer performing a function (like “detecting”), the specification must disclose how the computer performs that function — i.e., an algorithm or sufficient structural detail — not just the end result. The specification, however, only discloses that “an encrypted disk is selected for inspection” (¶0036) and that “an inspection account … is utilized in determining that a disk is encrypted” (¶¶0036–0038). These passages describe a human using an account to view metadata or access a provisioning system, not an automated detection performed by a computer. The specification does not disclose any algorithm, process, or structure for automated detection. Therefore, the specification does not reasonably convey to those skilled in the art that the inventor had possession of the full scope of the claimed automated detection at the time of filing.
Claims 1, 10, 11, recites, “generating an inspectable disk based on the decrypted encrypted disk”, however the specification does not support implementation on how the inspectable disk is indeed generated “based on” “decrypted encrypted disk”.
The specification contains, [0031] In an embodiment, the inspectable disk is generated based on a snapshot, a clone, a copy, a combination thereof, and the like, of the disk 112-1.
However, the specification does not implement “decrypted encrypted disk” by itself is “based on” for the generating of the inspectable disk. For example, in order to the copying of the disk, it is the data that is copied.
Claims 2-9, 12-19 are dependent claims of claims 1 and 11 and hence subject to the same rejections.
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-19 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.
Claim 1 recites the limitation "a custom key" in (line 2), "a custom key" in (line 5), "the custom key" in (line 8), "a custom key" in (line 9). It is not clear which custom key is referred by “the custom key” and whether all three custom keys are same or different. There is insufficient antecedent basis for this limitation in the claim. Considering that there are three different keys it is contrary to have the key being custom to the single account.
Claim 1 contains, authorizing a key policy on the security policy server for a custom key of an inspector account, wherein the key policy is a policy authorized to decrypt the encrypted disk. As claimed, “the key policy is a policy authorized to decrypt the encrypted disk”, the key policy is already “authorized” for every person/account. The authorizing step to further authorize the already authorized the key policy as claimed is indefinite for failing to particularly point out and distinctly claim the subject matter.
Claim 1, 10 and 11, recites “generating an inspectable disk based on the decrypted encrypted disk”. “Inspectable disk” is a coined relative term not explicitly defined as a particular artifact in the independent claim or the specification, as to what makes it inspectable. The term “inspectable disk” is a relative, result‑oriented adjective: it describes a disk “capable of being inspected” but does not by itself define what technical state, structure, or specific artifact renders the disk “inspectable.” A claim that uses such a relative term must either (a) include further defining claim language that ties the relative term to specific structure/steps, or (b) be clearly and unambiguously defined in the specification.
Without a limiting definition, a skilled reader may not understand the metes and bounds of the claimed subject matter with reasonable certainty.
Claims 2-9, 12-19 are dependent claims of claims 1 and 11 and hence subject to the same rejections as they do not cure the deficiencies
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-5, 10, 11, 12, 14, 15, are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Veselov et al., US 11216563 B1.
Referring to claim 1, Veselov discloses, a method for inspecting encrypted disks for a cybersecurity object using a custom key (Fig. 2; Fig. 5; col. 3 ln 20 to col. 17; The encrypted volumes are decrypted for analysis using an encryption key (col. 18 ln 1 to ln 15); The claim does not define “custom key” beyond “a key used by the security policy server to decrypt the encrypted disk.” The spec does not redefine “custom,” so it defaults to plain meaning — i.e., a key corresponding to a particular (i.e. “encrypted disk”, encryption context), comprising:
detecting an encrypted disk associated with a workload in a cloud computing environment, the cloud computing environment including a security policy server (Fig. 2, steps 202 to 206; col. 18 ln 1 to ln 15; the volume image 508 may be encrypted and the scanning service 510 may require access to the encryption key to perform the analysis);
authorizing a key policy on the security policy server for a custom key of an inspector account, wherein the key policy is a policy authorized to decrypt the encrypted disk (col. 18 ln 1 to ln 15; The encryption key may be maintained in a security module or security service of the computing resource service provider; discloses that the encryption key may be maintained in a security module/service of the provider, and that the scanning service (acting under appropriate authorization) obtains credentials and key identification to access the encryption key, This corresponds to authorizing a policy on a server to allow the scanning service (inspector) to use the key to decrypt; “key policy” is any permission/authorization to use a key and the “security policy server” is met by Veselov’s disclosure of a “security module or security service” of the cloud provider that maintains encryption keys and enforces access );
decrypting the encrypted disk with the custom key, wherein the key policy is configured to allow adding a custom key (col. 18 ln 1 to ln 15; access to the encryption key to perform the analysis); and
generating an inspectable disk based on the decrypted encrypted disk (Fig. 2, step 208; col. 10 line 1- 14; At step 208, the scanning service may generate a scannable volume, or cause a scannable volume to be generated, based at least in part on the snapshot data).
PNG
media_image1.png
594
836
media_image1.png
Greyscale
PNG
media_image2.png
680
550
media_image2.png
Greyscale
Referring to claim 2, Veselov discloses inspecting the inspectable disk to detect a cybersecurity object (Fig. 2; At step 210, the scanning service may perform the security assessment on the scannable volume).
Referring to claim 3, Veselov discloses repeatedly snapshots, volume images, mounting, copying, instantiating duplicates; it explicitly describes snapshot/volume image/copy flows (col. 3, lines 20-40; col. 9 lines 9-41; col. 10 lines 1-16; col. 17 line 9 to line 29; Copying contents from volume image into a second logical volume is effectively a clone).
Referring to claim 4, Veselov discloses, generating the inspectable disk based on a snapshot of the decrypted encrypted disk. (The snapshot may include all of the data needed to recreate the state of the computing resource within a duplicate, virtual computing resource. For example, the target computing resource may be an instance of a virtual machine implemented within block-level storage device resources allocated to a logical volume. The snapshot may be a copy of the state of memory, the state of any devices (virtual or physical) allocated to the resource, block-level image of the entire logical volume; or, the snapshot may be an image of only a portion of the logical volume containing the data required to embody an exact copy of the virtual machine instance; or the snapshot may simply be a copy of certain files of the target computing resource, such as a database of software packages installed in a virtual machine, col. 3, lines 35-40).
Referring to claim 5, Veselov discloses, generating the inspectable disk based on a copy of the decrypted encrypted disk (A volume image utilized by the scanning service 310 in accordance with the present systems and methods may be any suitable type of disk image, which is a copy of the electronic data stored in one or more discrete parts, such as sectors, of a physical storage device such as a hard disk drive, tape drive, removable magnetic or optical disk, and the like. The volume image may copy the entirety of the source medium, such that the contents represented by the stored data, as well as the structure of the stored data, are contained in the volume image. A volume image's copy of the physical storage device contents may be independent of the file system (i.e., the volume image contains a block based replica of the virtual machine) and/or may include the file system of the corresponding logical volume represented by the parts of the physical stored device that are copied. The volume image may be represented, such as within another physical storage device, as one or more computer files; in various embodiments, such computer file(s) may have one or more file formats suitable for disk images, such as the ISO disk image format or a format that corresponds to a particular software application. The volume image 308 may include the entire partition in which the virtual machine 312 is implemented, or may include only a portion of the partition, col., 11, lines 52-60
Referring to claim 10, the medium claim is similarly analyzed and rejected for the same rationale as the method claim 1.
Referring to claims 11-15, the system claim is similarly analyzed and rejected for the same rationale as the method claims 1-5, respectively.
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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 6–9 and 16–19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Veselov in view of Applicant’s admission of prior art, AAPA.
Referring to claim 6 and 16, Veselov teaches, as above, detecting snapshots/volume images, that volume images may be encrypted and require access to an encryption key for analysis, and generating an inspectable/scannable volume from a snapshot/volume image, a security module or security service of the computing resource service provider; discloses that the encryption key may be maintained in a security module/service of the provider, and that the scanning service (acting under appropriate authorization) obtains credentials and key identification to access the encryption key (see Veselov, Fig. 2; Fig. 5; col. 10, ll. 1–14; col. 18, ll. 1–15).
Applicant’s background section provides the problem faced, [0004] Scanning for cybersecurity threats in a cloud computing environment often includes scanning storage, disks, and the like, for such cybersecurity objects. One method of protecting information includes encrypting storage resources, such as disks, so that even if they are accessed by an unauthorized party, the disk is not readable. However, such encrypted disks also cannot be scanned as a scanner requires an unencrypted volume to access. Encrypted disks present a challenge as decryption keys may not be readily available, and therefore their contents cannot be scanned.
Veselov, already acknowledge such challenge and anticipates such solution to the problem/challenge faced, by expressly disclosing col. 18 ln 1 to ln 15; the volume image 508 may be encrypted and the scanning service 510 may require access to the encryption key to perform the analysis. The encryption key may be maintained in a security module or security service (not shown) of the computing resource service provider. In these embodiments, the scanning service 510 gains access to the key by obtaining credential information from the user and may also obtain key identification information if necessary. Alternatively, the user may maintain the key and provide the scanning service 510 with the key.
Veselov while having a service provider on a computing resource managing access to the keys, would be considered a key management system “obtaining” meaning fetching, it does not expressly show worded “determining that the encrypted disk utilizes an application based encryption; and fetching the custom key from a key vault management system”.
However, Applicant’s spec describes that the solution to the problem is as an admission that fetching and using keys from a key‑vault/KMS and using conventional key wrapping (KEK) or BitLocker key formats without adding any inventive steps or structural changes, and the limitations are implementations of known key management functionality. Specifically, functionalities of expressly admits use of key-management services (KMS/key vault), AWS/Azure KMS, from Amazon Web Services, Microsoft Azure, or Google Cloud Platform (BGCP) [0021], [0035] “embodiments illustrate user of cloud managed encryption in AWS, and application level encryption in Azure, it should be readily apparent that the teachings
herein can be applied to other cloud infrastructures with appropriate adjustments”, [0040], a KMS in AWS supports two types of keys. The first type is an Elastic Block Store (EBS) default key, and the second type is a custom key.”, and or example [0041], [0041]–[0044], [0048]–[0061].
Point of emphasis, Applicant made very clear that “it should be readily apparent that the teachings
herein can be applied to other cloud infrastructures with appropriate adjustments”. Indeed, a particular known technique was recognized as part of the ordinary capabilities of one skilled in the art. One of ordinary skill in the art would have been capable of applying this known technique to a known device (method, or product) that was ready for improvement and the results would have been predictable to one of ordinary skill in the art. MPEP 2143.
MPEP § 2129 these statements, are admissions that such functionality was known/available.
Public KMS documentation (e.g., AWS KMS, Azure Key Vault, etc) teaches known fetching data keys and key retrieval for decryption and distinguishing custom vs. default keys and associated policies. It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention and found to be a routine and predictable design of applying a known technique that yields predictable results to have modify Veselov’s a security module or security service of the computing resource service provider specifically by use of a particular existing KMS readily available/known services and use it to obtain the necessary key and decrypt an encrypted disk. See KSR Int’l Co. v. Teleflex, 550 U.S. 398 (2007).
Referring to claim 8 and 18, Veselov discloses encrypted images and the need for keys to analyze them (Veselov, Fig. 2; Fig. 5; col. 18, ll. 1–15). As above noted with claim 6 and 16, Applicant’s admits this to be known of using Linux disks utilize Cryptoluks key wrapping (KEK) or Windows operating system utilizes the Bitlocker key formats expressly discloses application‑level encryption examples (BitLocker, Cryptoluks) and provides a step flow for using a decoded base64 key from a key vault with BitLocker/decryption tooling ¶[0043]–[0044], the limitations are implementations of known functionality of the OS system for disks. Applicant goes further to sate, “an inspector is configured to execute a decrypt command..” it is unclear how an inspector “i.e. human” is configured, so this is read as an inspectors would use the respective command known under Linux disks utilize Cryptoluks.
MPEP § 2129 these statements, are admissions that such functionality was known/available.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention and found to be a routine and predictable design of applying a known technique that yields predictable results to have modify Veselov’s a security module or security service of the computing resource service provider specifically by use of a particular existing readily available/known services and use it to obtain the necessary key and decrypt an encrypted disk. See KSR Int’l Co. v. Teleflex, 550 U.S. 398 (2007).
Under MPEP § 2129 this is an admission that such workflows were known. Microsoft BitLocker or Linux disks utilize Cryptoluks documentation and tool documentation, teach the known of how externally supplied recovery/protector keys (e.g. often base64‑encoded in workflows) are used to decrypt/mount BitLocker volumes. Combining Veselov with these known OS/key retrieval practices would have been an obvious implementation to achieve the claimed result. Thus claims 8 and 18 are prima facie obvious.
Claim(s) 6, 16, is/are rejected under 35 U.S.C. 103 as being unpatentable over Veselov in view of and CARTER et al., WO 2004034184 A2 and GRAY et al., 20190334715
Referring to claim(s) 6, 16, Veselov do not disclose, which is well-known in the art, which CARTER discloses, determining that the encrypted disk utilizes an application based encryption (
application- based encryption systems encrypt whole file partitions and do allow encryption of individual files, last para, page 3,
The data vault and key vault can be protected in many ways.
Key Vault Management System, (8) a Data Audit System, and (9) a Key Vault. 4th para, page 7.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Veselov to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing encryption that is based on application. Different application would be encrypted with different key of the key vault which would enhance security of respective application specific information, 2nd para, page 7.
Veselov, and CARTER do not disclose, which is well-known in the art, which Gray discloses, fetching the custom key from a key vault management system (
[0110] In some examples, a user may have a user token that can be passed and mapped to a key in Key Vault 465. When activities associated with the user are performed in an enclave, the user's key may be fetched from Key Vault 465 using a cryptlet tunnel, e.g., in order to sign on behalf of the user using the user's key. Use of the cryptlet tunnel may allow the key to be communicated securely between the enclave and Key Vault 465.
[0105] when a cryptlet is instantiated within its CryptletContainer host, if its identity is established by a key pair in the key vault, the CryptletContainer will securely fetch and provide the key pair to the cryptlet upon instantiation. Or, if the cryptlet creates its own or a new key pair, these new keys may be automatically stored by the CryptletContainer when the Cryptlet deactivates. In some examples, the cryptlet can then use the private key to sign transactions and messages for delivery. One example of an assigned key is a cryptlet that signs transactions as a specific counter party, corporation, user, or device, to a Smart Contract with the counter party's private key.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Veselov to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing fetching the custom key. Different application would be encrypted with different key of the key vault which would enhance security of respective application specific information. The fetched key from the vault would enable performing the transaction associated with a specific party, para 105.
Claim(s) 7, 17, is/are rejected under 35 U.S.C. 103 as being unpatentable over Veselov in view of SCHINDEWOLF et al., 20210194678
Referring to claim(s) 7, 17, Veselov do not disclose, which is well-known in the art, which SCHINDEWOLF discloses, decrypting the custom key, wherein the custom key is encrypted using a key-encryption-key (
[0039] In an embodiment, the tenant configuration database 220 may store the key encryption key for decrypting the encrypted header information 130 including the body encryption key. The body encryption key may be used for decrypting and accessing the contents of the payload database 118. In another embodiment, the tenant configuration database 220 may include a configuration 222 for accessing the external system 122. The external system 122 may store the key encryption key for decrypting and accessing the body encryption key. The encrypted header information 130 of the payload database 118 may be transmitted to the external system 122. The external system 122 may use the key encryption key to decrypt the encrypted header information 130 to access the body encryption key. The external system 122 may transmit the body encryption key, in clear text, to the second partition 112. The second partition may decrypt the payload database 118 using the body encryption key.
[0025] The second access key 124 may be stored by the client 100 in a secure environment. The second access key 124 may be stored in a virtual vault, jailed environment, physical vault, and/or the like.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Veselov to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing key encrypting key. The stored key encrypting key would enable decrypting the information of the key. This would enable accessing content for transmission that is kept secured, para 39.
Claim(s) 8, 18, is/are rejected under 35 U.S.C. 103 as being unpatentable over Veselov in view of FANG, SG 11202103226U A and Li, CN 112989379 A.
Referring to claim(s) 8, 18, Veselov do not disclose, which is well-known in the art, which FANG discloses, setting a decoded base64 key from a key vault on the encrypted disk, in response ( unique User ID userType enum User type publicKey base64 encoded string Public key privateKey Alias string Alias of private key used by the custom clearance service platform to invoke the private key kept in secured digital key vault bcAccountld string Account ID on the blockchain, 2nd para, page 16)
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Veselov to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing base64 key. One of ordinary skilled in the art would readily know that the base64 is a binary to a text encoding scheme that represents binary data in an ASCII string format. base64 is designed to carry data stored in binary format across the channels. It takes any form of data and transforms it into a long string of plain text. The stored base64 key would enable decrypting the information and carry data stored in binary format for transmission of information that is kept secured, 2nd para, page 16.
Veselov, Fang do not disclose, which is well-known in the art, which Li discloses, to determining that an operating system of the workload utilizes Bitlocker (
based on this, in the operation system operation process of the electronic device, such as under the Windows OS operating system, the user starts the BitLocker, can prompt the user whether the BitLocker generated disk encryption key Key, stored to the first storage space of the first controller; under the condition that the selection is, the display interface of the electronic device can output query encryption interface for the disk encryption key, the user inputs the key identification and decoding authentication information of the disk encryption key, such as the name of Key and encryption password; The invention does not limit the content and the input mode of the key identification and decoding authentication information, and the visual condition is determined, last para, page 10.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Veselov to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing Bitlocker. One of ordinary skilled in the art would readily know that the BitLocker is a Windows security feature that encrypts drives to protect data. It helps keep sensitive information safe if a device is lost or stolen. BitLocker encrypts the entire disk drive, making it impossible to read the data without the encryption key. BitLocker integrates with the Windows operating system and is designed to be user-friendly. The well-known BitLocker would enable associating with the operating system and ensure that the sensitive information is prevented from forgery, last para, page 10.
Claim(s) 9, 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Veselov in view of and Novack et al., CN 106462439 A.
Referring to claim(s) 9, 19, Veselov do not disclose, which is well-known in the art, which Novack discloses, determining that the encrypted disk is encrypted based on metadata associated with the encrypted disk (
the cloud calculation environment, the lessee can include a user, company, company department, or the deployment by cloud service provider operates one or more of virtual machine has an access right in the data centre of the other entity. lessee might wish to represent itself to deploy virtual machine. However, the lessee may be desirable on the virtual machine is deployed to host data center was in storage or when the virtual machine is deployed to host computer in the data centre to prevent other entities (such as other lessee, eavesdropper or even data center administrator) to access the virtual machine. In order to achieve this purpose, a virtual machine may be encrypted, such as by the metadata of the virtual disk and/or virtual machine is encrypted. Therefore, the virtual machine encrypting the immigrating to protect the confidentiality of the content and integrity between the off-line storage and the host. In addition, for encrypting the content key of virtual machine may be required with a certain regularity is turned over (i.e., change). This may to the owner of the virtual machine provides access to the challenge of their encrypted virtual machine, 3rd para, page 3.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Veselov to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing metadata. One of ordinary skilled in the art would readily know that the metadata associated with the disk would provide addition information about the disk. The additional information would provide additional security for the encryption of the disk to protect the content of the disk from malicious entities, 3rd para, page 3.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-19 have been considered but are moot because the new ground of rejections is made under in view of Veselov.
Please see above rejections under Veselov.
Conclusion
Pertinent reference:
Kopylov et al., US 11288377 B1,
(13) There are multiple ways to store application data permanently, which include saving data on the VM disk or external data storage. However, data privacy in respect to the administrator 112 may not be guaranteed without data encryption. For example, the VM 108 disk data can be extracted by the administrator 112 by making a snapshot of the disk, creating a new disk based on the snapshot and attaching this disk to another VM for inspection. Non-sensitive data, such as application logs, that help to identify bugs and runtime errors, may still be written to the VM disk. All sensitive data must be encrypted inside the TEE 108 before being saved to a permanent data storage.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HARESH PATEL whose telephone number is (571)272-3973. The examiner can normally be reached on M-F 9-5:30.
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 L. 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 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 http://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). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HARESH N PATEL/Primary Examiner, Art Unit 2496