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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 2/2/2026 has been entered.
Claim Objections
Claim 1 is objected to because of the following informalities: Line 13 includes the phrase “handling the further access to the disk device…” There is no previous instance of “further access” therefore the phrase lacks antecedent basis. Examiner suggests removing “the”, leaving “handling further access to the disk device”. Appropriate correction is required.
Claim 7 is objected to because of the following informalities: The claim includes the limitation, “comprising a label step in which a user can be define the unique disk label” which is not grammatically correct. For the purpose of further examination and based on the specification and the arguments, the limitation will be interpreted as a label step in which a user can define the unique disk label. Examiner suggests removing the word “be”. Appropriate correction is required.
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 (i.e., changing from AIA to pre-AIA ) 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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1 – 4, 6 and 8 – 9 are rejected under 35 U.S.C. 103 as being unpatentable over Raizen US Patent No. 8416954 (originally cited in IDS filed 2/26/2024, herein after referred to as Raizen) in view of Indukuri et al. US Patent Application Publication No. 2019/0266347 (herein after referred to as Indukuri).
Regarding claim 1, Raizen describes a method for controlling access to a disk device connected to an execution platform (Storage devices 3, 4 may include multiple disk drives 5, 6 that combine to form a disk array (column 10, lines 41 – 42). …the host computers 1A, 1B communicate via a storage interconnect 24 with a plurality of primary storage devices 3, replica storage devices 4, and a set 9 that includes both primary 3 and replica 4 storage devices (column 15, lines 35 – 38)),the method comprising reserving a first region of the disk device and storing an unique disk label in said first region (At the same time, a key identifier (key_id), associated with that key is stored in the I/O filter system 28’s metadata region 46 on the LU… the key_id is a globally unique key_id (column 13, lines 42 – 47)), wherein said first region is not encrypted (Because metadata on the LU stores information, in plaintext, that can be used to obtain the key for the data on the LU, given permission to obtain the key it is possible for replicas to be made of a logical unit where the replica keeps intact the encryption and also includes in the replica the information to obtain a key for decryption (column 13, lines 17 – 23)), encrypting a second region of the disk device (…defining a first encrypted region on the logical unit for storing encrypted data (column 6, lines 17 – 18). …the logical unit portion 44 includes… a section 44b that stores encrypted data (column 19, lines 30 – 32)), wherein the second region includes user data and file information (…implementations of host-based encryption can be implemented to encrypt any data leaving the host as files, blocks, or objects (column 4, lines 18 – 19). This clearly indicates that data being stored can take the form of files, blocks, or objects. In one aspect, the invention provides an I/O filter system 28 that provides an information-centric protection mechanism for data (e.g., user data) stored on logical units… (column 12, lines 61 – 63)), said method further comprises providing a cipher agent running on said execution platform (…each host computer 1A, 1B having a respective I/O filter system with encryption 28A, 28B (column 15, lines 26 – 27)) and carrying out the following steps in case an opening of the disk device is requested, - reading the unique disk label stored in the first region (Whenever an eVLU 40b is encountered by the I/O filter driver 29 (usually at startup of the host 1), it is configured into the I/O filter system 28 by the xcrypt manager 64. At that point, the xcrypt manager 64 requests the key lookup of the encryption key by passing the key_id to a user space daemon… (column 24, lines 1 – 12). Reads and writes to encrypted parts of the VLU will be disabled to those devices until the key is looked up and cached in the kernel. The I/O filter system 28 gets the key for each eVLU, based on information stored in the I/O filter system 28 metadata which is in a private region of the LU (column 13, lines 63 – 67)), - retrieving a protection policy for the disk device based on the unique disk label (The key manager server 26… which is capable of looking up a globally unique identifier (column 16, lines 9 – 13). Thus, one role of the key manager server 26 in Fig. 2A is to securely create, store and return keys to authorized entities, such as I/O filter system 28 with I/O filter driver 29 of Fig. 2A (column 16, lines 34 – 37)) and - handling the further access to the disk device based on the protection policy (…Once the key lookup is accomplished, the daemon 102 sends the encryption key to the xcrypt manager 64, which then has it available for doing I/O… (column 24, lines 1 – 19). …On every read of a device (see Fig. 13), decrypt the data on the way back to the user… On every write of a device (see Fig. 12), encrypt the data before sending it down the I/O stack (column 23, lines 61 – 67)). Raizen describes that an identifier that is associated with the key can be stored and can be used to obtain the key, provided that all permissions and credentials are in place (column 4, line 65 – column 5, line 3). For example, when the key_id is presented to the key manager with appropriate credentials, the host system is allowed to obtain the key used to encrypt/decrypt the LU (column 5, lines 4 – 6). However, Raizen does not explicitly disclose wherein the protection policy comprises a whitelist of applications allowed to access the disk device, wherein the cipher agent does only allow access to the disk device by an application included in the whitelist.
Indukuri describes a method of protecting data. Specifically, before the ciphertext can be decrypted, the access control layer 50 or anchor service 26 may determine if the user device 14 is operating within an access context associated with the file. This determination may be made, for example, by the access control layer 50 extracting the context identifier from the heartbeat signal 40 and transmitting the context identifier to the anchor service 26 in a key-unlock request 62. The anchor service 26 may then determine whether to transmit a data encryption key to the access control layer 50 based at least in part on whether the context identifier indicates the access context associated with the ciphertext is satisfied, e.g., that the user device 14 is in an allowed location context. If the required access context is satisfied, anchor service 26 may transmit a key-unlock response 64 to the access control layer 50. In an embodiment of the invention, the key-unlock request 62 or key-unlock response 64 may include metadata associated with the data to be opened, such as a file identifier, a digital signature associated with the access control layer 50 that is used by the anchor service 26 to verify that the user device 14 is legitimate, or any other suitable data (page 6, paragraph [0073]). Encryption may be enforced in a simple fashion that is seamless to the user. That is, both the user and application are typically unaware that they are interacting with the data anchor system. In contrast to conventional products that come in the form of macros integrated into specific applications, the universal nature of the data anchor system allows it to work seamlessly without regard to the application or data type. Further, the system user can also whitelist or blacklist applications effortlessly in a few seconds. This ability to work seamlessly with list-based security systems and other applications is facilitated by the data anchor system operating below the application layer rather than at the application layer or in the application itself (page 11, paragraph [0119]).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to incorporate the Indukuri teachings in the Raizen system. Skilled artisan would have been motivated to incorporate the method of providing a user ability to whitelist applications as taught by Indukuri in the Raizen system for effectively allowing for seamless encryption enforcement (Indukuri, page 11, paragraph [0119]). In addition, both of the references teach features that are directed to analogous art and they are directed to the same field of endeavor, such as storage encryption. This close relation between both of the references highly suggests an expectation of success.
Regarding claim 2, Raizen in view of Indukuri describe the method according to claim 1 (see above), wherein the cipher agent carries out decryption for reading data from the second region and encryption for writing data in the second region (…Once the key lookup is accomplished, the daemon 102 sends the encryption key to the xcrypt manager 64, which then has it available for doing I/O… (Raizen, column 24, lines 1 – 19). …On every read of a device (see Fig. 13), decrypt the data on the way back to the user… On every write of a device (see Fig. 12), encrypt the data before sending it down the I/O stack (Raizen, column 23, lines 61 – 67)).
Regarding claim 3, Raizen in view of Indukuri describe the method according to claim 1 (see above), wherein the cipher agent comprises a cipher disk driver below the disk layer of an operating system running on the execution platform, said cipher disk driver controls access to the disk device which bypasses the disk layer (In general, in accordance with the invention, the I/O filter driver 29 can sit above or below any component in the I/O stack 30… (Raizen, column 18, lines 8 – 10)).
Regarding claim 4, Raizen in view of Indukuri describe the method according to claim 1 (see above), wherein the cipher agent comprises a file system driver for controlling access to the disk device through a disk layer of an operating system running on the execution platform (In general, in accordance with the invention, the I/O filter driver 29 can sit above or below any component in the I/O stack 30… (Raizen, column 18, lines 8 – 10)).
Regarding claim 6, Raizen in view of Indukuri describe the method according to claim 1 (see above), further comprising a data security manager for handling the security policy and for ensuring that the disk label is a unique disk label (…The libemcp_xcrypt 208 component services user commands from the powervt API 204 component and coordinates the events such as look up key event in the kernel 96. These commands, which are explained more fully as part of the flowcharts of Figs. 7 – 17 herein, do the following things: Add the encryption property to a device (see e.g., the flowchart of Fig. 9). This command also results in the provision of a key_id for the device and, optionally, other properties in addition to the key_id, if a given application requires it (Raizen, column 23, lines 31 – 41)).
Regarding claim 8, Raizen in view of Indukuri describe the method according to claim 1 (see above), comprising a policy step in which a user can define a whitelist of applications allowed to access the disk device (Further, the system user can also whitelist or blacklist applications effortlessly in a few seconds. This ability to work seamlessly with list-based security systems and other applications is facilitated by the data anchor system operating below the application layer rather than at the application layer or in the application itself (Indukuri, page 11, paragraph [0119])).
Regarding claim 9, Raizen describes an execution platform for controlling access for a disk device connected to the execution platform (Storage devices 3, 4 may include multiple disk drives 5, 6 that combine to form a disk array (column 10, lines 41 – 42). …the host computers 1A, 1B communicate via a storage interconnect 24 with a plurality of primary storage devices 3, replica storage devices 4, and a set 9 that includes both primary 3 and replica 4 storage devices (column 15, lines 35 – 38)), wherein the disk device comprises a first region, in which a unique disk label is stored (At the same time, a key identifier (key_id), associated with that key is stored in the I/O filter system 28’s metadata region 46 on the LU… the key_id is a globally unique key_id (column 13, lines 42 – 47)) and which is not encrypted (Because metadata on the LU stores information, in plaintext, that can be used to obtain the key for the data on the LU, given permission to obtain the key it is possible for replicas to be made of a logical unit where the replica keeps intact the encryption and also includes in the replica the information to obtain a key for decryption (column 13, lines 17 – 23)), and second region, which includes data and file information (…implementations of host-based encryption can be implemented to encrypt any data leaving the host as files, blocks, or objects (column 4, lines 18 – 19). This clearly indicates that data being stored can take the form of files, blocks, or objects. In one aspect, the invention provides an I/O filter system 28 that provides an information-centric protection mechanism for data (e.g., user data) stored on logical units… (column 12, lines 61 – 63)) and which is encrypted (…defining a first encrypted region on the logical unit for storing encrypted data (column 6, lines 17 – 18). …the logical unit portion 44 includes… a section 44b that stores encrypted data (column 19, lines 30 – 32)), wherein a cipher agent is running on the execution platform (…each host computer 1A, 1B having a respective I/O filter system with encryption 28A, 28B (column 15, lines 26 – 27)) and carries out the following steps in case an opening of the disk device is requested, - reading the unique disk label stored in the first region (Whenever an eVLU 40b is encountered by the I/O filter driver 29 (usually at startup of the host 1), it is configured into the I/O filter system 28 by the xcrypt manager 64. At that point, the xcrypt manager 64 requests the key lookup of the encryption key by passing the key_id to a user space daemon… (column 24, lines 1 – 12). Reads and writes to encrypted parts of the VLU will be disabled to those devices until the key is looked up and cached in the kernel. The I/O filter system 28 gets the key for each eVLU, based on information stored in the I/O filter system 28 metadata which is in a private region of the LU (column 13, lines 63 – 67)), - retrieving a protection policy for the disk device based on the unique disk label (The key manager server 26… which is capable of looking up a globally unique identifier (column 16, lines 9 – 13). Thus, one role of the key manager server 26 in Fig. 2A is to securely create, store and return keys to authorized entities, such as I/O filter system 28 with I/O filter driver 29 of Fig. 2A (column 16, lines 34 – 37)) and - handling the further access to the disk device based on the protection policy (…Once the key lookup is accomplished, the daemon 102 sends the encryption key to the xcrypt manager 64, which then has it available for doing I/O… (column 24, lines 1 – 19). …On every read of a device (see Fig. 13), decrypt the data on the way back to the user… On every write of a device (see Fig. 12), encrypt the data before sending it down the I/O stack (column 23, lines 61 – 67)). Raizen describes that an identifier that is associated with the key can be stored and can be used to obtain the key, provided that all permissions and credentials are in place (column 4, line 65 – column 5, line 3). For example, when the key_id is presented to the key manager with appropriate credentials, the host system is allowed to obtain the key used to encrypt/decrypt the LU (column 5, lines 4 – 6). However, Raizen does not explicitly disclose wherein the protection policy comprises a whitelist of applications allowed to access the disk device, wherein the cipher agent does only allow access to the disk device by an application included in the whitelist.
Indukuri describes a method of protecting data. Specifically, before the ciphertext can be decrypted, the access control layer 50 or anchor service 26 may determine if the user device 14 is operating within an access context associated with the file. This determination may be made, for example, by the access control layer 50 extracting the context identifier from the heartbeat signal 40 and transmitting the context identifier to the anchor service 26 in a key-unlock request 62. The anchor service 26 may then determine whether to transmit a data encryption key to the access control layer 50 based at least in part on whether the context identifier indicates the access context associated with the ciphertext is satisfied, e.g., that the user device 14 is in an allowed location context. If the required access context is satisfied, anchor service 26 may transmit a key-unlock response 64 to the access control layer 50. In an embodiment of the invention, the key-unlock request 62 or key-unlock response 64 may include metadata associated with the data to be opened, such as a file identifier, a digital signature associated with the access control layer 50 that is used by the anchor service 26 to verify that the user device 14 is legitimate, or any other suitable data (page 6, paragraph [0073]). Encryption may be enforced in a simple fashion that is seamless to the user. That is, both the user and application are typically unaware that they are interacting with the data anchor system. In contrast to conventional products that come in the form of macros integrated into specific applications, the universal nature of the data anchor system allows it to work seamlessly without regard to the application or data type. Further, the system user can also whitelist or blacklist applications effortlessly in a few seconds. This ability to work seamlessly with list-based security systems and other applications is facilitated by the data anchor system operating below the application layer rather than at the application layer or in the application itself (page 11, paragraph [0119]).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to incorporate the Indukuri teachings in the Raizen system. Skilled artisan would have been motivated to incorporate the method of providing a user ability to whitelist applications as taught by Indukuri in the Raizen system for effectively allowing for seamless encryption enforcement (Indukuri, page 11, paragraph [0119]). In addition, both of the references teach features that are directed to analogous art and they are directed to the same field of endeavor, such as storage encryption. This close relation between both of the references highly suggests an expectation of success.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Raizen in view of Indukuri, further in view of Ramaraj et al US Patent Application Publication No. 2020/0082114 (herein after referred to as Ramaraj).
Regarding claim 7, Raizen in view of Indukuri describe the method according to claim 1 (see above). They do not specifically disclose comprising a label step in which a user can be define the unique disk label.
Ramaraj describes storage drive protection using file system level encryption. Specifically, it is disclosed encrypting header information of a user-supplied storage device 120 using a key that is derived from the user’s unique identification. The identification could correspond to the user, a user account and/or the like so that the header data on the drive can only be decrypted with the same user’s unique information. Further, by encrypting only limited portions of the data on the drive 120, the computational overhead on processor 111 can be dramatically reduced. If only header information (e.g., the contents of XFS superblocks) is encrypted, for example, the remainder of the unencrypted data is essentially rendered to be useless, thereby preserving the integrity of the media contents stored on device 120 (page 8, paragraph [0074]).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to incorporate the Ramaraj teachings in the Raizen in view of Indukuri system. Skilled artisan would have been motivated to incorporate the method of encryption using a key that is derived from a user’s unique identification as taught by Ramaraj in the Raizen in view of Indukuri system for effectively encrypting header information of a user-supplied storage device. In addition, both of the references teach features that are directed to analogous art and they are directed to the same field of endeavor, such as storage encryption. This close relation between both of the references highly suggests an expectation of success.
Response to Arguments
Applicant argues that Raizen fails to disclose a protection policy comprising an application whitelist. Applicant further argues that the encryption in Raizen occurs transparently and is agnostic to the identity of the accessing application. Examiner notes that while Raizen does not specify the method, it explicitly mentions in several citations “provided that all permissions and credentials are in place”, “with appropriate credentials”, and “assuming the requester is allowed access”. Raizen clearly anticipates that requester credentials should be checked generally. Indukuri is then cited to suggest a specific method for determining what applications have appropriate credentials.
Applicant argues that Raizen fails to disclose “handling further access” by allowing or denying disk access. Examiner refers to explanation above, that Raizen generally describes determining permission/credentials and that Indukuri discloses a specific whitelist method. The combination is believed to reasonably suggest the “handling further access” as claimed.
Applicant argues that Raizen does not disclose retrieving such a policy based on a disk-stored label. Examiner refers to explanation above, that Raizen generally describes determining permission/credentials, that the key manager server is to securely create, store and return keys to authorized entities, and that Indukuri discloses a specific whitelist method including how the whitelist is compared.
Applicant argues that claim 9 is not anticipated for the same reasons above. Examiner refers to rejections and responses above as to why that claim is not currently allowable.
Applicant argues that Raizen does not teach or suggest claim 8 and that Indukuri fails to cure the deficiency. Specifically, Applicant argues that Raizen does not include a policy-based access-control framework and therefore combining Indukuri is based on impermissible hindsight. Examiner refers to explanation above, that Raizen generally describes determining permission/credentials, that the key manager server is to securely create, store and return keys to authorized entities, and that Indukuri discloses a specific whitelist method including how the whitelist is compared.
Applicant argues that claim 7 recites a label step in which a user defines the unique disk label. Examiner has referred to Ramaraj, which suggests that the encryption key used is derived from the user’s unique identification. Examiner believes that this broadly teaches a user defined unique disk label as argued. Examiner suggests more specific limitation to avoid this interpretation.
Applicant argues, with respect to claims 7 and 8, that there is no motivation to combine Indukuri or Ramaraj, nor an expectation of success. Examiner refers to rejections and responses above. Briefly, Raizen is believed to generally suggest some form of permission/credential determination and Indukuri teaches a specific method of permission/credential determination. Raizen describes the use of encryption keys while Ramaraj teaches that an encryption key may be derived from the user’s unique identification.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RALPH A VERDERAMO III whose telephone number is (571)270-1174. The examiner can normally be reached Monday through Friday 8:30 AM - 5:00 PM.
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, Reginald Bragdon can be reached at (571) 272-4204. 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.
/RALPH A VERDERAMO III/Examiner, Art Unit 2139
/REGINALD G BRAGDON/Supervisory Patent Examiner, Art Unit 2139
rv
July 25, 2026
Prosecution Insights