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 10/13/2025 has been entered.
Claims 1-3 and 5-20 are pending and being considered.
Claims 1, 5 and 10 have been amended.
Claim 4 have been canceled.
Claim Objections
Claims 1, 7-10, 13 and 16-20 objected to because of the following informalities:
Claims 1, 7-10, 13 and 16-20 recites “the second command” should read as “the at least one second command”
Claim 10 recites “the second command including a signature generated using a portion of the second command that is configured to be executed in the memory device to implement the function, wherein the function is implemented by execution of the at least one second command in the memory device” the examiner notes that the claim recited repeated limitation as shown above. Appropriate correction is required.
Response to 103
Applicant’s arguments filed on 10/13/2025 have been fully considered and are not persuasive.
Argument regarding claims 1, 10 and 19:
Applicants’ argument regarding claims 1 and 10 have been considered and are not persuasive. In response to applicant’s arguments that the cited prior art Duval fails to teach “the second command including a signature generated using a portion of the second command, wherein the signature is a hash-based message authentication code generated for a message having the portion of the second command using a cryptographic key” the applicant argues that Duval fails to teach “the second command including a signature generated using a portion of the second command” the examiner respectfully disagrees because Duval explicitly teach the above argued limitation Duval on [0023-0026] teaches the signing device generates the digital signature by executing a cryptographic function, such as a hash function, using a cryptographic key, the command, and the current memory system counter value. See on [0031] teaches the generator device creates the pre-generated digital signature by executing a cryptographic operation using the signed command. See on [0050] teaches the cryptographic engine 142 can be configured to execute one or more cryptographic operations to generate digital signatures as described herein. The cryptographic engine 142 can be configured to generate digital signatures using any suitable cryptographic algorithm such as, for example, a cryptographic hash function such as an SHA algorithm (e.g., SHA256), the MD5 algorithm, etc. A cryptographic has function maps an input value to a, usually shorted, hash value. The hash function can be selected such that it is unlikely that two different input values will map to the same hash value. The cryptographic engine 142 can be configured to generate a digital signature by executing a hash function on an input value related to the thing being digitally signed.
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.
Claims 1 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Obr (US 9645752) in view of Duval (US 20200042465) and further in view of Shin et al (hereinafter Shin) (US 9152553).
Regarding claim 1 Obr teaches a method, comprising: (Obr on [col 2 line 59-65] teaches method);
receiving, in an abstraction layer implemented for memory devices (Obr Fig 2 and text on [col 7 line 26-55] teaches receiving write request along with identifiers (i.e., one or more parameters) used for generating notification command at abstraction layer of host operating system. A write request may correspond to any request to write data to the non-volatile memory 124 of storage system 120 (i.e., memory device). For example, a write request may include a request to write a data item to a specific file (i.e., request to perform function, wherein the function in instant case is write data function to specific file));
generating, by the abstraction layer using the one or more parameters, at least one first command in a format independent of a command timing, format, or syntax configuration of the memory device (Obr Fig 2 and text on [col 7 line 26-55] teaches the operating system processes the received write request, and transmits the request (i.e., at least one first command) to the device driver 116A. Though not shown within FIG. 2, one skilled in the art will appreciate that additional abstraction layers may exist within the host system 110, and there write requests may pass through abstraction layers before being received at the device driver 116A. Prior to transmitting the write request to the device driver 116A, the operating system 114A may supplement the write request with additional information regarding the application 112A, the data item associated with the write request, or the write request itself. For example, the operating system 114 may supplement the write request with an identity of the application 112A or a logical identifier of the data item requested to be written (e.g., a file descriptor, a record locator, or an object key of the data item). The device driver 116A may receive write requests from the operating system 114A without metadata (i.e., command independent of command timing, format or syntax));
identifying, by the abstraction layer, a device driver of the memory device (Obr Fig 2 and text on [col 7 line 26-55] teaches the operating system processes the received write request, and transmits the request (i.e., at least one first command) to the device driver 116A (i.e., identifying driver of memory device). Though not shown within FIG. 2, one skilled in the art will appreciate that various additional abstraction layers may exist within the host system 110, and there write requests may pass through multiple abstraction layers before being received at the device driver 116A.);
and transmitting the at least one first command to the device driver to cause the device driver to generate at least one second command to the memory device according to the command timing, format, or syntax configuration of the memory device, (Obr on [col 8 line 13-18, line 54-67 and col 9 line 1-25] teaches after receiving the write request, the device driver 116A generates the write command with an identifier (i.e., second command generated by device driver), which may subsequently be used in generating notifications regarding the write command or the corresponding data item. In one embodiment, the device driver 116A modifies the write command itself. The write command and corresponding data item, as modified to include an identifier, are transmitted to the controller 122 via the communication link. In one embodiment, the write command (i.e., according to command timing since its generated after receiving the write command from abstraction layer of the OS) is transmitted via SATA or other storage protocol over a storage bus. On receiving the write command and corresponding data item, the controller 122 caches the data item into the volatile cache memory 126 i.e., function is implemented in memory device by execution of write command).
Obr fails to explicitly teach memory devices configured with access control based on cryptography, generate at least one second command to the memory device, the second command including a signature generated using a portion of the second command, however Duval from analogous art teaches wherein at least two of the memory devices have a different command timing, format, or syntax configuration (Duval Fig 1 block 110A-110N and text on [0040] teaches features of the memory system 110A. The other memory systems 110B, 110N may include the same features, or different features. i.e., features of memory devices 110B and 110N may be different from feature of memory device 110A);
memory devices configured with access control based on cryptography (Duval on [0023-0026] teaches memory system configured with access controlled based on cryptography);
(Duval on [0023-0026] teaches memory generating a command and including a signature in the command to be transmitted to memory device. Further teaches the signing device generates the digital signature by executing a cryptographic function, such as a hash function, using a cryptographic key, the command, and the current memory system counter value. Further teaches verifies the digital signature by computing a cryptographic digest of the command from the command message, the current value of the memory system counter and a memory system cryptographic key. A cryptographic digest is the output of a hash function or other suitable cryptographic function that is executed at the memory system utilizing the command, the current value of the memory system counter, and the memory system cryptographic key. See on [0050] teaches the cryptographic engine 142 can be configured to execute one or more cryptographic operations to generate digital signatures as described herein. The cryptographic engine 142 can be configured to generate digital signatures using any suitable cryptographic algorithm such as, for example, a cryptographic hash function such as an SHA algorithm (e.g., SHA256), the MD5 algorithm, etc. A cryptographic has function maps an input value to a, usually shorted, hash value. The hash function can be selected such that it is unlikely that two different input values will map to the same hash value. The cryptographic engine 142 can be configured to generate a digital signature by executing a hash function on an input value related to the thing being digitally signed).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Duval into the teaching of Obr by generating by the device drive a command including a digital signature. One would be motivated to do so in order to validate the command using the digital signature (Duval [0022-0024]).
The combination of Obr and Duval fails to explicitly teach memory devices from different manufacturer, however Shin from analogous art teaches wherein at least two of the memory devices are manufactured by different manufacturers and have a different command timing, format, or syntax configuration (Shin on [col 3 line 56-64] teaches memory devices fabricated by different manufacturers require a different command to perform operation, some flash memory manufacturers may require a different number of commands and addresses or different timing to perform an operation than others. See on [col 8 line 5-10 and col 8 line 50-55] teaches the firmware 124 can be used to construct a descriptor defining a command sequence for controlling the memory devices 106a-d. For example, the descriptor can be constructed to describe a command sequence defining an operation (e.g., read, write, or erase) for a memory device. As mentioned above, the configuration of command sequences may vary based on the requirements of the memory device manufacturer).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Shin into the combined teaching of Obr and Duval by having different memory devices manducated by different manufacturer. One would be motivated to do so in order to perform operation using respective memory device based on the specification of respective manufacturer of the memory device (Shin [col 1 line 31-40]).
Regarding claim 10 Obr teaches a non-transitory computer readable storage medium storing instructions which when executed on a computing device, cause the computing device to perform a method, comprising: (Obr on [col 4 line 7-29 and claim 1] teaches non-volatile memory storing instruction executed by a processor);
receiving, in an abstraction layer implemented for memory devices (Obr Fig 2 and text on [col 7 line 26-55] teaches receiving write request along with identifiers (i.e., one or more parameters) used for generating notification command at abstraction layer of host operating system. A write request may correspond to any request to write data to the non-volatile memory 124 of storage system 120 (i.e., memory device). For example, a write request may include a request to write a data item to a specific file (i.e., request to perform function, wherein the function in instant case is write data function to specific file));
generating, by the abstraction layer using the one or more parameters, at least one first command in a format independent of a command timing, format, or syntax configuration of the memory device (Obr Fig 2 and text on [col 7 line 26-55] teaches the operating system processes the received write request, and transmits the request (i.e., at least one first command) to the device driver 116A. Though not shown within FIG. 2, one skilled in the art will appreciate that additional abstraction layers may exist within the host system 110, and there write requests may pass through abstraction layers before being received at the device driver 116A. Prior to transmitting the write request to the device driver 116A, the operating system 114A may supplement the write request with additional information regarding the application 112A, the data item associated with the write request, or the write request itself. For example, the operating system 114 may supplement the write request with an identity of the application 112A or a logical identifier of the data item requested to be written (e.g., a file descriptor, a record locator, or an object key of the data item). The device driver 116A may receive write requests from the operating system 114A without metadata (i.e., command independent of command timing, format or syntax));
identifying, by the abstraction layer, a device driver of the memory device (Obr Fig 2 and text on [col 7 line 26-55] teaches the operating system processes the received write request, and transmits the request (i.e., at least one first command) to the device driver 116A (i.e., identifying driver of memory device). Though not shown within FIG. 2, one skilled in the art will appreciate that various additional abstraction layers may exist within the host system 110, and there write requests may pass through multiple abstraction layers before being received at the device driver 116A.);
and sending the at least one first command to the device driver to cause the device driver to generate at least one second command to the memory device according to the command timing, format, or syntax configuration of the memory device, the second command(Obr on [col 8 line 13-18, line 54-67 and col 9 line 1-25] teaches after receiving the write request, the device driver 116A generates the write command with an identifier (i.e., second command generated by device driver), which may subsequently be used in generating notifications regarding the write command or the corresponding data item. In one embodiment, the device driver 116A modifies the write command itself. The write command and corresponding data item, as modified to include an identifier, are transmitted to the controller 122 via the communication link. In one embodiment, the write command (i.e., according to command timing since its generated after receiving the write command from abstraction layer of the OS) is transmitted via SATA or other storage protocol over a storage bus. On receiving the write command and corresponding data item, the controller 122 caches the data item into the volatile cache memory 126 i.e., function is implemented in memory device by execution of write command).
Obr fails to explicitly teach memory devices configured with access control based on cryptography, generate at least one second command to the memory device, the second command including a signature generated using a portion of the second command, however Duval from analogous art teaches wherein at least two of the memory devices have a different command timing, format, or syntax configuration (Duval Fig 1 block 110A-110N and text on [0040] teaches features of the memory system 110A. The other memory systems 110B, 110N may include the same features, or different features. i.e., features of memory devices 110B and 110N may be different from feature of memory device 110A);
memory devices configured with access control based on cryptography (Duval on [0023-0026] teaches memory system configured with access controlled based on cryptography);
(Duval on [0023-0026] teaches memory generating a command and including a signature in the command to be transmitted to memory device. Further teaches the signing device generates the digital signature by executing a cryptographic function, such as a hash function, using a cryptographic key, the command, and the current memory system counter value. Further teaches verifies the digital signature by computing a cryptographic digest of the command from the command message, the current value of the memory system counter and a memory system cryptographic key. A cryptographic digest is the output of a hash function or other suitable cryptographic function that is executed at the memory system utilizing the command, the current value of the memory system counter, and the memory system cryptographic key. See on [0050] teaches the cryptographic engine 142 can be configured to execute one or more cryptographic operations to generate digital signatures as described herein. The cryptographic engine 142 can be configured to generate digital signatures using any suitable cryptographic algorithm such as, for example, a cryptographic hash function such as an SHA algorithm (e.g., SHA256), the MD5 algorithm, etc. A cryptographic has function maps an input value to a, usually shorted, hash value. The hash function can be selected such that it is unlikely that two different input values will map to the same hash value. The cryptographic engine 142 can be configured to generate a digital signature by executing a hash function on an input value related to the thing being digitally signed).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Duval into the teaching of Obr by generating by the device drive a command including a digital signature. One would be motivated to do so in order to validate the command using the digital signature (Duval [0022-0024]).
The combination of Obr and Duval fails to explicitly teach memory devices from different manufacturer, however Shin from analogous art teaches wherein at least two of the memory devices are manufactured by different manufacturers and have a different command timing, format, or syntax configuration (Shin on [col 3 line 56-64] teaches memory devices fabricated by different manufacturers require a different command to perform operation, some flash memory manufacturers may require a different number of commands and addresses or different timing to perform an operation than others. See on [col 8 line 5-10 and col 8 line 50-55] teaches the firmware 124 can be used to construct a descriptor defining a command sequence for controlling the memory devices 106a-d. For example, the descriptor can be constructed to describe a command sequence defining an operation (e.g., read, write, or erase) for a memory device. As mentioned above, the configuration of command sequences may vary based on the requirements of the memory device manufacturer).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Shin into the combined teaching of Obr and Duval by having different memory devices manducated by different manufacturer. One would be motivated to do so in order to perform operation using respective memory device based on the specification of respective manufacturer of the memory device (Shin [col 1 line 31-40]).
Claims 2-3, 5-7 and 11-16 are rejected under 35 U.S.C. 103 as being unpatentable over Obr (US 9645752) in view of Duval (US 20200042465) in view of Shin et al (hereinafter Shin) (US 9152553) and further in view of MARRIPUDI et al (hereinafter MARRIPUDI) (US 20180067671).
Regarding claim 2 and 11 the combination of Obr, Duval and Shin teaches all the limitations of claims 1 and 10 respectively, the combination fails to teach wherein the abstraction layer includes an operating system kernel and at least one utility, however MARRIPUDI from analogous art teaches
wherein the abstraction layer includes an operating system kernel and at least one utility program (MARRIPUDI on [0030] teaches OS kernel and utility program).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of MARRIPUDI into the combined teaching of Obr and Duval by having operating system and kernel in abstraction layer. One would be motivated to do so in order to validate the command using the digital signature executed in host operating system having Kernel and utility program for performing the requested function (MARRIPUDI [0004]).
Regarding claim 3 and 12 the combination of Obr, Duval, Shin MARRIPUDI teaches all the limitations of claims 2 and 11 respectively, MARRIPUDI further teaches wherein the utility program is executable as a command-line command (MARRIPUDI on [0030] teaches OS kernel and utility program, wherein utility program executable based on command-line command).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of MARRIPUDI into the combined teaching of Obr and Duval by having utility program executable as command line command. One would be motivated to do so in order to validate the command using the digital signature executed in host operating system having Kernel and utility program for performing the requested function (MARRIPUDI [0004]).
Regarding claim 13 the combination of Obr, Duval, Shin and MARRIPUDI teaches all the limitations of claim 11 above , Duval further teaches wherein the signature is a hash-based message authentication Code generated for a message having the portion of the second command using a cryptographic key (Duval on [0050] teaches The cryptographic engine 142 can be configured to generate digital signatures using any suitable cryptographic algorithm such as, for example, a cryptographic hash function such as an SHA algorithm (e.g., SHA256), the MD5 algorithm).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Duval into the teaching of Obr by generating by the device drive a command including a digital signature. One would be motivated to do so in order to validate the command using the digital signature (Duval [0022-0024]).
Regarding claim 5 and 14 the combination of Obr, Duval, Shin MARRIPUDI teaches all the limitations of claims 1 and 13 respectively, Duval further teaches wherein the one or more parameters include the signature (Duval on [0023-0026] teaches memory generating a command and including a signature in the command to be transmitted to memory device).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Duval into the teaching of Obr by generating by the device drive a command including a digital signature. One would be motivated to do so in order to validate the command using the digital signature (Duval [0022-0024]).
Regarding claim 6 and 15 the combination of Obr, Duval, Shin MARRIPUDI teaches all the limitations of claims 5 and 14 respectively, Obr further teaches wherein the abstraction layer has no access to the cryptographic key (Obr Fig 2 and text on [col 7 line 26-55] teaches additional abstraction layers may exist within the host system 110, and there write requests may pass through multiple abstraction layers before being received at the device driver 116A. i.e., no key is accessed at abstraction layer).
Regarding claim 7 and 16 the combination of Obr, Duval, Shin MARRIPUDI teaches all the limitations of claims 5 and 14 respectively, Obr further teaches wherein the abstraction layer is configured to provide an opcode and a command type for generation of the second command according to the command timing, format, or syntax configuration from the at least one first command (Obr on [col 8 line 13-18, line 54-67 and col 9 line 1-25] teaches after receiving the write request, the device driver 116A generates the write command with an identifier (i.e., second command generated by device driver based instruction included in the request), which may subsequently be used in generating notifications regarding the write command or the corresponding data item. In one embodiment, the device driver 116A modifies the write command itself. The write command and corresponding data item, as modified to include an identifier, are transmitted to the controller 122 via the communication link. In one embodiment, the write command (i.e., according to command timing since its generated after receiving the write command from abstraction layer of the OS) is transmitted via SATA or other storage protocol over a storage bus. On receiving the write command and corresponding data item, the controller 122 caches the data item into the volatile cache memory 126).
Claims 8, 9, 17 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Obr (US 9645752) in view of Duval (US 20200042465) in view of Shin et al (hereinafter Shin) (US 9152553) in view of MARRIPUDI et al (hereinafter MARRIPUDI) (US 20180067671) and further in view of CHHABRA et al (hereinafter CHHABRA) (US 20220209959).
Regarding claim 8 and 17 the combination of Obr, Duval, Shin MARRIPUDI teaches all the limitations of claims 7 and 16 respectively, the combination fails to teach wherein the opcode and the command type are configured for the second command to: write a cryptographic key into the memory device; update a cryptographic key in the memory device; increment a monotonic counter in the memory device; or retrieve data from the memory device; or any combination thereof, however CHHABRA from analogous art teaches
wherein the opcode and the command type are configured for the second command to: write a cryptographic key into the memory device; update a cryptographic key in the memory device; increment a monotonic counter in the memory device; or retrieve data from the memory device; or any combination thereof (Dover on [0103, 0107, 0110 and 0151-0158] teaches the opcode of the WRAP_KEY instruction indicates that execution circuitry is to store the KEY_FIELD1 and KEY_FIELD2 fields from the input structure into the output structure, generate a MAC over the output structure, and integrity protect the entire structure by encrypting the structure using a session key).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of CHHABRA into the combined teaching of Obr, Duval and MARRIPUDI having an opcode for writing or updating cryptographic key, accessing data from memory device and making any changes to the data. One would be motivated to do so in order to perform authentication operation using key defined in the opcode (CHHABRA [0103 and 0107]).
Regarding claim 9 and 18 the combination of Obr, Duval and MARRIPUDI teaches all the limitations of claims 7 and 16 respectively, the combination fails to teach wherein the opcode and the command type are configured for the second command to: activate security features of the memory device; deactivate security features of the memory device; start a session of updating registers in the memory device; end a session of updating registers in the memory device; calculate a digest of a portion of content stored in the memory device; change a portion of data stored in the memory device; or replace a cryptographic key in the memory device; or any combination thereof, however CHHABRA from analogous art teaches
wherein the opcode and the command type are configured for the second command to: activate security features of the memory device; deactivate security features of the memory device; start a session of updating registers in the memory device; end a session of updating registers in the memory device; calculate a digest of a portion of content stored in the memory device; change a portion of data stored in the memory device; or replace a cryptographic key in the memory device; or any combination thereof (Dover on [0103, 0107, 0110 and 0151-0158] teaches the opcode of the WRAP_KEY instruction indicates that execution circuitry is to store the KEY_FIELD1 and KEY_FIELD2 fields from the input structure into the output structure, generate a MAC over the output structure, and integrity protect the entire structure by encrypting the structure using a session key).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of CHHABRA into the combined teaching of Obr, Duval and MARRIPUDI having an opcode for writing or updating cryptographic key, accessing data from memory device and making any changes to the data. One would be motivated to do so in order to perform authentication operation using key defined in the opcode (CHHABRA [0103 and 0107]).
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Obr (US 9645752) in view of Duval (US 20200042465).
Regarding claim 19 Obr teaches an apparatus, comprising: (Obr on [col 2 line 60-67] teaches system);
a memory device (Obr on [col 5 line 15-44] teaches memory device);
and at least one microprocess configured via instructions to: (Obr on [col 4 line 50-63] teaches one or more processor);
receive, in an abstraction layer implemented for memory devices identifying a memory device of the memory devices, (Obr Fig 2 and text on [col 7 line 26-55] teaches receiving write request along with identifiers (i.e., one or more parameters) used for generating notification command at abstraction layer of host operating system. A write request may correspond to any request to write data to the non-volatile memory 124 of storage system 120 (i.e., memory device). For example, a write request may include a request to write a data item to a specific file (i.e., request to perform function, wherein the function in instant case is write data function to specific file));
generate, by the abstraction layer using the one or more parameters, at least one first command in a format independent of a manufacturer specification about command and response timing, format, or syntax configurations for the memory device (Obr Fig 2 and text on [col 7 line 26-55] teaches the operating system processes the received write request, and transmits the request (i.e., at least one first command) to the device driver 116A. Though not shown within FIG. 2, one skilled in the art will appreciate that additional abstraction layers may exist within the host system 110, and there write requests may pass through abstraction layers before being received at the device driver 116A. Prior to transmitting the write request to the device driver 116A, the operating system 114A may supplement the write request with additional information regarding the application 112A, the data item associated with the write request, or the write request itself. For example, the operating system 114 may supplement the write request with an identity of the application 112A or a logical identifier of the data item requested to be written (e.g., a file descriptor, a record locator, or an object key of the data item). The device driver 116A may receive write requests from the operating system 114A without metadata (i.e., command independent of command timing, format or syntax));
identify, by the abstraction layer, a device driver of the memory device (Obr Fig 2 and text on [col 7 line 26-55] teaches the operating system processes the received write request, and transmits the request (i.e., at least one first command) to the device driver 116A (i.e., identifying driver of memory device). Though not shown within FIG. 2, one skilled in the art will appreciate that various additional abstraction layers may exist within the host system 110, and there write requests may pass through multiple abstraction layers before being received at the device driver 116A.);
and send the at least one first command to the device driver to cause the device driver to generate at least one second command to the memory device according to the manufacturer specification for the memory device, (Obr on [col 8 line 13-18, line 54-67 and col 9 line 1-25] teaches after receiving the write request, the device driver 116A generates the write command with an identifier (i.e., second command generated by device driver), which may subsequently be used in generating notifications regarding the write command or the corresponding data item. In one embodiment, the device driver 116A modifies the write command itself. The write command and corresponding data item, as modified to include an identifier, are transmitted to the controller 122 via the communication link. In one embodiment, the write command (i.e., according to command timing since its generated after receiving the write command from abstraction layer of the OS) is transmitted via SATA or other storage protocol over a storage bus. On receiving the write command and corresponding data item, the controller 122 caches the data item into the volatile cache memory 126 i.e., function is implemented in memory device by execution of write command).
Obr fails to explicitly teach memory devices configured with access control based on cryptography, generate at least one second command to the memory device, the second command including a signature generated using a portion of the second command, however Duval from analogous art teaches wherein at least two of the memory devices have a different command timing, format, or syntax configuration (Duval Fig 1 block 110A-110N and text on [0040] teaches features of the memory system 110A. The other memory systems 110B, 110N may include the same features, or different features. i.e., features of memory devices 110B and 110N may be different from feature of memory device 110A);
memory devices configured with access control based on cryptography (Duval on [0023-0026] teaches memory system configured with access controlled based on cryptography);
(Duval on [0023-0026] teaches memory generating a command and including a signature in the command to be transmitted to memory device. Further teaches the signing device generates the digital signature by executing a cryptographic function, such as a hash function, using a cryptographic key, the command, and the current memory system counter value. Further teaches verifies the digital signature by computing a cryptographic digest of the command from the command message, the current value of the memory system counter and a memory system cryptographic key. A cryptographic digest is the output of a hash function or other suitable cryptographic function that is executed at the memory system utilizing the command, the current value of the memory system counter, and the memory system cryptographic key. See on [0050] teaches the cryptographic engine 142 can be configured to execute one or more cryptographic operations to generate digital signatures as described herein. The cryptographic engine 142 can be configured to generate digital signatures using any suitable cryptographic algorithm such as, for example, a cryptographic hash function such as an SHA algorithm (e.g., SHA256), the MD5 algorithm, etc. A cryptographic has function maps an input value to a, usually shorted, hash value. The hash function can be selected such that it is unlikely that two different input values will map to the same hash value. The cryptographic engine 142 can be configured to generate a digital signature by executing a hash function on an input value related to the thing being digitally signed).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Duval into the teaching of Obr by generating by the device drive a command including a digital signature. One would be motivated to do so in order to validate the command using the digital signature (Duval [0022-0024]).
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Obr (US 9645752) in view of Duval (US 20200042465) and further in view of MARRIPUDI et al (hereinafter MARRIPUDI) (US 20180067671).
Regarding claim 20 the combination of Obr and Duval teaches all the limitations of claim 19 above, the combination fails to teach wherein the abstraction layer includes an operating system kernel and at least one utility, however MARRIPUDI from analogous art teaches
wherein the abstraction layer includes an operating system kernel and at least one utility program (MARRIPUDI on [0030] teaches OS kernel and utility program).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of MARRIPUDI into the combined teaching of Obr and Duval by having operating system and kernel in abstraction layer. One would be motivated to do so in order to validate the command using the digital signature executed in host operating system having Kernel and utility program for performing the requested function (MARRIPUDI [0004]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOEEN KHAN whose telephone number is (571)272-3522. The examiner can normally be reached 7AM-5PM EST M-TH Alternate Fridays.
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, Shewaye Gelagay can be reached on (571)272-4219. 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.
/MOEEN KHAN/ Primary Examiner, Art Unit 2436