DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
Receipt is acknowledged of a request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e) and a submission, filed on September 10th, 2025.
Response to Amendment
The amendment filed on August 21st, 2025 has been entered in view of the filing of RCE on September 10th, 2025.
By the amendment filed on August 21st, 2025, the amendment of claims 1, 2, 7-9, 11, 14, and 21-23 have been acknowledged. Claims 3, 15, 16, and 20 were previously cancelled. Claims 1-2, 4-14, 17-19, and 21-23 are currently pending.
In view of the amendments and arguments, rejections of claims under 35 USC 112(a) and 112(b) are withdrawn.
Response to Arguments
Applicant's arguments with respect to the independent claims 1, 7, and 14 filed August 21st, 2025 have been fully considered, but they are moot in view of claim amendments and new grounds of rejections in this Office Action, and are not persuasive.
Regarding amended independent claims 1, 7, and 14, Applicant argued:
For substantially the same reasons, Applicant respectfully submits that the cited references, alone or in combination, fail to teach, show, or suggest the data storage devices of claims 1, 7, and 14. The Final Office Action cites Stern to teach the limitations "detecting whether the operation specific command corresponds to the header pattern and the footer pattern of the operation specific file stored in the first location; and perform the internal storage task if the operation specific command meets the header pattern and the footer pattern of the operation specific file stored in the first location." Final Office Action, pp. 17-19.
Applicant respectfully submits that Stern discloses a "special object is a special file 302 that physically resides on the data store 106... special file 302 typically has a file size of one sector or 512 bytes, however it should be understood that some file systems may employ sector blocks of varying size (e.g., 1024 bytes, etc.)." Stern, para. [0045]. Additionally, Stern states that "Here, special file 302 physically resides on the data store 106 at a logical sector number of 98766 and is flagged unmovable." Id. at [0046]. Stern continues, "Since the [Virtual Memory Card Controller] VMCC 110 typically tracks the sector of each and every special file 302 (e.g., in order to recognize when it is appropriate to call an application to handle communication with a host), flagging the special file as unmovable simplifies this procedure." Stern also discloses that "the VMCC 110 can record the logical sector address of the special file 302 as soon (or shortly thereafter) as the special file 302 is created." Id. at [0047]. As cited by the Final Office Action, Stern discloses that "the VMCC 110 can be configured to detect the logical location of special files 302. For example, rather than (or in addition to) persistently tracking the location of the special files 302, the VMCC 110 can, e.g., upon initialization, scan a given set of directories (e.g., the "/special/directory as well as others) for files with a file size of exactly one sector. For instance, the VMCC 110 can receive a command 308 to load into memory. Upon loading, or starting, the VMCC 110 can explore the special directories and flag the special files 302."Id. at [0049].
Applicant submits that, at most, Stern teaches tracking and flagging an unmovable special file to simplify when it is appropriate to call an application to handle communication with a host. Stern further teaches an alternative method of detecting a logical location of special files. Instead of persistently tracking the location of the special files 302, the VMCC 110 can explore special directories and flag special files 302 by scanning a given set of directories for files with a file size of exactly one sector.
Applicant thus submits that Stern fails to teach detecting whether the operation specific command meets a data pattern of the operation specific file, wherein the detecting comprises identifying that the operation specific file comprises a specific file via recognizing the data pattern of the operation specific file, as recited in claim 1. That is, whereas Stern provides for a method of detecting a logical location of special files via scanning a given set of directories for files with a file size of exactly one sector, the claimed embodiments provide for the detection of a special file within an operation specific file when a data pattern of the operation specific file is recognized by the controller (i.e., the recognition identifies the operation specific file as a comprising a special file).
Even in view of Johnson, which the Final Office Action cites to teach adding a header pattern and a footer pattern to a file, Applicant submits that the cited references, alone or in combination, fail to teach, show, suggest the claimed embodiments. Final Office Action, p. 19. Johnson teaches an identification header that comprises three elements. Johnson, [0763]. "The first element serves as a project identifier 4-202. The project identifier corresponds to the project in the developer portal and uniquely identifies the project. The second line is the encoding identifier 4-204 that specifies how the rest of the provisioning file is encoded. The third line in the identification header is a random salt 4-206 that is used in encoding the encrypted portion 4-220. In exemplary uses, each time the provisioning file is generated it will use a different random salt." Johnson, [0764]- [0766].
Applicant submits that, at most, Johnson teaches a project identifier that identifies in a developer portal a corresponding project of the sample provisioning file. However, Johnson fails to teach that the project identifier is a data pattern of an operation specific file that, when detected, identifies to the data storage device that the operation specific file comprises a special file, nor that recognizing the data pattern identifies to the data storage device that the operation specific file comprises the special file. Thus, Johnson fails to cure the deficiencies of Brown and Stern. Withdrawal of the rejection is respectfully requested.
Examiner respectfully disagrees.
Amended claim 1 recites in part, “wherein creating the operation specific file comprises adding a data pattern to a special file, …, wherein the data pattern identifies to the data storage device that the operation specific file comprises the special file, and wherein the data pattern is predefined in the data storage device before receiving the command; … detect whether the operation specific command meets the data pattern of the operation specific file stored in the first location, wherein the detecting comprises identifying that the operation specific file comprises the special file via recognizing the data pattern of the operation specific file; and perform the internal storage task at the second location if the operation specific command is detected to meet the data pattern of the operation specific file stored in the first location”.
However, the amended claim does not recite narrowly what “data pattern” is nor what “meet the data pattern” is. The amended claim merely recites that the data pattern “identifies to the data storage device that the operation specific file comprises the special file” and “is predefined in the data storage device before receiving the command”.
Therefore, the broadest reasonable interpretation of Applicant’s claims with regards to the above highlighted limitations, would only require any “data pattern” could be any pattern that indicates a file comprises a “special file” and that this data pattern is predefined. Additionally, the operation specific command “meet the data pattern” merely requires that the operation specific command fits /meets the data pattern that indicates the special file, but does not require that the operation specific command specifically contains, includes any or all portions of the data pattern. For the purpose of examination, “meet the data pattern” may be merely associated with the data pattern, via an indication of relationship/association.
In this regard, STERN discloses at [0049], FIG. 3, “the VMCC 110 can receive a command 308 to load into memory. Upon loading, or starting, the VMCC 110 can explore the special directories and flag the special files 302. The VMCC 110 endowed with this feature may require additional memory, but can be particularly well suited to dynamically creating special files 302 on the fly rather than employing only a static set of special files 302 generated when the data store 106 is formatted. Moreover, newly created special files 302 can even occur as a result of an operation received from a host application, such as an update utility or the like that, e.g., performs a write operation on a special file 302 associated with the path "\special\newobject".” E.g. the command /operation received from a host may perform operations such as updates/writes to special file “associated with” a specific path, which may be interpreted as command “meet the data pattern” of the operation specific file, (the data pattern added to the file may be interpreted from “VMCC 110 … flag the special files 302” and “special file 302 associated with the path”).
Furthermore, BROWN discloses provide the special file to the second data storage device (“230 Download available FW updates to IHS”, FIG. 3), and performing a internal storage task at the second location after the special file is provided to the second data storage device (“205 build FW update package”, FIG. 3, [0024] “Update functions, including, but not limited to, a firmware inventory function, a version comparison function and a firmware upgrade functions may be incorporated in one, or more, utility programs. Other software utility programs may be included as required”).
Therefore, the combination of BROWN and STERN discloses detect whether the operation specific command corresponds to the header pattern and the footer pattern of the operation specific file stored in the first location; and perform the internal storage task at the second location if the operation specific command meets the header pattern and the footer pattern of the operation specific file stored in the first location, as recited in amended claim 1.
For substantially the same reason stated above, STERN also discloses similar limitations in amended claims 7 and 14.
Furthermore, previously cited Johnson et al., US Patent Application Publication Number 20190158353 discloses creating the operation specific file comprises adding a data pattern to a special file (FIGs. 93-95, provisioning file is created including adding an identification header in the beginning of the provisioning file and an “override area” at the end of the provisioning file, each one may contain various patterns, such as project identification number and “application-specific parameters” and “implementation-specific parameters”. [0754]-[0810], “Provisioning is performed in conjunction with a device date (e.g., update to firmware, services, bug fix, etc.).” e.g. creating an update operation specific file comprising adding a data pattern to a special file).
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
Such claim limitation(s) is/are: “means to store data” in claim 14.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
For the purpose of examination, corresponding structure or equivalent of “means to store data” in claim 14 is interpreted as memory device (e.g. NAND) 206 in FIG. 2 and descriptions or equivalent of.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 4-5, 7, 9-14, 19, 21, and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Brown et al., US Patent Number 8,707,297 (herein “BROWN”) in view of Stern et al., US Patent Application Publication Number 20080091878 (herein “STERN”), and further in view of Johnson et al., US Patent Application Publication Number 20190158353 (herein “JOHNSON”).
Regarding claim 1, BROWN discloses a data storage device (100, 130, 135, FIG. 2), comprising: a memory device 130; and a controller 15 coupled to the memory device 130,
wherein the controller 15 is configured to: create the operation specific file (“205 build FW update package”, FIG. 3),
wherein creating the operation specific file comprises adding a data pattern to a special file, wherein the data pattern identifies to the data storage device that the operation specific file comprises the special file, wherein the data pattern is predefined in the data storage device before receiving the command ([0026] “firmware update package may further include a data structure”, which includes “system_bios(vendor_$vendor_system_$system)=$version`, where $vendor is the PCI SIG (Peripheral Component Interconnect Special interest Group) defined Vendor ID, $system is a vendor unique system identifier, and $version is the version string of a start-up initialization program firmware image update”, which can be considered a signature that is predefined by vendors before commands are received. The data structure can be considered data patterns added to the file, and the data patterns of the data structure is predefined. Firmware update packages may be considered internal storage task and a special file in the operation specific file);
wherein the special file comprises: a signature ([0026] “firmware update package may further include a data structure”, which includes “system_bios(vendor_$vendor_system_$system)=$version`, where $vendor is the PCI SIG (Peripheral Component Interconnect Special interest Group) defined Vendor ID, $system is a vendor unique system identifier, and $version is the version string of a start-up initialization program firmware image update”, which can be considered a signature); and
a file indicating an internal storage task (“205 build FW update package”, FIG. 3, [0024] “Update functions, including, but not limited to, a firmware inventory function, a version comparison function and a firmware upgrade functions may be incorporated in one, or more, utility programs. Other software utility programs may be included as required”);
store the operation specific file in a first location (“225 Run OS executable on IHS using OS change management SW to query remote repository for available FW updates”, “230 Download available FW updates to IHS”, FIG. 3, remote repository 130 may be a first location where the available updates are stored);
write the operation specific file to a second location (“225 Run OS executable on IHS using OS change management SW to query remote repository for available FW updates”, “230 Download available FW updates to IHS”, FIG. 3, remote repository 130 may be a first location where the available updates are stored, and then download/write to IHS, which may be a second location);
perform the internal storage task at the second location (“205 build FW update package”, FIG. 3, [0024] “Update functions, including, but not limited to, a firmware inventory function, a version comparison function and a firmware upgrade functions may be incorporated in one, or more, utility programs. Other software utility programs may be included as required”, e.g. updates as internal storage tasks are downloaded and performed at the IHS).
Brown does not explicitly disclose receive a command from a host device to create an operation specific file; wherein the special file comprises: an operation specific header; a signature; and a file indicating an internal storage task disposed between the operation specific header and the signature, wherein the data pattern identifies to the data storage device that the operation specific file comprises the special file, receive an operation specific command from the host device to write the operation specific file to a second location; detect whether the operation specific command meets the data pattern of the operation specific file stored in the first location, wherein the detecting comprises identifying that the operation specific file comprises the special file via recognizing the data pattern of the operation specific file; and perform the internal storage task at the second location if the operation specific command is detected to meet the data pattern of the operation specific file stored in the first location.
STERN discloses receive a command from a host device to create an operation specific file ([0049] “the VMCC 110 can receive a command 308 to load into memory. Upon loading, or starting, the VMCC 110 can explore the special directories and flag the special files 302. The VMCC 110 endowed with this feature may require additional memory, but can be particularly well suited to dynamically creating special files 302 on the fly”);
receive an operation specific command from the host device to write the operation specific file to a second location ([0049], FIG. 3, “the VMCC 110 can receive a command 308 to load into memory. Upon loading, or starting, the VMCC 110 can explore the special directories and flag the special files 302. The VMCC 110 endowed with this feature may require additional memory, but can be particularly well suited to dynamically creating special files 302 on the fly rather than employing only a static set of special files 302 generated when the data store 106 is formatted. Moreover, newly created special files 302 can even occur as a result of an operation received from a host application, such as an update utility or the like that, e.g., performs a write operation on a special file 302 associated with the path "\special\newobject".” E.g. the command /operation received from a host may perform operations such as updates/writes to special file “associated with” a specific path. Loading into memory may be considered to write the file to a second location, a second data storage device);
detect whether the operation specific command meets the data pattern of the operation specific file stored in the first location, wherein the detecting comprises identifying that the operation specific file comprises the special file via recognizing the data pattern of the operation specific file; and perform the internal storage task at the second location if the operation specific command is detected to meet the data pattern of the operation specific file stored in the first location ([0049], FIG. 3, “the VMCC 110 can receive a command 308 to load into memory. Upon loading, or starting, the VMCC 110 can explore the special directories and flag the special files 302. The VMCC 110 endowed with this feature may require additional memory, but can be particularly well suited to dynamically creating special files 302 on the fly rather than employing only a static set of special files 302 generated when the data store 106 is formatted. Moreover, newly created special files 302 can even occur as a result of an operation received from a host application, such as an update utility or the like that, e.g., performs a write operation on a special file 302 associated with the path "\special\newobject".” E.g. the command /operation received from a host may perform operations such as updates/writes to special file “associated with” a specific path, which may be interpreted as command “meet the data pattern” of the operation specific file, (the data pattern added to the file may be interpreted from “VMCC 110 … flag the special files 302” and “special file 302 associated with the path”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify BROWN’s firmware updating system to further include STERN’s command request to generate a special file, to allow use of more sophisticated command set of memory devices (see STERN [0005]).
BROWN and STERN do not explicitly disclose wherein the special file comprises: an operation specific header; and a file indicating an internal storage task disposed between the operation specific header and the signature.
JOHNSON discloses wherein the special file comprises: an operation specific header; a signature; and a file indicating an internal storage task disposed between the operation specific header and the signature (FIGs. 93-95, particularly FIG. 94, provisioning file, includes, an “identification header” in the beginning of the provisioning file as operation specific header, a signature (checksum Part 4-324, used for encrypting /decrypting the middle portion), and a file (middle encrypted portion data part 4-322, which is encrypted with the checksum signature) between the header and the signature. FIG. 95, [0754]-[0810], “Provisioning is performed in conjunction with a device date (e.g., update to firmware, services, bug fix, etc.).” Middle portion is the file containing provisioning information, which is an internal storage task).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify BROWN’s firmware updating system with STERN’s command request to generate a special file, to further include JOHNSON’s special file with header, signature and an internal storage task file, to increase the security and allow greater control (see JOHNSON [0800]).
Regarding claim 4, BROWN discloses wherein the creating occurs in a host interface module (HIM) (“205 build FW update package”, FIG. 3, generation here occurs in a software executed in the CPU. HIM may be general interpreted as a software module executing in a controller or a CPU).
Regarding claim 5, BROWN discloses wherein the controller is configured to encrypt or sign the file ([0026] “firmware update package may further include a data structure”, which includes “system_bios(vendor_$vendor_system_$system)=$version`, where $vendor is the PCI SIG (Peripheral Component Interconnect Special interest Group) defined Vendor ID, $system is a vendor unique system identifier, and $version is the version string of a start-up initialization program firmware image update”, which can be considered a signature).
Regarding claim 7, Applicant is directed to the rejection of claim 1, for claim 7 is rejected based on substantially the same reasons.
Regarding claim 9, BROWN discloses wherein the controller is configured to read the internal storage task from a data structure of the operation specific file after the validating ([0026] “firmware update package may further include a data structure”, which includes “system_bios(vendor_$vendor_system_$system)=$version`, where $vendor is the PCI SIG (Peripheral Component Interconnect Special interest Group) defined Vendor ID, $system is a vendor unique system identifier, and $version is the version string of a start-up initialization program firmware image update”, which can be considered a signature. Once the corresponding available firmware update is found available, the controller downloads the firmware update package, e.g. read the operation versions from the data structure after validation. Firmware update may be considered as internal storage task).
BROWN and STERN do not explicitly disclose a header pattern and a footer pattern of an operation specific file.
JOHNSON discloses a header pattern and a footer pattern of an operation specific file (FIGs. 93-95, provisioning file is created including adding an identification header in the beginning of the provisioning file and an “override area” at the end of the provisioning file, each one may contain various patterns, such as project identification number and “application-specific parameters” and “implementation-specific parameters”. [0754]-[0810], “Provisioning is performed in conjunction with a device date (e.g., update to firmware, services, bug fix, etc.).” e.g. creating an update operation specific file comprising adding a header pattern and a footer pattern).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify BROWN’s firmware updating system with STERN’s command request to generate a special file, to further include JOHNSON’s adding of a header pattern and a footer pattern to the special file, to increase the security and allow greater control (see JOHNSON [0800]).
Regarding claim 10, BROWN discloses wherein the controller is configured to turn on or turn off the detecting (inherent, all software components can be configured to be turned on or turned off, i.e. execute or not execute).
Regarding claim 11, BROWN discloses wherein the data pattern includes a file operation identification (ID) ([0026] “firmware update package may further include a data structure”, which includes “system_bios(vendor_$vendor_system_$system)=$version`, where $vendor is the PCI SIG (Peripheral Component Interconnect Special interest Group) defined Vendor ID, $system is a vendor unique system identifier, and $version is the version string of a start-up initialization program firmware image update”, includes various ID numbers that represents the firmware update operation).
Regarding claim 12, BROWN discloses wherein the detecting is performed by a file pattern engine (inherent, file pattern engine is contained in the CPU/controller, as is the querying of available updates is done by the CPU in BROWN).
Regarding claim 13, BROWN discloses wherein the file pattern engine is disposed along a transmission line 135 of the controller ([0020] “IHS 100 communicates over network 135 with software/firmware program repository 130”, since IHS 100 is connected to transmission line 135, pattern engine is thus disposed along the transmission line 135).
Regarding claim 14, Applicant is directed to the rejection of claim 1, for claim 14 is rejected based on substantially the same reasons.
Regarding claim 19, BROWN discloses wherein the controller is configured to verify the operation specific file ([0023], “an update package may verify a digital certificate, or other authentication signature for each file in the package”).
Regarding claim 21, BROWN discloses the data storage device of claim 1, wherein the first location is the data storage device and a second location is a second data storage device (“225 Run OS executable on IHS using OS change management SW to query remote repository for available FW updates”, “230 Download available FW updates to IHS”, FIG. 3, remote repository 130 may be considered a first location /data storage device, where the available updates are stored, and IHS may be considered as a second location /second data storage device).
Regarding claim 23, BROWN discloses the data storage device of claim 7, wherein the first location is the data storage device and the second location is a second data storage device remotely located relative to the first location (“225 Run OS executable on IHS using OS change management SW to query remote repository for available FW updates”, “230 Download available FW updates to IHS”, FIG. 3, remote repository 130 may be considered a first location /data storage device, where the available updates are stored, and IHS may be considered as a second location /second data storage device where the operation of FW updates is performed).
Claims 2, 6 and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over BROWN in view of STERN, further in view of JOHNSON, and further in view of Wooten et al., US Patent Application Publication Number 20170104580 (herein “WOOTEN”).
Regarding claim 2, BROWN and STERN and JOHNSON do not explicitly disclose wherein the signature is a hash-based message authentication code (HMAC) signature.
WOOTEN discloses wherein the signature is a hash-based message authentication code (HMAC) signature ([0036], “The device can check a HMAC signature of a software module using the sealing key and/or attestation key of the preceding software module in the boot chain”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify BROWN’s firmware updating system with STERN’s command request to generate a special file, with JOHNSON’s special file with header, signature and an internal storage task file, to further include WOOTEN’s HMAC signature verification, to implement stronger security (see WOOTEN Background).
Regarding claim 6, BROWN discloses wherein the controller is configured to use an authentication signature to check integrity ([0023], “an update package may verify a digital certificate, or other authentication signature for each file in the package.”).
BROWN and STERN and JOHNSON do not explicitly disclose use a hash message authentication code (HMAC) signature.
WOOTEN discloses use a hash message authentication code (HMAC) signature ([0036], “The device can check a HMAC signature of a software module using the sealing key and/or attestation key of the preceding software module in the boot chain”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify BROWN’s firmware updating system with STERN’s command request to generate a special file, with JOHNSON’s special file with header, signature and an internal storage task file, to further include WOOTEN’s HMAC signature verification, to implement stronger security (see WOOTEN Background).
Regarding claim 17, BROWN and STERN and JOHNSON do not explicitly disclose wherein the controller is configured to encrypt the operation specific file.
WOOTEN discloses wherein the controller is configured to encrypt the operation specific file ([0078] Block 330 can represent an encryption/decryption module with logic to program processing unit(s) 302 of device 300 for performing encryption and decryption, e.g. encryption of part of the firmware updating package).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify BROWN’s firmware updating system with STERN’s command request to generate a special file, with JOHNSON’s special file with header, signature and an internal storage task file, to further include WOOTEN’s encryption/decryption, to implement stronger security (see WOOTEN Background).
Regarding claim 18, BROWN and STERN and JOHNSON do not explicitly disclose wherein the controller is configured to decrypt the operation specific file.
WOOTEN discloses wherein the controller is configured to decrypt the operation specific file ([0078] Block 330 can represent an encryption/decryption module with logic to program processing unit(s) 302 of device 300 for performing encryption and decryption, e.g. encryption of part of the firmware updating package).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify BROWN’s firmware updating system with STERN’s command request to generate a special file, with JOHNSON’s special file with header, signature and an internal storage task file, to further include WOOTEN’s encryption/decryption, to implement stronger security (see WOOTEN Background).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over BROWN in view of STERN, further in view of JOHNSON, and further in view of Stenfort et al., US Patent Application Publication Number 20180004504 (herein “STENFORT”).
Regarding claim 8, BROWN and STERN and JOHNSON do not explicitly disclose wherein the internal storage task is selected from a group consisting of: device lock, device format, device reset statistics, change power mode, enable write cache, disable write cache, change error correction capabilities, enable host memory buffer (HMB) support, disable HMB support, or flush cache.
STENFORT discloses wherein the internal storage task is selected from a group consisting of: device lock, device format, device reset statistics, change power mode, enable write cache, disable write cache, change error correction capabilities, enable host memory buffer (HMB) support, disable HMB support, or flush cache ([0338] performing a power mode change during firmware update operation).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify BROWN’s firmware updating system with STERN’s command request to generate a special file, with JOHNSON’s special file with header, signature and an internal storage task file, to further include STENFORT’s change of power mode, to allow continual running of OS during firmware update without rebooting OS (see STENFORT [0014]).
Claim 22 is rejected under 35 U.S.C. 103 as being unpatentable over BROWN in view of STERN, further in view of JOHNSON, and further in view of DZIERZANOWSKI et al., US Patent Application Publication Number 20220237565 (herein “DZIERZANOWSKI”).
Regarding claim 22, BROWN and STERN do not explicitly disclose the data storage device of claim 1, wherein the data pattern is protected with a header signature and a footer signature, and wherein the header signature and the footer signature are separate and distinct from the signature.
JOHNSON discloses the footer pattern and data file may be encrypted /signed with separate and distinct encryption schemes /signatures ([0795], “a first override area or encrypted area may be encrypted using a first encryption scheme and a second override area or encrypted area may be encrypted using a second encryption scheme.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify BROWN’s firmware updating system with STERN’s command request to generate a special file, to further include JOHNSON’s special file with header, signature and an internal storage task file, to increase the security and allow greater control (see JOHNSON [0800]).
DZIERZANOWSKI discloses wherein the header pattern are protected with a header signature, and wherein the header signature are separate and distinct from the signature of the file with a storage task (FIGs. 5A and 5B, [0126]-[0127], “Header 500 is created as a combination of public and private data fields provided by the entity to the system…. The header 500 is hashed by the system via a SHA-3 function 506…. In this manner, the system forms a highly secure digital signature of the header data and timestamp.” And separately “The data block 530 hashed by the system via a SHA-3 function 536…. The digital signature output of the data block 542 is captured as a field for storage in 552.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify BROWN’s firmware updating system with STERN’s command request to generate a special file, with JOHNSON’s special file with header, signature and an internal storage task file, to further include DZIERZANOWSKI’s separate and distinct signatures for header/footer from the signature of the file, to prevent tampering and corruption of data by untrusted parties (see DZIERZANOWSKI [0056]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHEN GU whose telephone number is (571) 270-1208. The examiner can normally be reached M-F 10:30am-8:00pm 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, Jared Rutz can be reached on (571) 272-5535. 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.
CHEN GU
Examiner
Art Unit 2135
/C.G./Examiner, Art Unit 2135
/JARED I RUTZ/Supervisory Patent Examiner, Art Unit 2135