DETAILED ACTION
Claims 1-5, 8-16, and 19-28 have been examined.
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 December 11, 2024, has been entered.
Specification
The title of the invention is not sufficiently descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed. The examiner recommends inserting --BANK-- before “HEADER”.
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification.
Claim Interpretation
The examiner notes that previous 112(f) interpretation is no longer applicable as applicant’s claims no longer invoke 112(f) due to amendments to claim circuits/circuitry.
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-5, 8-16, and 19-28 are rejected under 35 U.S.C. 103 as being unpatentable over O’Neill, U.S. Patent No. 6,832,373, in view of Osthoff et al., U.S. Patent Application Publication No. 2005/0091501 A1. Furthermore, Wikipedia, “Lempel-Ziv-Welch”, is cited herein as extrinsic evidence showing characteristics of LZW compression.
Referring to claim 1, O’Neill has taught a memory circuit, comprising:
a plurality of banks (see FIGs.8A and 10, and column 30, line 42, to column 31, line 27); and
processing circuitry (see column 5, line 60, to column 6, line 8) coupled with the plurality of banks and configured to cause the memory circuit (see column 7, lines 23-29, and FIG.8A. A computer having memory may be the memory circuit) to:
access firmware data associated with the memory circuit, the firmware data comprising a plurality of compressed bank data that includes information about the plurality of banks at the memory circuit (see column 18, lines 3-11, column 30, lines 31-37, column 34, lines 22-23 and 51-54, and column 37, lines 16-40, along with FIGs.9 and 11 and their descriptions. In summary, the firmware update package, which may be compressed (e.g. via LZW compression (column 18, lines 3-6)), includes various compressed bank information for the system (code to initialize bank pointer, code to update current bank firmware, bank size information, CRC information for fault tolerance during update, etc.)) and a bank header (see column 18, lines 6-11), wherein the update package includes a plurality of bank data sizes (see column 30, lines 31-37, “bank sizes”, which are deemed to be part of the header) and a quantity of the plurality of compressed bank data (see column 30, lines 31-37, column 33, lines 41-52, and column 37, line 16, to column 38, line 9. A CRC (error correction) code(s) would be such a quantity that is deemed part of the header. For instance, a CRC code is unique to particular bank data so as to determine when a bank update has occurred. As a CRC code is a calculated quantity, it is a quantity of the bank data), wherein each bank data size corresponds to a size of a respective compressed bank data of the plurality of compressed bank data (the bank sizes are sizes of respective banks associated with the compressed bank data used to update the banks);
O’Neill has not explicitly taught the bank header indicating a composition of the plurality of compressed bank data. However, recall from the citations above that O’Neill has taught that the update package may be compressed, thereby making it optional. Osthoff has similarly taught transmitting software as a payload with a header that indicates whether the payload is compressed, and, if so, the type of compression used (see paragraph [0094], which states “The header 301 further comprises…a command section indicating parameters used by the mobile terminal during the processing of the payload…The parameters may further comprise information about whether and what type of compression and/or encryption is used”). One of ordinary skill in the art would have recognized that to implement optional compression in O’Neill, indicating the composition of the package data, i.e., whether it is compressed or not, and then providing the compression type, would inform the receiver as to the type of data being received and allow the receiver to quickly select the appropriate decompression routine that corresponds to the selected compression type. As a result, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify O’Neill’s bank header to indicate a composition of the plurality of compressed bank data.
O’Neill has also not taught that the plurality of bank data sizes and the quantity of the plurality of compressed bank data are in the bank header. Instead, they are just part of the package in general. However, one of ordinary skill in the art would have recognized that the information can appear anywhere in the package and functionality would remain the same (the system would simply be designed to look for the bank sizes and quantity wherever they are placed in the package). As a header is understood to precede a payload (in this case, the updated code), the bank sizes and quantity data can be moved to the header and this would amount to a mere rearrangement of parts, which is a routine expedient that is not a patentable distinction, particularly absent a demonstration of the criticality of this information being in a header versus somewhere else in the package. See MPEP 2144.04, including section (VI)(C). As such, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify O’Neill such that the bank sizes and quantity appear in and accessible location within the update package, including in the header.
O’Neill has further taught wherein a compression of the plurality of compressed bank data is based at least in part on one or more bank data refraining from aligning with one or more banks of the plurality of banks (from FIG.8A and column 26, lines 30-56, non-volatile memory, which stores the compressed firmware data package (column 34, lines 6-7 and 15-25), is divided into 64KB banks. Recall, from above, that O’Neill teaches using LZW compression, the properties of which are shown in Wikipedia. Such compression can be said to be based on the claimed refraining for multiple reasons:
Whether fixed 12-bit LZW or variable-width LZW is used, bytes typically do not fall on byte boundaries (see Wikipedia, “Packing order”)). That is, the nature of the compression is such that at least some bank data refrains from aligning with one or more banks storing the data. As an example, if each location in a bank stores 1 byte, and 12-bit codes are used, while the first byte may be aligned, the next 12-bit code would not be aligned because it starts halfway through the next byte. If each location instead stores 2 bytes, and 12-bit codes are used, while the first byte may be aligned, the next 12-bit code would again not be aligned because it starts at the 13th bit (no padding is added with LZW). If each location stores 4 bytes, a similar unalignment occurs. Various sizes of memory locations and compressed codes would result in different unalignments.
From column 33, lines 62-65, and FIG.10, the compressed firmware is compressed to be small so that it can be stored in a small part 1224 of memory. Thus, bank data within the compressed firmware is not compressed in a way that causes it to be stored in (aligned with) every bank in memory. Thus, there is a lack of alignment with at least one bank.
In general, with LZW compression, the codes are compressed to create a shorter bit sequence, and no padding is added, meaning it is a compression scheme based on unalignment as opposed to alignment.
O’Neill, as modified, has further taught that the memory circuit is caused to identify, based at least in part on the bank header indicating the composition and including the plurality of bank data sizes and the quantity of the plurality of compressed bank data (based on the header indicating the data in the update package is compressed, where the header includes the other information. The examiner also notes that this limitation does not necessarily require that the identification occur because the header indicates and includes these things; instead, it can be read as a repeat of what the header indicates/includes), a portion of the firmware data comprising a first compressed bank data from the plurality of compressed bank data, the first compressed bank data corresponding to a first bank of the plurality of banks (again, the current firmware version is updated bank-by-bank. By identifying, based on the header, that the composition is a compressed composition, all data therein, including the data for a first bank update (e.g. shown in FIG.10), is compressed); and
O’Neill, as modified, has further taught that the memory circuit is causes to decompress, based at least in part on the identifying, the first compressed bank data to obtain a first bank data corresponding to the first bank of the plurality of banks (see column 16, lines 37-39. Based on identifying that the update is compressed, all of it is decompressed).
Referring to claim 2, O’Neill, as modified, has taught the memory circuit of claim 1, wherein the processing circuitry is further configured to cause the memory circuit to: determine whether the firmware data comprises the plurality of compressed bank data or a second plurality of uncompressed bank data, wherein identifying the portion of the firmware data comprising the first compressed bank data is based at least in part on determining that the firmware data comprises the plurality of compressed bank data (as described above, compression is optional in O’Neill and O’Neill’s header can be modified to include a compressed/uncompressed indicator. Thus, when the indicator must be analyzed to determine whether the update package includes compressed or uncompressed bank data. If compression is indicated, then first compressed bank data is identified).
Referring to claim 3, O’Neill, as modified, has taught the memory circuit of claim 2, wherein: the firmware data comprises an indication of whether the firmware data comprises the plurality of compressed bank data or whether the firmware data comprises the second plurality of uncompressed bank data; and determining that the firmware data comprises the plurality of compressed bank data is based at least in part on the indication (see the rejection of claims 1-2. The header includes such an indication).
Referring to claim 4, O’Neill, as modified, has taught the memory circuit of claim 3, wherein: the firmware data comprises a firmware header indicating a composition of the firmware data; and the firmware header comprises the indication of whether the firmware data comprises the plurality of compressed bank data or the second plurality of uncompressed bank data (see the rejections of claims 1-3).
Referring to claim 5, O’Neill, as modified, has taught the memory circuit of claim 1, wherein the decompressing is configured to cause the memory circuit to: read the identified portion of the firmware data comprising the first compressed bank data to obtain the first bank data (see the rejection of claim 1. If the package is compressed, all data therein is decompressed, including the first compressed bank data to obtain the first bank data, which is used to update the first bank).
Referring to claim 8, O’Neill, as modified, has taught the memory circuit of claim 1, wherein the bank header comprises a plurality of error control information corresponding to the plurality of compressed bank data (see column 33, lines 37-61, and column 18, lines 6-11. CRC codes and digital signatures are included for error control, as is validation information).
Referring to claim 9, O’Neill has taught the memory circuit of claim 8, wherein the processing circuitry is further configured to cause the memory circuit to: perform, based at least in part on the decompressing, an error control operation on the first bank data based at least in part on first error control information of the plurality of error control information (as described, error control for all package data, including first bank data, is performed based on the error control information. And since all package data is decompressed (when indicated by the header as being compressed), the error control is partly based on the result of the decompression. Note FIG.11 (and its description) as well, which performs specific error control operation for the bank at which the update failed, which could include any bank, including the first bank).
Referring to claim 10, O’Neill, as modified, has taught the memory circuit of claim 1, wherein the processing circuitry is further configured to cause the memory circuit to: store the first bank data at the processing circuitry based at least in part on the decompressing (see column 16, lines 32-42. When decompressed, the decompressed data has to be stored to memory where it will wait for the update. Also, see column 29, lines 17-30, where based on the decompression, the system determines if there is enough storage for the package and, if not, current data on the computer may be rearranged/compressed so as to make room for the decompressed package).
Referring to claim 11, O’Neill, as modified, has taught the memory circuit of claim 1, wherein the processing circuitry is further configured to cause the memory circuit to: receive the firmware data, wherein accessing the firmware data is based at least in part on receiving the firmware data (see FIG.2A and the description thereof).
Claim 12 is mostly rejected for similar reasoning as claim 1. Further, to perform all of the claimed operations, a processor executes instructions stored in a memory (non-transitory computer-readable medium).
Claims 13-16 and 18-25 are rejected for similar reasoning as claims 2-5, 8-10, and 1-4, respectively.
Referring to claim 26, O’Neill, as modified, has taught the memory circuit of claim 1, wherein the processing circuitry is further configured to cause the memory circuit to: identify one or more boundaries associated with the portion of the firmware data based at least in part on the plurality of bank data sizes and the quantity of the plurality of compressed bank data included in the bank header, wherein identifying the portion of the firmware data comprising the first compressed bank data from the plurality of compressed bank data is based at least in part on identifying the one or more boundaries (see column 37, lines 16-40. Basically, the system determines the next bank to require an update (for instance, if the update was interrupted due to failure). To do this, the bank size and CRC information are compared to what is in the update package and if they match, then that bank has already been updated and the next bank is tested. The first bank that does match as expected needs to be updated. And, the size of that bank is indicated. Thus, the CRC and bank size together indicate which bank and its size, i.e., if the size is X, then the beginning boundary of the bank is its starting address/pointer and the end boundary is that starting address/pointer+X).
Claims 27-28 are rejected for similar reasoning as claim 26.
Response to Arguments
On page 17 of applicant’s response, applicant argues that a version is not a quantity of the plurality of compressed bank data.
The examiner agrees and has removed this mapping in the rejection. However, the examiner does believe that an error correction code is a quantity of compressed bank data.
On page 17 of applicant’s response, applicant argues that the file size is not the claimed quantity nor is it in the header.
The examiner is not relying on the file size to reject the claim at the moment, but disagrees it cannot be considered part of the header. While the examiner asserts that anything that is not the bank data itself can be considered part of the header, the examiner has updated the rejection to consider this obvious instead.
On pages 17-18 of applicant’s response, applicant argues that O’Neill’s bank sizes are not related to bank data sizes…wherein each bank data size corresponds to a size of a respective compressed bank data of the plurality of compressed bank data. Applicant also argues the bank sizes are not in a header.
The examiner respectfully disagrees. Banks may be different sizes in O’Neill and banks are updated one at a time. Therefore, the bank sizes indicate the size of the banks and therefore the maximum amount of data that can be stored therein. As described above, the examiner asserts it is obvious for the sizes to be in the header.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to David J. Huisman whose telephone number is 571-272-4168. The examiner can normally be reached on Monday-Friday, 9:00 am-5:30 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jyoti Mehta, can be reached at 571-270-3995. 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.
/David J. Huisman/Primary Examiner, Art Unit 2183