DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to claims filed 03/27/2024.
Claims 1-20 are pending.
Specification
The disclosure is objected to because of the following informalities: several misspellings or omitted words. [0017] states, “Thus, there an existing technical problem…” needs an “is”. [0020] states, “This access this extra field….” Should be “To access this extra field…”. Other similar errors are present. Examiner recommends reviewing the document for all minor informalities.
Appropriate correction is required.
The use of the terms Apple, Vx Works, and WiMax, which are a trade name or a mark used in commerce, has been noted in this application. The term should be accompanied by the generic terminology; furthermore, the term should be capitalized wherever it appears or, where appropriate, include a proper symbol indicating use in commerce such as ™, SM, or ® following the term.
Although the use of trade names and marks used in commerce (i.e., trademarks, service marks, certification marks, and collective marks) are permissible in patent applications, the proprietary nature of the marks should be respected and every effort made to prevent their use in any manner which might adversely affect their validity as commercial marks.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 1-5 and 11-20 are rejected under 35 U.S.C. 103 as being unpatentable over Szubbocsev Pub. No. US 11438171 B2 (hereafter Szubbocsev) in view of Jean et al. Pub. No. US 11442634 B2 (hereafter Jean).
With regards to claim 1, Szubbocsev teaches a method for managing access to a memory device of a data processing system that is shared between a plurality of abstracted resources hosted on the data processing system, the method comprising: (assigning the first device-specific cryptographic key to a first virtual machine associated with the memory device, assigning the second device-specific cryptographic key to a second virtual machine associated with the memory device and different from the first virtual machine col 15 lines 35-40)obtaining a memory device authentication request from a virtual machine (VM) being hosted on the data processing system, (At 705, the memory device may receive a first cryptographic key from a first virtual machine associated with a memory device Col 17 lines 42-44 )the memory device authentication request comprising at least a VM secured portion access key unique to the VM, a write counter, and write data; (generating a first device-specific cryptographic key based on a first partition of a memory device…assigning the first device-specific cryptographic key to a first virtual machine associated with the memory device col 15 lines 31-33, 35-37. generating a second device-specific cryptographic key based on a second partition of the memory device...assigning the second device-specific cryptographic key to a second virtual machine associated with the memory device and different from the first virtual machine col 15 lines 33-35, 37-40. For uniqueness, because the first cryptographic key has been assigned to the first virtual machine, the first cryptographic key may not be assigned to another virtual machine associated with the memory device. In another example, the memory device may assign the second cryptographic key (e.g., as associated with the second partition of the memory device) to the second virtual machine. Like the first cryptographic key, the second cryptographic key may not be assigned to another virtual machine associated with the memory device. Col 7 lines 49-59)making a first determination that the VM has access to the memory device using the VM secured portion access key; (authenticating at least one of the first virtual machine or the second virtual machine based on respective ones of the first device-specific cryptographic key or the second device-specific cryptographic key col 15 lines 40-43. If the cryptographic key received from the virtual machine matches the cryptographic key associated with the corresponding partition in the memory device, then the identity of the virtual machine may be authenticated col 8 lines 21-25)in response to the first determination from a virtual machine (VM), (In the case where the identity of the virtual machine is authenticated (e.g., via key authentication component 360) and the code operating on the virtual machine is authenticated (e.g., via code authentication component 365), then the virtual machine may be authenticated, and access to the secure data stored in memory device 305 may be permitted col 12 lines 43-49 )Szubbocsev does not teach the write request comprising a write counter and write data, synchronizing the write request, or writing the write data to memory based on the write request sequence.However, in analogous art, Jean teaches obtaining a memory device write request
the memory device write request comprising (At 701, an RPMB command can be received, such as at a memory device from a host device. The RPMB command can include an RPMB write command, an RPMB read command, or one or more other RPMB commands col 11 lines 34-37) a write counter (the RPMB command comprising an RPMB data frame, the RPMB data frame comprising 8 write counter bytes, wherein the RPMB circuit is configured to implement a counter and to verify the order of an RPMB write command with the received counter bytes and the counter. the RPMB command comprising an RPMB data frame, the RPMB data frame comprising 8 write counter bytes, wherein the RPMB circuit is configured to implement a counter and to verify the order of an RPMB write command with the received counter bytes and the counter. col 18 lines 18-23) and write data (providing the data bytes comprises providing a number (n) chunks of data, the n chunks of data consisting of all of the data bytes for a single read or write transfer. col 19 lines 37-40.)
synchronizing the memory device write request into a write request sequence using the write counter and writing the write data to the memory device based on the write request sequence. (an RPMB command queue can be implemented, such as in a table or one or more other data structure, such as in the memory controller, control circuitry, the RPMB circuit, or one or more other component, further improving RPMB processes col 8 lines 56-61. The write commands can be queued in the order they are received, and the read commands can be performed out of order, so long as the write count associated with the RPMB write commands are maintained between the host device and the memory device. Col 11 lines 42-47).It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the virtualized memory-access system of Szubbocsev with the RPMB command-queue and write-counter techniques of Jean resulting in a system with VM authentication and access control and protected memory writes with a write-counter and replay protection.A person of ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, to use the VM-specific authentication and access-control mechanism together with the RPMB write-counter and command-queue mechanism to provide authenticated, replay-protected writes by multiple virtual machines to a shared memory device ensuring that messages cannot be captured by an attacker and then later replayed (in at least Jean col 2 lines 63-64)
With regards to claim 2, Jean teaches wherein the memory device write request is for writing the write data into a secured portion of the memory device, writing the write data to the memory device comprises writing the write data into a field of the secured portion, the memory device is non-volatile memory, the secured portion is a relay protected memory block (RPMB) of the non-volatile memory. (FIG. 2 illustrates an example portion of a system 200 including a host device 205, a memory device 210, and a communication interface (I/F) 215. The memory device 210 can include a non-volatile memory (NVM) device 212 and control circuitry, such as a memory controller (MEM CTRL) 211 or circuits or control logic, and can provide data from the NVM device 212 to the host device 205, or receive data from the host device 205 to be stored on the NVM device 212, using the communication interface 215. Col 3 lines 50-58. Writes to an RPMB portion of memory can be authenticated using a key/mac (message authentication code), such as a HMAC SHA-256 algorithm calculated from a security key (e.g., programmed into a host device or a memory device) and a counter value that is incremented each time the RPMB portion of memory is written. Col 2 lines 57-62).
With regards to claim 3, Jean teaches wherein the method is performed by a management entity hosted by the data processing system, and, among all other components and resources of the data processing system including the VM, only the management entity is able to access the RPMB of the memory device. (The host device 205 can include a host Replay Protected Memory Block (RPMB) circuit 216 configured to adapt host data (e.g., encrypt) for communication to the memory device 210. Jean Col 4 lines 19-23. If a valid command is confirmed, the memory device RPMB circuit 218 can enable communication of RPMB data between the host device 205 and the RPMB partition 221. In an example, the memory device RPMB circuit 218 and the host RPMB circuit 216 can include RPMB access logic, including an authentication key circuit (e.g., one-time password (OTP)), a write counter, or one or more other circuits or logic col 4 lines 31-39 Examiner notes that the RPMB circuit is the dedicated communicator between the host and the RPMB partition. )Szubbocsev teaches including the VM (The key engine 180 may be used to generate and associate one or more cryptographic keys with corresponding partitions of (e.g., groups of memory cells within) device 105. The cryptographic keys may then be assigned to one or more virtual machines coupled with device 105. (col 5 lines 31 - 35) The cryptographic engine 182 may be used during an authentication process to authenticate the identity of, or the code operating on, one or more virtual machines connected to device 105. col 5 lines 50-53 Examiner notes that the management entity is the combination of the key engine and the cryptographic engine)It would have been obvious to a person have ordinary skill in the art prior to the effective filing date of the claimed invention to combine the key/cryptographic engine of Szubbocsev to provide the VM authentication and key-assignment functionality with the host RPMB circuit of Jean to provide management entity only access to the protected RPMB for secure writes. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success for the purpose of allowing a portion of memory to be accessed with a hidden security key, providing secure storage for the host device to protect crucial programs or data, as well as enable copy protection. RPMB can provide a secure way to exchange information and avoid man-in-the-middle attacks (in at least Jean Col 2 lines 48-52)
With regards to claim 4, Szubbocsev teaches wherein the VM secured portion access key unique to the VM is created and provisioned to the VM by a VM key engine of the management entity, (The key engine 180 may be used to generate and associate one or more cryptographic keys with corresponding partitions of (e.g., groups of memory cells within) device 105. The cryptographic keys may then be assigned to one or more virtual machines coupled with device 105. The cryptographic keys may be used to authenticate or verify the identity of, or code operating on, one or more virtual machines, the device 105 itself, or a combination thereof Col 5 lines 31-38).Jean teaches and operations of the management entity are not accessible to a user of the data processing system through an operating system of the data processing system. (The memory device 210 can include a memory device Replay Protected Memory Block (RPMB) circuit 218 (or other logic or crypto cell) configured to receive the adapted host data, such as through one or more buffer, etc., from the communication interface 215, and check such request for access to a protected partition of the NVM device 212, such as an RPMB partition 221 separate from a user partition or other portion of the NVM 213. If a valid command is confirmed, the memory device RPMB circuit 218 can enable communication of RPMB data between the host device 205 and the RPMB partition 221 Col 4 lines 24-31 Examiner notes that this circuit 218 has exclusive access to the protected partition and is separate from a user partition or other portion.)It would have been obvious to a person have ordinary skill in the art prior to the effective filing date of the claimed invention to combine the secure access portion keys provisioned from the management entity key engine to the VM of Szubbocsev with the host RPMB circuit of Jean to provide management entity only access to the protected RPMB for secure writes. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success for the purpose of allowing a portion of memory to be accessed with a hidden security key, providing secure storage for the host device to protect crucial programs or data, as well as enable copy protection. RPMB can provide a secure way to exchange information and avoid man-in-the-middle attacks (in at least Jean Col 2 lines 48-52).
With regards to claim 5, Szubbocsev teaches wherein making a first determination that the VM has access to the memory device using the VM secured portion access key comprises: making a second determination that the VM secured portion access key included in the memory device write request matches a VM secured portion access key that was previously issued to the VM before the obtaining of the memory device write request. (At 240, the memory device may receive a command signed with the cryptographic key from the virtual machine. The memory device may verify the identity of the virtual machines by comparing the received command containing the cryptographic key from the virtual machine with the cryptographic key that was assigned to the virtual machine at 220. Because the cryptographic key may be associated with a single virtual machine (e.g., as assigned in 220), if the cryptographic key received from the virtual machine matches the cryptographic key associated with the corresponding partition in the memory device, then the identity of the virtual machine may be authenticated. However, in the case that the cryptographic key received from the virtual machine does not match the cryptographic key assigned to the virtual machine (e.g., the keys are not the same), the virtual machine may not be authenticated, and access to the memory device may be prohibited. Col 8 lines 14-30)
With regards to claim 11, Szubbocsev teaches A non-transitory machine-readable medium having instructions stored therein, which when executed by a processor, cause the processor to perform operations for managing access to a memory device of a data processing system that is shared between a plurality of abstracted resources hosted on the data processing system, the operations comprising: (The apparatus may include features, means, or instructions (e.g., a non-transitory computer-readable medium storing instructions executable by a processor) Col 15 lines 28-31)obtaining a memory device authentication request from a virtual machine (VM) being hosted on the data processing system (At 705, the memory device may receive a first cryptographic key from a first virtual machine associated with a memory device Col 17 lines 42-44 )the memory device authentication request comprising at least a VM secured portion access key unique to the VM, a write counter, and write data; (generating a first device-specific cryptographic key based on a first partition of a memory device…assigning the first device-specific cryptographic key to a first virtual machine associated with the memory device col 15 lines 31-33, 35-37. generating a second device-specific cryptographic key based on a second partition of the memory device...assigning the second device-specific cryptographic key to a second virtual machine associated with the memory device and different from the first virtual machine col 15 lines 33-35, 37-40. For uniqueness, because the first cryptographic key has been assigned to the first virtual machine, the first cryptographic key may not be assigned to another virtual machine associated with the memory device. In another example, the memory device may assign the second cryptographic key (e.g., as associated with the second partition of the memory device) to the second virtual machine. Like the first cryptographic key, the second cryptographic key may not be assigned to another virtual machine associated with the memory device. Col 7 lines 49-59)making a first determination that the VM has access to the memory device using the VM secured portion access key; (authenticating at least one of the first virtual machine or the second virtual machine based on respective ones of the first device-specific cryptographic key or the second device-specific cryptographic key col 15 lines 40-43. If the cryptographic key received from the virtual machine matches the cryptographic key associated with the corresponding partition in the memory device, then the identity of the virtual machine may be authenticated col 8 lines 21-25)in response to the first determination from a virtual machine (VM), (In the case where the identity of the virtual machine is authenticated (e.g., via key authentication component 360) and the code operating on the virtual machine is authenticated (e.g., via code authentication component 365), then the virtual machine may be authenticated, and access to the secure data stored in memory device 305 may be permitted col 12 lines 43-49 )Szubbocsev does not teach the write request comprising a write counter and write data, synchronizing the write request, or writing the write data to memory based on the write request sequence.However, in analogous art, Jean teaches obtaining a memory device write request the memory device write request comprising (At 701, an RPMB command can be received, such as at a memory device from a host device. The RPMB command can include an RPMB write command, an RPMB read command, or one or more other RPMB commands col 11 lines 34-37) at least a VM secured portion access key unique to the VM, a write counter (the RPMB command comprising an RPMB data frame, the RPMB data frame comprising 8 write counter bytes, wherein the RPMB circuit is configured to implement a counter and to verify the order of an RPMB write command with the received counter bytes and the counter. the RPMB command comprising an RPMB data frame, the RPMB data frame comprising 8 write counter bytes, wherein the RPMB circuit is configured to implement a counter and to verify the order of an RPMB write command with the received counter bytes and the counter. col 18 lines 18-23) and write data (providing the data bytes comprises providing a number (n) chunks of data, the n chunks of data consisting of all of the data bytes for a single read or write transfer. col 19 lines 37-40.)
synchronizing the memory device write request into a write request sequence using the write counter and writing the write data to the memory device based on the write request sequence. (an RPMB command queue can be implemented, such as in a table or one or more other data structure, such as in the memory controller, control circuitry, the RPMB circuit, or one or more other component, further improving RPMB processes col 8 lines 56-61. The write commands can be queued in the order they are received, and the read commands can be performed out of order, so long as the write count associated with the RPMB write commands are maintained between the host device and the memory device. Col 11 lines 42-47).It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the virtualized memory-access system of Szubbocsev with the RPMB command-queue and write-counter techniques of Jean resulting in a system with VM authentication and access control and protected memory writes with a write-counter and replay protection.A person of ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, to use the VM-specific authentication and access-control mechanism together with the RPMB write-counter and command-queue mechanism to provide authenticated, replay-protected writes by multiple virtual machines to a shared memory device ensuring that messages cannot be captured by an attacker and then later replayed (in at least Jean col 2 lines 63-64)
With regards to claim 12, Jean teaches wherein the memory device write request is for writing the write data into a secured portion of the memory device, writing the write data to the memory device comprises writing the write data into a field of the secured portion, the memory device is non-volatile memory, the secured portion is a relay protected memory block (RPMB) of the non-volatile memory. (FIG. 2 illustrates an example portion of a system 200 including a host device 205, a memory device 210, and a communication interface (I/F) 215. The memory device 210 can include a non-volatile memory (NVM) device 212 and control circuitry, such as a memory controller (MEM CTRL) 211 or circuits or control logic, and can provide data from the NVM device 212 to the host device 205, or receive data from the host device 205 to be stored on the NVM device 212, using the communication interface 215. Col 3 lines 50-58. Writes to an RPMB portion of memory can be authenticated using a key/mac (message authentication code), such as a HMAC SHA-256 algorithm calculated from a security key (e.g., programmed into a host device or a memory device) and a counter value that is incremented each time the RPMB portion of memory is written. Col 2 lines 57-62).
With regards to claim 13, Jean teaches wherein the operations are performed by a management entity hosted by the data processing system, and, among all other components and resources of the data processing system including the VM, only the management entity is able to access the RPMB of the memory device. (The host device 205 can include a host Replay Protected Memory Block (RPMB) circuit 216 configured to adapt host data (e.g., encrypt) for communication to the memory device 210. Jean Col 4 lines 19-23. If a valid command is confirmed, the memory device RPMB circuit 218 can enable communication of RPMB data between the host device 205 and the RPMB partition 221. In an example, the memory device RPMB circuit 218 and the host RPMB circuit 216 can include RPMB access logic, including an authentication key circuit (e.g., one-time password (OTP)), a write counter, or one or more other circuits or logic col 4 lines 31-39 Examiner notes that the RPMB circuit is the dedicated communicator between the host and the RPMB partition. )Szubbocsev teaches including the VM (The key engine 180 may be used to generate and associate one or more cryptographic keys with corresponding partitions of (e.g., groups of memory cells within) device 105. The cryptographic keys may then be assigned to one or more virtual machines coupled with device 105. (col 5 lines 31 - 35) The cryptographic engine 182 may be used during an authentication process to authenticate the identity of, or the code operating on, one or more virtual machines connected to device 105. col 5 lines 50-53 Examiner notes that the management entity is the combination of the key engine and the cryptographic engine)It would have been obvious to a person have ordinary skill in the art prior to the effective filing date of the claimed invention to combine the key/cryptographic engine of Szubbocsev to provide the VM authentication and key-assignment functionality with the host RPMB circuit of Jean to provide management entity only access to the protected RPMB for secure writes. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success for the purpose of allowing a portion of memory to be accessed with a hidden security key, providing secure storage for the host device to protect crucial programs or data, as well as enable copy protection. RPMB can provide a secure way to exchange information and avoid man-in-the-middle attacks (in at least Jean Col 2 lines 48-52)
With regards to claim 14, Szubbocsev teaches wherein the VM secured portion access key unique to the VM is created and provisioned to the VM by a VM key engine of the management entity, and operations of the management entity are not accessible to a user of the data processing system through an operating system of the data processing system. (The key engine 180 may be used to generate and associate one or more cryptographic keys with corresponding partitions of (e.g., groups of memory cells within) device 105. The cryptographic keys may then be assigned to one or more virtual machines coupled with device 105. The cryptographic keys may be used to authenticate or verify the identity of, or code operating on, one or more virtual machines, the device 105 itself, or a combination thereof Col 5 lines 31-38).Jean teaches and operations of the management entity are not accessible to a user of the data processing system through an operating system of the data processing system. (The memory device 210 can include a memory device Replay Protected Memory Block (RPMB) circuit 218 (or other logic or crypto cell) configured to receive the adapted host data, such as through one or more buffer, etc., from the communication interface 215, and check such request for access to a protected partition of the NVM device 212, such as an RPMB partition 221 separate from a user partition or other portion of the NVM 213. If a valid command is confirmed, the memory device RPMB circuit 218 can enable communication of RPMB data between the host device 205 and the RPMB partition 221 Col 4 lines 24-31 Examiner notes that this circuit 218 has exclusive access to the protected partition and is separate from a user partition or other portion.)It would have been obvious to a person have ordinary skill in the art prior to the effective filing date of the claimed invention to combine the secure access portion keys provisioned from the management entity key engine to the VM of Szubbocsev with the host RPMB circuit of Jean to provide management entity only access to the protected RPMB for secure writes. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success for the purpose of allowing a portion of memory to be accessed with a hidden security key, providing secure storage for the host device to protect crucial programs or data, as well as enable copy protection. RPMB can provide a secure way to exchange information and avoid man-in-the-middle attacks (in at least Jean Col 2 lines 48-52).
With regards to claim 15, Szubbocsev teaches wherein making a first determination that the VM has access to the memory device using the VM secured portion access key comprises: making a second determination that the VM secured portion access key included in the memory device write request matches a VM secured portion access key that was previously issued to the VM before the obtaining of the memory device write request. (At 240, the memory device may receive a command signed with the cryptographic key from the virtual machine. The memory device may verify the identity of the virtual machines by comparing the received command containing the cryptographic key from the virtual machine with the cryptographic key that was assigned to the virtual machine at 220. Because the cryptographic key may be associated with a single virtual machine (e.g., as assigned in 220), if the cryptographic key received from the virtual machine matches the cryptographic key associated with the corresponding partition in the memory device, then the identity of the virtual machine may be authenticated. However, in the case that the cryptographic key received from the virtual machine does not match the cryptographic key assigned to the virtual machine (e.g., the keys are not the same), the virtual machine may not be authenticated, and access to the memory device may be prohibited. Col 8 lines 14-30)
With regards to claim 16, Szubbocsev teaches A data processing system comprising: a processor; and a memory device coupled to the processor, wherein memory device stores instructions that causes the data processing system to perform operations for managing access to the memory device, the memory device being shared between a plurality of abstracted resources hosted on the data processing system, the operations comprising: (The functions described herein may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium Col 22 lines 11-16)obtaining a memory device authentication request from a virtual machine (VM) being hosted on the data processing system (At 705, the memory device may receive a first cryptographic key from a first virtual machine associated with a memory device Col 17 lines 42-44 )the memory device authentication request comprising at least a VM secured portion access key unique to the VM, a write counter, and write data; (generating a first device-specific cryptographic key based on a first partition of a memory device…assigning the first device-specific cryptographic key to a first virtual machine associated with the memory device col 15 lines 31-33, 35-37. generating a second device-specific cryptographic key based on a second partition of the memory device...assigning the second device-specific cryptographic key to a second virtual machine associated with the memory device and different from the first virtual machine col 15 lines 33-35, 37-40. For uniqueness, because the first cryptographic key has been assigned to the first virtual machine, the first cryptographic key may not be assigned to another virtual machine associated with the memory device. In another example, the memory device may assign the second cryptographic key (e.g., as associated with the second partition of the memory device) to the second virtual machine. Like the first cryptographic key, the second cryptographic key may not be assigned to another virtual machine associated with the memory device. Col 7 lines 49-59)making a first determination that the VM has access to the memory device using the VM secured portion access key; (authenticating at least one of the first virtual machine or the second virtual machine based on respective ones of the first device-specific cryptographic key or the second device-specific cryptographic key col 15 lines 40-43. If the cryptographic key received from the virtual machine matches the cryptographic key associated with the corresponding partition in the memory device, then the identity of the virtual machine may be authenticated col 8 lines 21-25)in response to the first determination from a virtual machine (VM), (In the case where the identity of the virtual machine is authenticated (e.g., via key authentication component 360) and the code operating on the virtual machine is authenticated (e.g., via code authentication component 365), then the virtual machine may be authenticated, and access to the secure data stored in memory device 305 may be permitted col 12 lines 43-49 )Szubbocsev does not teach the write request comprising a write counter and write data, synchronizing the write request, or writing the write data to memory based on the write request sequence.However, in analogous art, Jean teaches obtaining a memory device write request the memory device write request comprising (At 701, an RPMB command can be received, such as at a memory device from a host device. The RPMB command can include an RPMB write command, an RPMB read command, or one or more other RPMB commands col 11 lines 34-37) at least a VM secured portion access key unique to the VM, a write counter (the RPMB command comprising an RPMB data frame, the RPMB data frame comprising 8 write counter bytes, wherein the RPMB circuit is configured to implement a counter and to verify the order of an RPMB write command with the received counter bytes and the counter. the RPMB command comprising an RPMB data frame, the RPMB data frame comprising 8 write counter bytes, wherein the RPMB circuit is configured to implement a counter and to verify the order of an RPMB write command with the received counter bytes and the counter. col 18 lines 18-23) and write data (providing the data bytes comprises providing a number (n) chunks of data, the n chunks of data consisting of all of the data bytes for a single read or write transfer. col 19 lines 37-40.)
synchronizing the memory device write request into a write request sequence using the write counter and writing the write data to the memory device based on the write request sequence. (an RPMB command queue can be implemented, such as in a table or one or more other data structure, such as in the memory controller, control circuitry, the RPMB circuit, or one or more other component, further improving RPMB processes col 8 lines 56-61. The write commands can be queued in the order they are received, and the read commands can be performed out of order, so long as the write count associated with the RPMB write commands are maintained between the host device and the memory device. Col 11 lines 42-47).It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to combine the virtualized memory-access system of Szubbocsev with the RPMB command-queue and write-counter techniques of Jean resulting in a system with VM authentication and access control and protected memory writes with a write-counter and replay protection.A person of ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, to use the VM-specific authentication and access-control mechanism together with the RPMB write-counter and command-queue mechanism to provide authenticated, replay-protected writes by multiple virtual machines to a shared memory device ensuring that messages cannot be captured by an attacker and then later replayed (in at least Jean col 2 lines 63-64)
With regards to claim 17, Jean teaches wherein the memory device write request is for writing the write data into a secured portion of the memory device, writing the write data to the memory device comprises writing the write data into a field of the secured portion, the memory device is non-volatile memory, the secured portion is a relay protected memory block (RPMB) of the non-volatile memory. (FIG. 2 illustrates an example portion of a system 200 including a host device 205, a memory device 210, and a communication interface (I/F) 215. The memory device 210 can include a non-volatile memory (NVM) device 212 and control circuitry, such as a memory controller (MEM CTRL) 211 or circuits or control logic, and can provide data from the NVM device 212 to the host device 205, or receive data from the host device 205 to be stored on the NVM device 212, using the communication interface 215. Col 3 lines 50-58. Writes to an RPMB portion of memory can be authenticated using a key/mac (message authentication code), such as a HMAC SHA-256 algorithm calculated from a security key (e.g., programmed into a host device or a memory device) and a counter value that is incremented each time the RPMB portion of memory is written. Col 2 lines 57-62).
With regards to claim 18, Szubbocsev and Jean teach wherein the operations are performed by a management entity hosted by the data processing system, and, among all other components and resources of the data processing system including the VM, only the management entity is able to access the RPMB of the memory device. (The host device 205 can include a host Replay Protected Memory Block (RPMB) circuit 216 configured to adapt host data (e.g., encrypt) for communication to the memory device 210. Jean Col 4 lines 19-23. If a valid command is confirmed, the memory device RPMB circuit 218 can enable communication of RPMB data between the host device 205 and the RPMB partition 221. In an example, the memory device RPMB circuit 218 and the host RPMB circuit 216 can include RPMB access logic, including an authentication key circuit (e.g., one-time password (OTP)), a write counter, or one or more other circuits or logic col 4 lines 31-39 Examiner notes that the RPMB circuit is the dedicated communicator between the host and the RPMB partition. )Szubbocsev teaches including the VM (The key engine 180 may be used to generate and associate one or more cryptographic keys with corresponding partitions of (e.g., groups of memory cells within) device 105. The cryptographic keys may then be assigned to one or more virtual machines coupled with device 105. (col 5 lines 31 - 35) The cryptographic engine 182 may be used during an authentication process to authenticate the identity of, or the code operating on, one or more virtual machines connected to device 105. col 5 lines 50-53 Examiner notes that the management entity is the combination of the key engine and the cryptographic engine)It would have been obvious to a person have ordinary skill in the art prior to the effective filing date of the claimed invention to combine the key/cryptographic engine of Szubbocsev to provide the VM authentication and key-assignment functionality with the host RPMB circuit of Jean to provide management entity only access to the protected RPMB for secure writes. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success for the purpose of allowing a portion of memory to be accessed with a hidden security key, providing secure storage for the host device to protect crucial programs or data, as well as enable copy protection. RPMB can provide a secure way to exchange information and avoid man-in-the-middle attacks (in at least Jean Col 2 lines 48-52)
With regards to claim 19, Szubbocsev teaches wherein the VM secured portion access key unique to the VM is created and provisioned to the VM by a VM key engine of the management entity, and operations of the management entity are not accessible to a user of the data processing system through an operating system of the data processing system. (The key engine 180 may be used to generate and associate one or more cryptographic keys with corresponding partitions of (e.g., groups of memory cells within) device 105. The cryptographic keys may then be assigned to one or more virtual machines coupled with device 105. The cryptographic keys may be used to authenticate or verify the identity of, or code operating on, one or more virtual machines, the device 105 itself, or a combination thereof Col 5 lines 31-38).Jean teaches and operations of the management entity are not accessible to a user of the data processing system through an operating system of the data processing system. (The memory device 210 can include a memory device Replay Protected Memory Block (RPMB) circuit 218 (or other logic or crypto cell) configured to receive the adapted host data, such as through one or more buffer, etc., from the communication interface 215, and check such request for access to a protected partition of the NVM device 212, such as an RPMB partition 221 separate from a user partition or other portion of the NVM 213. If a valid command is confirmed, the memory device RPMB circuit 218 can enable communication of RPMB data between the host device 205 and the RPMB partition 221 Col 4 lines 24-31 Examiner notes that this circuit 218 has exclusive access to the protected partition and is separate from a user partition or other portion.)It would have been obvious to a person have ordinary skill in the art prior to the effective filing date of the claimed invention to combine the secure access portion keys provisioned from the management entity key engine to the VM of Szubbocsev with the host RPMB circuit of Jean to provide management entity only access to the protected RPMB for secure writes. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success for the purpose of allowing a portion of memory to be accessed with a hidden security key, providing secure storage for the host device to protect crucial programs or data, as well as enable copy protection. RPMB can provide a secure way to exchange information and avoid man-in-the-middle attacks (in at least Jean Col 2 lines 48-52).
With regards to claim 20, Szubbocsev teaches wherein making a first determination that the VM has access to the memory device using the VM secured portion access key comprises: making a second determination that the VM secured portion access key included in the memory device write request matches a VM secured portion access key that was previously issued to the VM before the obtaining of the memory device write request. (At 240, the memory device may receive a command signed with the cryptographic key from the virtual machine. The memory device may verify the identity of the virtual machines by comparing the received command containing the cryptographic key from the virtual machine with the cryptographic key that was assigned to the virtual machine at 220. Because the cryptographic key may be associated with a single virtual machine (e.g., as assigned in 220), if the cryptographic key received from the virtual machine matches the cryptographic key associated with the corresponding partition in the memory device, then the identity of the virtual machine may be authenticated. However, in the case that the cryptographic key received from the virtual machine does not match the cryptographic key assigned to the virtual machine (e.g., the keys are not the same), the virtual machine may not be authenticated, and access to the memory device may be prohibited. Col 8 lines 14-30)
Claims 6 is rejected under 35 U.S.C. 103 as being unpatentable over Szubbocsev Pub. No. US 11438171 B2(hereafter Szubbocsev) in view of Jean et al. Pub. No. US 11442634 B2 (hereafter Jean) as applied to claims 1-5 and 11-20 above and in further view of Sela et al. Pub. No. US 2020/0014544 A1 (hereafter Sela)
With regards to claim 6, Szubbocsev teaches wherein making a first determination that the VM has access to the memory device using the VM secured portion access key further comprises: after the second determination, retrieving a first secured portion key from a secured portion of the memory device (a memory device may generate a first symmetric cryptographic key and store the first cryptographic key in the memory device. In some cases, the first cryptographic key may be stored in the first partition of the memory device. Szubbocsev Col 6 lines 53-57)Szubbocsev does not teach making a third determination by getting a second key from a remote system and comparing the two keys.However, in analogous art, Sela teaches and a second secured portion key from a data processing system manager that is remote to the data processing system; making a third determination that the first secured portion key matches the second secured portion key (The RPMB feature is based on a symmetric key which resides in both the storage device and the entity (e.g. host SoC, remote server, etc. ¶[0045] Accordingly, the remote server may have a higher authenticity hierarchy, where the RPMB write key is stored and provided by the remote server only ¶[0049]).
It would have been obvious to a person have ordinary skill in the art prior to the effective filing date of the claimed invention to combine the VM security and architecture of Szubbocsev and the resulting synchronization of write data of Jean with the remote server RPMB key of Sela to provide a higher authentication process to the protected RPMB storage.A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success for the purpose of allowing write access to be limited to one entity (such as a remote server)…a remote server may securely update data stored in RPMB (such as image version data, certificates, keys, etc.) with authentication that updates are from the remote server (in at least Sela [0021])Jean teaches and in response to the third determination, initiate synchronization of the write data to the secured portion of the memory device. (the write commands can be queued in the order they are received…so long as the write count associated with the RPMB write commands are maintained between the host device and the memory device. Jean Col 11 lines 42-47).It would have been obvious to a person have ordinary skill in the art prior to the effective filing date of the claimed invention to combine a third determination that a second secured portion access key from a remote server matching the first secured portion access key of Sela before initiating the synchronization of the write data of Jean to provide a higher authentication process to the protected RPMB storage.A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success for the purpose of allowing a portion of memory to be accessed with a hidden security key, providing secure storage for the host device to protect crucial programs or data, as well as enable copy protection. RPMB can provide a secure way to exchange information and avoid man-in-the-middle attacks (in at least Jean Col 2 lines 48-52).
Claims 7 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Szubbocsev Pub. No. US 11438171 B2(hereafter Szubbocsev) in view of Jean et al. Pub. No. US 11442634 B2 (hereafter Jean) and in further view of Sela et al. Pub. No. US 2020/0014544 A1 (hereafter Sela) as applied to claim 6 above and in further view of Cariello et al. Pub. No. US 11321468 B2 (hereafter Cariello)
With regards to claim 7, Szubbocsev teaches wherein the first secured portion key is stored in (a memory device may generate a first symmetric cryptographic key and store the first cryptographic key in the memory device. In some cases, the first cryptographic key may be stored in the first partition of the memory device. Szubbocsev Col 6 lines 53-57) Szubbocsev does not teach an extra field provisioned in the secured portion of the memory device.However, in analogous art, Cariello teaches an extra field provisioned in the secured portion of the memory device, the memory device is non-volatile memory, the secured portion is a relay protected memory block (RPMB) of the non-volatile memory. (providing an exclusive and secure access to a dedicated sub region within the replay protected memory block (RPMB) of a managed memory device… the dedicated sub region can be hidden to the normal user being associated to an arbitrary protocol ID during its initialization and key programing…. Col 14 lines 4-11and Each RPMB region has a dedicated authentication key. Col 5 lines 55-56)It would have been obvious to a person have ordinary skill in the art prior to the effective filing date of the claimed invention to combine the VM/RPMB security and architecture of Szubbocsevwith the extra field for an RPMB key of Cariello to provide a higher authentication process to the protected RPMB storage.A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success for the purpose of an exclusive and secure access to a dedicated sub region within protected memory of a managed memory device (in at least Cariello col 3 lines 53-56).
With regards to claim 8, Szubbocsev teaches wherein retrieving the first secured portion key from the secured portion of the memory device comprises (a memory device may generate a first symmetric cryptographic key and store the first cryptographic key in the memory device. In some cases, the first cryptographic key may be stored in the first partition of the memory device. Szubbocsev Col 6 lines 53-57) using a third secured portion key different from the first secured portion key and the second secured portion key to access the secured portion of the memory device. (a memory device may generate a third cryptographic key, which may be a symmetric cryptographic key, an asymmetric cryptographic key, or another type of cryptographic key….the first and second keys may be generated, stored in, and associated with the first and second partitions, which both include some number of memory cells based on respective sizes of the first and second partitions. In this case, the third cryptographic key may be associated with at least a portion of the remaining memory cells in the memory device. Col 7 lines 13 – 16, 32-38)
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Szubbocsev Pub. No. US 11438171 B2(hereafter Szubbocsev) in view of Jean et al. Pub. No. US 11442634 B2 (hereafter Jean) as applied to claims 1-5 and 11-20 above and in further view of Sela et al. Pub. No. US 2020/0014544 A1 (hereafter Sela) as applied to claims 6-8 and in further view of Sun Pub. No. US 2019/0163913 A1 (hereafter Sun)
With regards to claim 9, Jean teaches wherein the write counter and write data of the memory device write request are encrypted using an encryption protocol. (Writes to an RPMB portion of memory can be authenticated using a key/mac (message authentication code), such as a HMAC SHA-256 algorithm calculated from a security key… and a counter value that is incremented each time the RPMB portion of memory is written. Col 2 lines 57-62).Jean does not teach that the write data and write counter are necessarily encrypted using an encryption protocol.However, in analogous art, Sun teaches wherein the write counter and write data of the memory device write request are encrypted using an encryption protocol. (the data to be written and the write counter are encrypted by using the root key of the processor stored in the secure memory… ¶[0079]).It would have been obvious to a person have ordinary skill in the art prior to the effective filing date of the claimed invention to combine the hmac sha-256 algorithm calculated from a security key for writes to an RPMB portion of Jean with the encryption of the write data and write counter of Sun resulting in a system with further security and protected access to the secure portion of memory. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success so that the writing process verification between the processor and the memory is ensured, thus preventing data to be written from being illegally modified during a transmission process. (In at least Sun ¶[0084])
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Szubbocsev Pub. No. US 11438171 B2(hereafter Szubbocsev) in view of Jean et al. Pub. No. US 11442634 B2 (hereafter Jean) as applied to claims 1-5 and 11-20 above and in further view of Anumala et al. Pub. No. WO 2024/168567 A1 (hereafter Anumala)
With regards to claim 10, Szubbocsev teaches wherein the write request sequence includes a plurality of memory device write requests received from different ones a plurality of VMs hosted by the data processing system, the VM being one of the plurality of VMs (The cryptographic keys may then be assigned to one or more virtual machines coupled with device 105. col 5 lines 31 – 35. Both key engine 180 and cryptographic engine 182 may be used to authenticate multiple virtual machines connected to device 105. Col 6 lines 3-5). the memory device write request being one of the plurality of memory device write requests, each of the plurality of memory device write requests comprises respective ones of the VM secured portion access key unique to each of the plurality of VMs, (For uniqueness, because the first cryptographic key has been assigned to the first virtual machine, the first cryptographic key may not be assigned to another virtual machine associated with the memory device. Col 7 lines 49-59) Jean teaches the memory device write request being one of the plurality of memory device write requests (The write commands can be queued in the order they are received…. the RPMB operations can be performed in order. Col 11 lines 42-43, 52)
comprises respective ones of the VM secured portion access key unique to each of the plurality of VMs, the write counter, and the write data, (the RPMB data frame comprising 8 write counter bytes…. header bytes, consisting of 32-64 bytes of data; data bytes following the header bytes; and message authentication code (MAC) bytes following the data bytes. Col 18 lines 19-20, 25-28) and writing the write data to the memory device based on the write request sequence comprises using the write counter included respective ones of the plurality of memory device write requests to ensure that all of the plurality of memory device write requests are written into the memory device. (the write commands can be queued in the order they are received…so long as the write count associated with the RPMB write commands are maintained between the host device and the memory device. Col 11 lines 42-47).Szubbocsev and Jean do not teach using the write counter included respective ones of the plurality of memory device write requests.However, in analogous art, Anumala teaches using the write counter included respective ones of the plurality of memory device write requests (the memory system 330 may separately track a write counter for each RPMB region 334A-D...the memory system 330 may separately store an authentication key for each RPMB region 334A-D ¶[0046]).It would have been obvious to a person have ordinary skill in the art prior to the effective filing date of the claimed invention to combine the assignment of device-specific cryptographic keys to different virtual machines for controlling access to a shared memory device of Szubbocsev and the use of an RPMB command queue and write counter for authenticated memory operations of Jean with the authentication of access requests to protected RPMB memory by a requesting virtual machine of Anumala to provide secure, authenticated access to protected memory by different virtual machines while maintaining protection against unauthorized memory operations. A person having ordinary skill in the art would have been motivated to make this combination, with a reasonable expectation of success, to provide improved confidentiality of user data by reducing the likelihood of, or preventing, a threat actor obtaining unauthorized access to secure data stored in a replay protected memory block (RPMB) portion of a memory module. (in at least ¶[0023])
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Todd Jeffrey Johnson whose telephone number is (571)270-0929. The examiner can normally be reached M-F, 7:30am to 5pm ET.
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, Bradley Teets can be reached at (571) 272-3338. 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.
/T.J.J./Examiner, Art Unit 2197
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197
Prosecution Insights