DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
The following claim(s) is/are pending in this office action: 1, 3, 5-15
The following claim(s) is/are amended: 1, 3, 11
The following claim(s) is/are cancelled: 2, 4
The following claim(s) is/are new: -
Claim(s) 1, 3, 5-15 is/are rejected.
Response to Arguments
Applicant’s arguments filed in the amendment filed 4/3/2026, have been fully considered but are moot in view of new grounds of rejection. The reasons set forth below.
Applicant’s Invention as Claimed
Claim Rejections - 35 USC § 103
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 of this title, 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, 3, 5-15 are rejected under 35 U.S.C. 103 as being unpatentable over Natsume (US Pub. 2010/0313192) in view of El-Hajj (US Pub. 2005/0203673) and further in view of Dwertmann (DE 10-2020-209-128 A1).
With respect to Claim 1, Natsume teaches an electronic control device mounted on a vehicle, the electronic control device comprising: a controller configured to execute a program in which a process of controlling a device mounted on the vehicle is mounted; (Fig. 1, paras. 3, 61, 66; ECU for an automobile has processor that controls processing of apparatuses mounted on the vehicle based on execution of an application program (control software).)
A memory configured to store an address list; (para. 72; memory. Para. 137; memory is set to identify an interruption location. Fig. 19, paras. 137-138; Block IDs of the blocks.)
a communication interface configured to receive update data used to update the program; (Fig. 2, para. 77; wireless or radio communication interface connected to ECU receives updated program)
and a storage configured to store the program, (para. 78-84; received updated program is stored in memory in ECU.)
and includes non-processed data not subjected to compression processing or encryption processing, the non-processed data holds the address list (Encryption or compression will be taught later. paras. 84-86; received data blocks are written to storage. Para. 13; program is described in address space. Fig. 12, para. 112; program is stored with a header and a fixed address area that stores the program. Figs. 19, 21, paras. 137-138; the individual data blocks may also have their own id such that Block 1 can be distinguished from Block 2.)
the update data includes a plurality of data blocks, the non-processed data comprises a header portion at a head of each data block of the plurality of data blocks (paras. 84-86; received data blocks are written to storage. Fig. 12, para. 112; program is stored with a header and a fixed address area that stores the program. Figs. 19, 21, paras. 137-138; the individual data blocks may also have their own id such that Block 1 can be distinguished from Block 2.)
the address list is included in the header portion, wherein the address list includes information capable of specifying each data block of the plurality of data blocks included in the update data (Figs. 19, 21, paras. 137-138; the individual data blocks may also have their own id such that Block 1 can be distinguished from Block 2. See also Fig. 22; alternate storage configuration where Block IDs are grouped together at start.)
when the process of writing the update version data block to the storage is interrupted in a middle, (paras. 73-76, 84-86, 111-116, 121-133; when the system receives an update to a program the system creates a separate storage area for the updated program, sets a completion flag to “0”, writes and verifies all data is received, and sets the completion flag to “1.” Para. 132-136; Alternatively, the system can flag “00” for writing, “01” for written-but-not-verified and “10” for written and verified. Therefore the system can determine whether a program has finished writing and/or verification or whether the process has been interrupted. Figs. 19, 21, paras. 137-138; System can also identify particular blocks so that an interruption can result in picking up from the particular block that whose writing/verification was interrupted.)
the controller specifies a data block in the update data corresponding to the update version data block to be rewritten according to the address list (Figs. 19, 21, paras. 137-138; System can also identify particular blocks so that an interruption can result in picking up from the particular block that whose writing/verification was interrupted.)
by acquiring the address list from the header portion, (paras. 84-86; received data blocks are written to storage. Fig. 12, para. 112; program is stored with a header and a fixed address area that stores the program. Figs. 19, 21, paras. 137-138; the individual data blocks may also have their own id such that Block 1 can be distinguished from Block 2.)
and designates the specified data block to re-acquire the update data, (para. 116-117; when the system restarts after an interruption, the system reacquires the update data and processes it.)
sets the resume address as the transfer start request address, transmits the transfer start request address to the communication interface, and receives from the communication interface, only a portion of the plurality of data blocks of the update data corresponding to the transfer start request and after the transfer start request. (A resume address will be taught later. para. 116-117; when the system restarts after an interruption, the system reacquires the update data and processes it. Fig. 22, paras. 141-144; Block IDs used to identify point at which rewriting was interrupted, and rewriting begins from that block. Para. 123; data block to be transmitted, which suggests single block transmission. Further, even if one read the disclosure as transmitting all of the blocks, both Natsume and Dwertmann disclose identifying particular areas that have not been updated and it would have been obvious to one of ordinary skill prior to the effective filing date to transfer only that data because the transfer of data that has already been successfully updated would serve no purpose. It is obvious to remove elements when the function of the element is not desired, see MPEP 2144.04(II)(A). See also Dwertmann, pg. 6; “This makes it possible not to transmit data sections have already been fully programmed.”)
But Natsume does not explicitly teach compression or encryption.
El-Hajj, however, does teach wherein the update data includes at least one of compressed data subjected to compression processing or encrypted data subjected to encryption processing, (paras. 43-48; vehicle on board unit performs wireless communication with a server to get application updates. Paras. 151-154, 374; communication may use compression and encryption.
the controller extracts an update version data block of the program to be written to the storage from the update data by at least performing one of decompressing the compressed data and decrypting the encrypted data, (paras. 395-399; decompression and decryption of a received message.)
It would have been obvious to one of ordinary skill prior to the effective filing to combine the device of Natsume and the compression and encryption in order to decrease the size and increase the security of the message being transmitted.
But modified Natsume does not explicitly teach determines a resume address in the update data according to the head address.
Dwertmann, however, does teach comprising a resume address describing a correspondence between a respective head address and a respective data block address written in the memory of each data block of the plurality of data blocks in the update data; (pg. 4; data is written to non-volatile memory at a specific physical memory address. Pg. 5; transfer points designate the start position of a new data section. The actual length can be specified if desired. pg. 6; resume points can be set which indicate points at which the write process can be resumed after an interruption. The resume points can be defined as absolute points or as relative addresses in the data object. Fig. 2, pg. 5; TD in transferred data object related to SP in stored memory. Further, RP identifies a specific point where the write process can be resumed.)
the controller receives, from the communication interface, a transfer start address request at a head of the update data; (First see Natsume, paras. 84-86; received data blocks are written to storage. Fig. 12, para. 112; program is stored with a header and a fixed address area that stores the program. Then see Dwertmann, pg. 4; data is written to non-volatile memory at a specific physical memory address. Pg. 5; transfer points designate the start position of a new data section. The actual length can be specified if desired.)
specifies a head address of the specified data block, (pg. 4; data is written to non-volatile memory at a specific physical memory address. Pg. 5; transfer points designate the start position of a new data section. The actual length can be specified if desired.)
determines the resume address according to the head address, (pg. 6; resume points can be set which indicate points at which the write process can be resumed after an interruption. The resume points can be defined as absolute points or as relative addresses in the data object.)
It would have been obvious to one of ordinary skill prior to the effective filing to combine the device of modified Natsume and the determines a resume address in the update data according to the head address in order to allow for relative addressing to keep order as lengths change due to decompression. (Dwertmann, pg. 5)
With respect to Claim 3, modified Natsume teaches the electronic control device according to claim 1, and Natsume also teaches wherein the controller stores the address list acquired from the header portion in the memory when writing the update version data block in the storage, paras. 84-86; received data blocks are written to storage. Fig. 12, para. 112; program is stored with a header and a fixed address area that stores the program. Figs. 19, 21, paras. 137-138; the individual data blocks may also have their own id such that Block 1 can be distinguished from Block 2.)
and the controller specifies a data block in the update data corresponding to the update version data block to be rewritten using the address list stored in the memory when a process of writing the update version data block into the storage is interrupted in a middle. (Figs. 19, 21, paras. 137-138; System can also identify particular blocks so that an interruption can result in picking up from the particular block that whose writing/verification was interrupted. para. 116-117; when the system restarts after an interruption, the system reacquires the update data and processes it.)
With respect to Claim 5, modified Natsume teaches the electronic control device according to claim 1, and El-Hajj also teaches wherein the data block is subjected to the compression processing, and a header portion of the data block is not compressed. (paras. 366-368, 374, 555; packet header includes encryption and compression fields. Para. 213, 396; payload is compressed. Para. 482; payload becomes virtual content when message is compressed or encrypted.)
The same motivation to combine as the independent claim applies here.
With respect to Claim 6, modified Natsume teaches the electronic control device according to claim 5, and El-Hajj also teaches wherein the controller acquires the update version data block by decompressing the update data for each data block, (para. 396; decompression of message.)
The same motivation to combine as the independent claim applies here.
And Natsume also teaches and the controller writes the update data into the storage for each update version data block. (paras. 73-76, 84-86, 111-116, 121-133; when the system receives an update to a program the system creates a separate storage area for the updated program, sets a completion flag to “0”, writes and verifies all data is received, and sets the completion flag to “1.”)
With respect to Claim 7, modified Natsume teaches the electronic control device according to claim 5, and El-Hajj also teaches wherein the update data is configured by aggregating one or more of the data blocks subjected to the compression processing and the header portion corresponding to the data block, (para. 362-365; reassembly of a multi-part message.)
the update data is subjected to the encryption processing for each of the data blocks, and the header portion is not encrypted. (paras. 366-368, 374, 555; packet header includes encryption and compression fields. Para. 213, 398-399; payload is encrypted and flag is set to indicate it. Para. 482; payload becomes virtual content when message is compressed or encrypted.)
The same motivation to combine as the independent claim applies here.
With respect to Claim 8, modified Natsume teaches the electronic control device according to claim 5, and El-Hajj also teaches wherein the update data is subjected to the encryption processing after being subjected to the compression processing, (para. 398; encryption after compression.)
and the controller acquires the update version data block by decrypting and then decompressing the update data. (paras. 395-399; decompression and decryption.)
The same motivation to combine as the independent claim applies here.
With respect to Claim 9, modified Natsume teaches the electronic control device according to claim 1, and Natsume also teaches wherein supplementary information of the data block is described at a head or a tail or a position between the head and the tail of the data block, (paras. 112, 138; top includes state ID or main ID of the program as a whole as to whether it has been verified. Block ID includes the state of each block.)
and the address list describes a position of a head of the data block or describes a position of the supplementary information arranged at a head of the data block. (para. 138; state of block is identified at a predetermined address of the block.)
With respect to Claim 10, modified Natsume teaches the electronic control device according to claim 1, and Natsume also teaches wherein the update data includes a second data block next to a first data block, and when a process of writing the second data block to the storage is interrupted in a middle after the first data block is written to the storage, the controller resumes the process of writing the update data to the storage from the second data block. (Figs. 19, 21, paras. 137-138; System can also identify particular blocks so that an interruption can result in picking up from the particular block that whose writing/verification was interrupted.)
With respect to Claim 11, modified Natsume teaches the electronic control device according to claim 10, and Natsume also teaches wherein: the memory stores write completion block information indicating that writing of the data block of the update data to the storage is completed, (paras. 73-76, 84-86, 111-116, 121-133; when the system receives an update to a program the system creates a separate storage area for the updated program, sets a completion flag to “0”, writes and verifies all data is received, and sets the completion flag to “1.” Para. 132-136; Alternatively, the system can flag “00” for writing, “01” for written-but-not-verified and “10” for written and verified. Therefore the system can determine whether a program has finished writing and/or verification or whether the process has been interrupted.)
each time a data block of the update data is written in the storage, the controller stores the write completion block information related to the data block in which writing is completed in the memory, and when the write completion block information indicates that the writing of the second data block to the storage is not completed, the controller resumes the process of writing the update data to the storage from the second data block. (Figs. 19, 21, paras. 137-138; System can also identify particular blocks so that an interruption can result in picking up from the particular block that whose writing/verification was interrupted.)
With respect to Claim 12, modified Natsume teaches the electronic control device according to claim 11, and Natsume also teaches wherein the controller diagnoses whether the update data is normally written to the storage according to the write completion block information. (paras. 73-76, 84-86, 111-116, 121-133; system verifies write. See also paras. 118-119; system writes an error log when an error occurs, which is also a diagnosing of normal writing.)
With respect to Claim 13, modified Natsume teaches the electronic control device according to claim 1, and El-Hajj also teaches wherein the vehicle includes a gateway device (para. 78-86; Vehicle OBU with a wireless interface may function as a data gateway.)
that temporarily stores the update data and transfers the temporarily stored update data to the electronic control device, the communication interface receives the update data via the gateway device, (paras. 78-81; OBU can transfer data to ECU. Para. 86; OBU may act as a server. Paras. 145-149; multi-part message may have some chunks sent at not others, and OBU may store received chunks. See also Natsume, paras. 71-72, 84; buffer stores received data until it is written to the flash ROM.)
The same motivation to combine as the independent claim applies here.
And Natsume also teaches and when resuming the write processing interrupted in a middle, the controller re-acquires the update data temporarily held by the gateway device. (para. 116-117; when the system restarts after an interruption, the system reacquires the update data and processes it. See also El-Hajj, Para. 86; OBU may act as a server.)
With respect to Claim 14, modified Natsume teaches the electronic control device according to claim 1, and El-Hajj also teaches wherein a first data block included in the update data is encrypted by using a second data block that is included in the update data and is different from the first data block, (para. 399; message content may include additional data such as a session ID to assist in decrypting the message. Therefore the session ID is a second data block.)
the update data includes an initialization vector used to decrypt a data block encrypted first in the update data, (para. 398-399; a public/private key encryption may be used to communicate a session key that is used to encrypt the content of messages.)
and when the second data block is a data block encrypted first in the update data, the controller acquires the second data block and the initialization vector together to decrypt the second data block. (para. 398-399; Session ID may be used in decryption. Therefore the private key (initialization) can be used on the encrypted session data (second data block) to generate the session key and assist in the decryption of the remainder of the message, including the first data block.)
The same motivation to combine as the independent claim applies here.
With respect to Claim 15, modified Natsume teaches the electronic control device according to claim 1, and El-Hajj also teaches wherein a first data block included in the update data is encrypted by using a second data block that is included in the update data and is different from the first data block, (para. 399; message content may include additional data such as a session ID to assist in decrypting the message. Therefore the session ID is a second data block.)
the update data includes an initialization vector used to decrypt a data block encrypted first in the update data, (para. 398-399; a public/private key encryption may be used to communicate a session key that is used to encrypt the content of messages.)
the first data block is arranged after the second data block in the update data, and when decrypting the first data block, the controller decrypts the first data block by acquiring the first data block and the second data block together. (para. 398-399; Session ID may be used in decryption. Therefore the private key (initialization) can be used on the encrypted session data (second data block) to generate the session key and assist in the decryption of the remainder of the message, including the first data block. Since the data from the second data block is used to decrypt the remainder of the message, it would have been obvious to one of ordinary skill prior to the effective filing date to include the session data first so that decryption can be performed as the rest of the message arrives.)
The same motivation to combine as the independent claim applies here.
Remarks
Applicant amends Claim 1 and argues the amended claim is nonobvious over the previously cited Natsume/El-Hajj/Dwertmann combination. Examiner finds the amended claim remains obvious over the combination and Examiner maintains the rejection. Applicant’s first argument for nonobviousness is that “Dwertmann merely suggests on page 6 that a resume point can indicate from which point or address that a write process can be resumed either as an absolute address or a relative address with reference to writing of a current data object. Nowhere does Dwertmann disclose or teach such reference points describing a correspondence between a respective head address and data block address written in memory of each data block…”
Applicant’s argument is unpersuasive because Applicant improperly piecemeal attacks the rejection. The combination renders the feature obvious. Examiner previously cited Natsume, which taught an update comprising a plurality of data blocks with headers for the blocks. Compare, e.g., Natsume Fig. 19 with Spec, Fig. 2. Applicant previously amended in head/resume addresses and argued (see Claims, Claim 1 and Remarks, pg. 9 of 9/4/2025 amendment) that “[a]t most, Natsume discloses identifying an ID storage part 401, and restarting rewriting based on the ID storage part 401…” i.e. Natsume differs from the amended claims in that Natsume only places an identifier within the update data and does not relate that to a position within the local memory. Examiner agreed and cited Dwertmann to teach resume points which are memory addresses that relate to transfer points/memory points, which are addresses in the transferred data.
Examiner does not understand the argument to complain about what Dwertmann was cited for – the correspondence between two addresses. Rather, the complaint appears to be that Dwertmann’s disclosure of the correspondence is not between “a respective head address and data block address written in memory.” In other words, Applicant complains that Dwertmann, Fig. 2 is not sufficiently close to Spec, Fig. 2. Examiner seriously questions how different Dwertmann Fig. 2 and Spec, Fig. 2 are. Examiner acknowledges that Dwertmann doesn’t use the terms “header” or “head” but TD1…n are directly analogous to what Spec calls Local Header 321 and Natsume calls BlockIDs 402a. Still, the distinction is irrelevant because regardless of whether Dwertmann teaches a header, Applicant does not dispute that Natsume teaches a header identifying one of a plurality of blocks and Applicant does not dispute that Dwertmann teaches a correspondence between the update data and the local memory storage. The combination teaches the amended claim language of a resume address describing a correspondence between a respective head address and a respective data block address.
Applicant next argues the claims are nonobvious because the amended claims require “receives…only a portion of the plurality of data blocks of the update data corresponding to the transfer start request.” Applicant reads Natsume paras. 116-117 as requiring transfer of the entire program, because Natsume states “acquires the data of the update version program from the rewriting tool 310 once more.”
The combination renders the claim feature obvious in three separate ways. First, Examiner asserts Applicant misreads Natsume. Natsume paras. 116-117 are referring to the update of a program with a single data block, see Fig. 12. Thus, when Natsume discusses acquiring the data “once more” that is because the entire program is in state “0” (an incomplete rewrite). But when Natsume begins to discuss an updating with multiple blocks as in Fig. 19, it makes clear that the function of the individual BlockIDs is to allow for breaking up the update data and allowing for partial completion of the rewrite and verification process. Fig. 21 and para. 142 are the most clear here: When the main identifying ID is “0” (i.e. the program has not been fully rewritten) the system begins interrogating BlockIDs until it finds a BlockID that is “00”and then “the firmware and the rewriting tool are started so that rewriting is resumed from that block.” Examiner asserts that suggests transferring only that and subsequent blocks and not transferring the preceding blocks.
Second, even if Applicant were correct that Natsume anticipates transmitting all of the data again, Natsume would render the claimed feature obvious. Natsume enables identification of particular data blocks through its BlockIDs. Therefore, Natsume renders obvious transmitting only the data necessary because a disclosure that includes transmitting all blocks but enables individual block identification renders transmitting only useful blocks obvious because omission of an element is obvious when the function of the element is not desired, see MPEP 2144.04(II)(A). Here, the blocks that have already been successfully updated have no function, and their re-transfer serves no purpose whatsoever, which makes it obvious to not transfer those blocks.
Third, Dwertmann, pg. 6 explicitly teaches that one benefit of its resume feature is to avoid retransmission: “[i]f the data transmission in interrupted during programming, the last stored values can be evaluated and/or transmitted to the programming module in order to indicate up to which point the transmitted data have already been stored. This makes it possible not to transmit data sections that have already been fully programmed, even in the case of compressed, encrypted, or otherwise processed data, and to continue the transmission and storage of the data at a suitable point.” The combination teaches the feature.
The amended claims remain obvious over the combination of references. All claims remain rejected.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS P CELANI whose telephone number is (571)272-1205. The examiner can normally be reached on M-F 9-5.
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, Vivek Srivastava can be reached on 571-272-7304. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/NICHOLAS P CELANI/Examiner, Art Unit 2449
Prosecution Insights