DETAILED ACTION
Priority
Applicant’s claim for the benefit to EP 24197797 filed September 2, 2024 is acknowledged. Priority documents were received September 8, 2025.
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 .
Claim Interpretation
Explicit definitions for the following claim terms were identified within the original specification: “locally accessible” ¶46; “data parts” ¶65; “that would cause one or more updates” ¶65; “access request” ¶69; “responsive to a successful access request” ¶69; and miscellaneous terms (e.g. ‘a’, ‘the’, ‘comprise’ , ‘above’, ‘below’) are defined in ¶110-¶114.
With regard to claim 1, the language “that would cause one or more updates to data stored by said other ECU” (when viewed in light of the definition provided in Paragraph [0065] of the original specification) appears to be a recitation of intended sue of the configuration data that is identified. The claim limitation does not impose a functional limitation on the claimed device. Instead this claim limitation appears to be describing the data that is identified. The description being how the data is intended to be used, e.g. the intended use of the data. The claimed device does not require updating the other ECUs. The only ‘updating’ operation recited in the claim is the updating of the virtual data storage, which when read in light of the instant specification, does not appear to require the ECUs themselves to be updated.
With regard to claim 6, the claim recites that the data parts stored in the virtual data store ‘that is to be obtained’ by the other ECUs. The language ‘that is to be obtained’ is an intended use of the data parts that does not impart a functional limitation on the claimed device. The intention of what the data parts are to be used to do, does not change the function of the claimed device.
Recitation of intended uses do not impose functional or structural limitations on a claimed device. It is suggested that the claims be amended to not raise the question of intended use limitation, and instead recite the structure and function that applicant seeks patent protection coverage over.
112 sixth paragraph
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 following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
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.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
“switching device… configured to relay the access request between the other ECUs and the virtual data store” in claim 11.
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.
The “switching device” of claim 11 has been interpreted in light of Paragraph [0078] of the original specification as an “Ethernet switch”.
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 § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 19 and 20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because these claims appear to be directed to software per se.
With regard to claim 19, the claim is directed to “A computer program product comprising program code”. One of ordinary skill in the art would recognize this as explicitly reciting that the claimed device is program code per sae. The ‘processing circuitry’ recited in the preamble of claim 19, is not part of the computer program product to which the claim is directed, but is recited as an external element not part of the claimed device itself. It is suggested that the claim be amended to recite -- A computer program product comprising: processing circuitry and program code; wherein when the program code is executed by the processing circuitry: performing the method of claim 18.--
With regard to claim 20, the claim is directed to “A non-transitory computer-readable storage medium comprising instructions”. The non-transitory computer-readable-storage medium is not recited as storing said instructions, but is instead recited as comprising said instructions. Meaning that the non-transitory computer-readable storage medium is made up of the instructions themselves, and is not a hardware device capable of storing the instructions. Therefore, one of ordinary skill in the art would recognize this as explicitly reciting that the claimed device is instructions per sae. The ‘processing circuitry’ recited in the preamble of claim 20, is not part of the non-transitory computer-readable storage medium to which the claim is directed, but is recited as an external element. It is suggested that the claim be amended to explicitly recite the claimed --non-transitory computer-readable storage medium comprising: a memory storing instructions; and processing circuitry; wherein the instructions, when executed by the processing circuitry, cause the processing circuitry to perform the method of claim 18—
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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Zellen [2014/0245278] in view of Itatsu [2021/0397433].
With regard to claim 1 Zellen teaches A computer system as apparatus 10 (Zellen, ¶20 “FIG. 1 is a block diagram illustrating one embodiment of an automotive software update arrangement 10 of the present invention. Apparatus 10 may include an automobile 12 having a memory device 14 storing a database of installed software files and versions”) for replicating data as performing software update (Id) among [[ as the communication within the automobile (Zellen, ¶20 “Also within automobile 12 is a hard drive 16 that may include a processor, and which may be in communication with memory device 14.”) of a marine vessel as the automobile (Id; Please note that the specific type of vehicle, e.g. marine vessel vs automobile, has been identified as being non-functional descriptive material describing a vehicle that one of ordinary skill in the art would recognize as being substantially similar within the context of the claimed device), the computer system comprising processing circuitry as the processor (Id) configured to:
control a first ECU as a USB port (Zellen, ¶22 “Thus. USB memory device 24 may be inserted into the USB port such that the updated files may be copied from USB memory device 24 to memory device 14.”) from among the plurality of ECUs to:
update as update (Zellen, ¶22) a virtual data storage as the database within the automobile (Zellen, ¶20 “Apparatus 10 may include an automobile 12 having a memory device 14 storing a database of installed software files and versions.”; Figure 1, 14) based on configuration data as update files (Zellen, ¶22 “Alternatively, automobile 12 may receive updated files from a virtual repository 24, which may be in the form of a portable memory device, such as a USB memory device storing the latest versions of the software files stored in memory device 14.”) from a data carrier device as the virtual repository 24, which may be in the form of a portable memory device, such as a USB memory device (Id), the virtual data storage being locally accessible as the database being within the automobile (Zellen, ¶20; Please note this claim limitation has been read in light of Paragraph [0046] as being within the perimeters of the vehicle) by [[
[[
identify [data parts] as determining as the files of the list not already stored (Zellen, ¶25 “The processor of automobile 12 may look at the version number of the software files on USB memory device 24 and compare the version numbers to the version numbers of the software files already stored in memory device 14. Next, the processor may copy from USB memory device 24 only the software files whose latest versions are not already stored in memory device 14.”; Please note this claim limitation has been read in light of Paragraph [0065] of the original specification which defines ‘data parts’ as “individual segments or portions of the complete configuration data”) of the configuration data as update files (Zellen, ¶22 “Alternatively, automobile 12 may receive updated files from a virtual repository 24, which may be in the form of a portable memory device, such as a USB memory device storing the latest versions of the software files stored in memory device 14.”) [that would cause one or more updates] as the latest versions are not already stored (Id; Please note this claim limitation has been read in light of Paragraph [0065] of the original specification as being defined to mean “that the identified data parts, when applied or installed, would modify or enhance the existing data stored in the other ECUs”) to [[
obtain as receiving the updated files (Zellen, ¶22 “automobile 12 may receive updated files from a virtual repository 24”; ¶27 “after automobile 12 has received the request to update the software files stored in automobile 12, automobile 12 may transmit a query to network repository 18 to list the following three software files that are stored in
memory device 14 and that may need to be updated:”) said one or more data parts of the configuration data as the files of the list not already stored (Zellen, ¶25 “The processor of automobile 12 may look at the version number of the software files on USB memory device 24 and compare the version numbers to the version numbers of the software files already stored in memory device 14. Next, the processor may copy from USB memory device 24 only the software files whose latest versions are not already stored in memory device 14.”) [responsive to a successful access request] as a request to access (Zellen, ¶27 “after automobile 12 has received the request to update the software files stored in automobile 12, automobile 12 may transmit a query to network repository 18 to list the following three software files that are stored in memory device 14 and that may need to be updated:”; Please note this claim limitation has been read in light of Paragraph [69] where it is defined as ‘the virtual data storage acknowledges and grants the access request, allowing the other ECU to retrieve the requested data parts”) [[as the database within the automobile (Zellen, ¶20 “Apparatus 10 may include an automobile 12 having a memory device 14 storing a database of installed software files and versions.”; Figure 1, 14).
Zellen does not explicitly teach electronic control units, ECUs, wherein the ECUs are connected to the same backbone network…. One or more ECUs from among the plurality of ECUs via the backbone network; and control said other ECUs to:…updated to data stored by said other ECUs…
Itatsu teaches replicating data as updating programs (Itatsu, ¶44 “An on-board ECU 3 provided in the vehicle acquires an update program transmitted from the program providing device S1 via wireless communication, adopts the update program as a program to be executed, and is thus able to update the program to be executed by the ECU (reprogram).”) among a plurality of electronic control units as the plurality of on-board ECUs (Itatsu, ¶46 “The vehicle C is provided with the vehicle exterior communication device 1, the on-board update device 2, a display device 5, and a plurality of on-board ECUs 3 for controlling various on-board devices”), ECUs, wherein the ECUs (Id) are connected to the same backbone network as an interior LAN, CAN, or Ethernet (Itatsu, ¶46 “The vehicle exterior communication device 1 and the on-board update device 2 are connected via a harness such as a serial cable harness so as to be able to communicate with each other. The on-board update device 2 and the on-board ECU 3 are connected via a vehicle interior LAN 4 that conforms to a communication protocol such as a CAN (Control Area Network (registered trademark)) or Ethernet (registered trademark) so as to be able to communicate with each other.”) of a marine vessel as vehicle C (Itatsu, ¶46)…
Control a first ECU as the on-board update device 2 (Itatsu, ¶49; Figure 1, 2) from among the plurality of ECUs as the plurality of ECUs (Itatsu, ¶46; Figure 1, 3) to:
update a virtual storage as storage unit 21 (Itatsu, ¶51; Figure 2, 21) based on configuration data as updated control program (Itatsu, ¶51 “Also, the control program may be a control program downloaded from an external computer (not shown) connected to a communication network (not shown), and stored in the storage unit 21. Furthermore, configuration information regarding all the on-board ECUs 3 provided in the vehicle C is stored in the storage unit 21 (the predetermined storage area). The storage unit 21 stores the update program acquired from the program providing device S1”) from a data carrier device as downloaded from external computer (Id), the virtual data storage as storage unit 21 (Id) being locally accessible (Itatsu, ¶52) by one or more other ECUs from among the plurality of ECUs via the backbone network (Itatsu, ¶52 “The vehicle interior communication units 23 are input/output interfaces that employ a communication protocol such as a CAN (Control Area Network) or Ethernet (registered trademark), and the control unit 20 communicates with the on-board ECUs 3 that are connected to the vehicle interior LAN 4 or another on-board device such as a relay device with each other via the vehicle interior communication units 23.”); and
control said other ECUs as each ECU 3 performing the update (Itatsu, ¶59 “After the reception of the update program is completed normally, i.e. after the reception of all of the divided blocks is complete, upon a predetermined operation such as the IG switch of the vehicle C being switched ON and OFF, the control unit 30 of the on-board ECU 3 performs switching of the operating region, and adopts and executes the received update program as the current version of the program.”) to:
identify [data parts] as the divided block segments (Itatsu, ¶52 “In this way, the vehicle interior LAN 4 is divided into a plurality of segments by providing a plurality of vehicle interior communication units 23, and each on-board ECU is connected to any of the segments according to the function (the control system function, the safety system function, or the body system function) of the on-board ECU.”; ¶59) as determining of the configuration data [that would cause one or more updates] to data stored by said other ECUs (Itatsu, ¶53 “Each on-board ECU 3 includes a control unit 30… a program or data for the on-board ECU 3 is stored therein. This program or data is the update target that is to be updated with the update program transmitted from the on-board update device 2.”), and
obtain said one or more data part of the configuration data [responsive to a successful access request] between said other ECUs as the control unit 30 of each ECU receives the update program (Itatsu, ¶57 “The control unit 30 of the on-board ECU 3 receives an update program transmitted from the on-board update device 2, via the vehicle interior communication unit 32, and acquires the update program.”) and the virtual data storage as the update is received from the on-board update device 2 (Id).
It would have been obvious to one of ordinary skill to which said subject matter pertains at the time the invention was filed to have implemented the vehicle on-board update device taught by Itatsu to acquire the update data (Itatsu, ¶44) using the portable memory device taught by Zellen (¶8, 22, ¶25) and the file-by-file granularity software update (Zellen, ¶19). The proposed combination simply substitutes the wireless communication taught by Itatsu (¶44 “An on-board ECU 3 provided in the vehicle acquires an update program transmitted from the program providing device S1 via wireless communication, adopts the update program as a program to be executed, and is thus able to update the program to be executed by the ECU (reprogram).”) with the portable memory device taught by Zellen (Zellen, ¶22, ¶25). This combination would yield the predictable results of providing flexible source of software (Zellen, ¶12).
One of ordinary skill in the art would recognize the file-by-file granularity software update taught by Zellen (¶19) using the version numbers (¶25; ¶29) may be used as the means of performing the block division (Itatsu, ¶58). Within the proposed combination this would improve the device taught by Itatsu to enable the version numbers (Itatsu, Fig 10, see Version numbers in Vehicle configuration information table) to be used to enable the file-by-file granularity yielding the predictable results of minimizing the number of transactions and necessary size of target memory (Zellen, ¶9, ¶10), improving traceability (Zellen, ¶11),
It should be noted that Zellen is silent regarding the internal structure of the motor vehicle. One of ordinary skill in the art would recognize that within the proposed combination, the internal structure of the device may be implemented as taught by Itatsu while using the updating method taught by Zellen as detailed above for the above recited reasoning.
With regard to claim 2 the proposed combination further teaches wherein the computer system is operable offline, the processing circuitry being operable to carry out the control of the ECUs agnostic to internet connectivity (Zellen, ¶25 “In the case of a virtual repository in the form of a USB memory device 24, the manufacturer of automobile 12 or some other service personnel may periodically ship USB memory device 24 to a local service garage or directly to the home of the owner of automobile 12. Service personnel or the owner of automobile 12 may insert USB memory device 24 into the USB port of automobile 12.”).
With regard to claim 3 the proposed combination further teaches wherein the processing circuitry as the processor (Zellen, ¶20 “Also within automobile 12 is a hard drive 16 that may include a processor, and which may be in communication with memory device 14.”) is configured to control the first ECU as the USB Port (Zellen, ¶22 “Thus. USB memory device 24 may be inserted into the USB port such that the updated files may be copied from USB memory device 24 to memory device 14.”) to update as update (Zellen, ¶22) the virtual data storage as the database within the automobile (Zellen, ¶20 “Apparatus 10 may include an automobile 12 having a memory device 14 storing a database of installed software files and versions.”; Figure 1, 14) by:
setting up a fileserver as a separate file that includes a list of all other files (Zellen, ¶26 “USB memory device 24 may include a separate file that includes a list of all the other files stored on USB memory device 24 and their associated version numbers.”) in the virtual data storage as copying files not stored in the memory device (Zellen, ¶25 “Next, the processor may copy from USB memory device 24 only the software files whose latest versions are not already stored in memory device 14.”; ¶26 “Thus, the processor of automobile 12 may have easy access to the version numbers of the software files stored on USB memory device 24, which may facilitate the comparison of these version numbers to the version numbers of the software files already stored in memory device 14.”) and transferring the configuration data thereto as copy (Zellen, ¶25 “Next, the processor may copy from USB memory device 24 only the software files whose latest versions are not already stored in memory device 14.”), or
updating an existing fileserver in the virtual data storage with the configuration data as updating the versions of files identified as not being the latest (Zellen, ¶29 “Upon receiving the above list of the latest versions of each of the three software files available from network repository 18, automobile 12 may compare the latest version numbers of the files available from network repository 18 to the version numbers of the files already stored in memory device 14, as illustrated in the following Table I: … Thus, as a result of the above comparisons, automobile 12 may request from network repository 18 version 4 of File A and version 15 of File B. Version3 of File A and version 12 of File B in memory device 14 may be overwritten.”).
With regard to claim 4 the proposed combination further teaches wherein fileserver as a separate file that includes a list of all other files (Zellen, ¶26 “USB memory device 24 may include a separate file that includes a list of all the other files stored on USB memory device 24 and their associated version numbers.”), such as the Vehicle configuration information master table (Itatsu, Figure 10) comprises a link (¶66 “The MAC address is an address corresponding to the data link layer when the vehicle interior communication unit 23 of the on-board ECU 3 is a communication port that supports Ethernet”; Figure 10, see MAC address, and IP address) accessible by said other ECUs to the configuration data (Itatsu, ¶57 “The control unit 30 of the on-board ECU 3 receives an update program transmitted from the on-board update device 2, via the vehicle interior communication unit 32, and acquires the update program.”) stored in the data carrier device as the update store din the virtual repository 24 (Zellen, ¶22 “Alternatively, automobile 12 may receive updated files from a virtual repository 24, which may be in the form of a portable memory device, such as a USB memory device storing the latest versions of the software files stored in memory device 14.”).
With regard to claim 5 the proposed combination further teaches wherein the control of said other ECUs to identify the data parts comprises as the files of the list not already stored (Zellen, ¶25 “The processor of automobile 12 may look at the version number of the software files on USB memory device 24 and compare the version numbers to the version numbers of the software files already stored in memory device 14. Next, the processor may copy from USB memory device 24 only the software files whose latest versions are not already stored in memory device 14.”; Please note this claim limitation has been read in light of Paragraph [0065] of the original specification which defines ‘data parts’ as “individual segments or portions of the complete configuration data”), at said other ECUs:
receiving a message from the virtual data storage as the database within the automobile (Zellen, ¶20 “Apparatus 10 may include an automobile 12 having a memory device 14 storing a database of installed software files and versions.”; Figure 1, 14) indicating said update of the configuration data (Zellen, ¶29 “Thus, as a result of the above comparisons, automobile 12 may request from network repository 18 version 4 of File A and version 15 of File B. Version3 of File A and version 12 of File B in memory device 14 may be overwritten.”);
identifying an absence of said update in a memory of said other ECUs as identifying that File C is already up to date and thus does not need to be updated (Zellen, ¶29 “Upon receiving the above list of the latest versions of each of the three software files available from network repository 18, automobile 12 may compare the latest version numbers of the files available from network repository 18 to the version numbers of the files already stored in memory device 14, as illustrated in the following Table I…” See Table 1 File C already has version 9); and
controlling submission of said [access request] as not requesting the update for File C (Zellen, ¶29 “automobile 12 may not request from network repository 18 version 9 of File C.”; ¶33 “their version identifiers may be electronically accessed.”; Please note this claim limitation has been read in light of Paragraph [69] where it is defined as ‘a formal request initiated by an other ECU to retrieve specific data from the virtual data storage”) to the virtual data storage as the database within the automobile (Zellen, ¶20 “Apparatus 10 may include an automobile 12 having a memory device 14 storing a database of installed software files and versions.”; Figure 1, 14).
With regard to claim 6 the proposed combination further teaches wherein the processing circuitry is further configured to, prior to controlling the other ECUs to obtain the data parts, encrypt the data parts stored in the virtual data storage that is to be obtained by the other ECUs (Itatsu, ¶45 “When the update program is transmitted, an external file that contains such a program code and data is transmitted from the program providing device S1 as, for example, encrypted archive file.”).
With regard to claim 7 the proposed combination further teaches wherein the data carrier device is a removable storage device as the virtual repository 24, which may be in the form of a portable memory device, such as a USB memory device (Zellen, ¶22 “Alternatively, automobile 12 may receive updated files from a virtual repository 24, which may be in the form of a portable memory device, such as a USB memory device storing the latest versions of the software files stored in memory device 14.”) connectable to an input port of the first ECU (Zellen, ¶22 “Thus. USB memory device 24 may be inserted into the USB port such that the updated files may be copied from USB memory device 24 to memory device 14.”), wherein the processing circuitry as the processing circuitry (Zellen, ¶20 “Also within automobile 12 is a hard drive 16 that may include a processor, and which may be in communication with memory device 14.”) is configured to control the first ECU ¶22 “Thus. USB memory device 24 may be inserted into the USB port such that the updated files may be copied from USB memory device 24 to memory device 14.”) to update the virtual data storage (Zellen, ¶25 “Next, the processor may copy from USB memory device 24 only the software files whose latest versions are not already stored in memory device 14.”) with the configuration data as update files (Zellen, ¶22 “Alternatively, automobile 12 may receive updated files from a virtual repository 24, which may be in the form of a portable memory device, such as a USB memory device storing the latest versions of the software files stored in memory device 14.”) in response to said data carrier device connecting to the first ECU (Zellen, ¶25 “Service personnel or the owner of automobile 12 may insert USB memory device 24 into the USB port of automobile 12.”).
With regard to claim 8 the proposed combination further teaches wherein the processing circuitry is further configured to, prior to controlling the first ECU to obtain the configuration data (Zellen, ¶31 “Thus, as a result of the above comparisons, automobile 12 may copy from USB memory device 24 version 3.3 of File A and version 6.2 of File C. Version 3.2 of File A and version 5.3 of File C in memory device 14 may be overwritten”), authenticate as detecting the presence (Zellen, ¶30) the removable storage device as it connects to the first ECU as the connection of the USB memory device into the USB port (Zellen, ¶30 “In another specific example embodiment to further illustrate the inventive method, after service personnel or the owner of automobile 12 has inserted USB memory device 24 into the USB port of automobile 12, automobile 12 may first detect the presence of the connection of USB memory device 24 to the USB port of automobile”).
With regard to claim 9 the proposed combination further teaches wherein the data carrier device as the data downloaded from the external device to the internal storage (Zellen, ¶22 “Alternatively, automobile 12 may receive updated files from a virtual repository 24, which may be in the form of a portable memory device, such as a USB memory device storing the latest versions of the software files stored in memory device 14.”; Itatsu ¶51 ) is an internal (Itatsu, Figure 2, 21, see Storage unit 21 is internal to On-board update device 2) memory of the first ECU as the on-board update device 2 (Itatsu, Figure 2, 2)
With regard to claim 10 the proposed combination further teaches wherein the processing circuitry as the processor (Zellen, ¶20 “Also within automobile 12 is a hard drive 16 that may include a processor, and which may be in communication with memory device 14.”) is configured to control the first ECU as a USB port (Zellen, ¶22 “Thus. USB memory device 24 may be inserted into the USB port such that the updated files may be copied from USB memory device 24 to memory device 14.”) to update the virtual data storage (Zellen, ¶20 “Apparatus 10 may include an automobile 12 having a memory device 14 storing a database of installed software files and versions.”; Figure 1, 14) in response to one or more of:
a manual user input received at an ECU being a display device (Itatsu, ¶60 “The display device 5 is an HMI (Human Machine Interface) device such as a display of a car navigation system, for example.”; ¶81),
a software functionality trigger as automatic detection (Zellen, ¶33 “In another specific example embodiment to further illustrate the inventive method, after service personnel or the owner of automobile 12 has inserted USB memory device 24 into the USB port of automobile 12, automobile 12 may first detect the presence of the connection of USB memory device 24 to the USB port of automobile 12.”; Please note this claim limitation has been read in light of Paragraph [64] as detecting the insertion of the removable storage device) automatically identifying the data carrier device as the USB memory device (Id), and
a predetermined time period having lapsed as periodically updated software (Zellen, ¶4 “Automotive electronics typically include software that is periodically updated by the manufacturer of the automobile.”; ¶25 “In the case of a virtual repository in the form of a USB memory device 24, the manufacturer of automobile 12 or some other service personnel may periodically ship USB memory device 24 to a local service garage or directly to the home of the owner of automobile 12.”).
With regard to claim 11 the proposed combination further teaches wherein the backbone network comprises a switching device (Itatsu, ¶46 “The on-board update device 2 and the on-board ECU 3 are connected via a vehicle interior LAN 4 that conforms to a communication protocol such as a CAN (Control Area Network (registered trademark)) or Ethernet (registered trademark) so as to be able to communicate with each other.”; ¶52; ¶66; Please note this claim limitation has been interpreted in light of 112f and paragraph [78] of the original specification as an “Ethernet switch”) interfacing the first ECU and the other ECUs and configured to relay the access request(s) (Itatsu, ¶127 “Although the on-board update device 2 in the present embodiment is a gateway (a relay device) that generally controls the segments of a plurality of systems of the on-board ECUs 3”) between the other ECUs as the on-board ECUs 3 (Id) and the virtual data storage as the on-bard update device 2 (Id) storage unit 21 (Itatsu, ¶51) which one of ordinary skill in the art would identify as being parallel to the database within the automobile (Zella, ¶22) within the proposed combination.
With regard to claim 12 the proposed combination further teaches wherein the configuration data comprises one or more of software update data (Zellen, ¶4 “Automotive electronics typically include software that is periodically updated by the manufacturer of the automobile. Current implementations of software updates require either the unit to be removed from the assembly for a firmware update or the utilization of a full file system update.”), firmware update data as firmware update (Id), user profile data, system data, diagnostic data, security patch data, operational data (¶55 “information regarding the operating region.”), calibration data, application data, and performance tuning data.
With regard to claim 13 the proposed combination further teaches wherein the backbone network is based on Ethernet (Itatsu, ¶46 “The on-board update device 2 and the on-board ECU 3 are connected via a vehicle interior LAN 4 that conforms to a communication protocol such as a CAN (Control Area Network (registered trademark)) or Ethernet (registered trademark) so as to be able to communicate with each other.”; ¶52; ¶66).
With regard to to claim 14 the proposed combination further teaches wherein the ECUs are wiredly (Please note Paragraph [43] details Ethernet Cables as example of “wired connections”) connected to the backbone network as vehicle interior communication, such as CAN or Ethernet protocols (Itatsu, ¶52 “The vehicle interior communication units 23 are input/output interfaces that employ a communication protocol such as a CAN (Control Area Network) or Ethernet (registered trademark), and the control unit 20 communicates with the on-board ECUs 3 that are connected to the vehicle interior LAN 4 or another on-board device such as a relay device with each other via the vehicle interior communication units 23.”).
With regard to claim 15 the proposed combination further teaches A marine vessel as an automotive (Zellen, ¶20 “Apparatus 10 may include an automobile 12 having a memory device 14 storing a database of installed software files and versions.”) comprising the computer system of claim 1 (See above mapping for claim 1).
With regard to claim 16 the proposed combination further teaches further comprising one or more ECUs being connected to the same backbone network of the marine vessel (Itatsu, Figure 1 See Vehicle C containing the ECUs 3).
With regard to claim 17 the proposed combination further teaches wherein the backbone network is based on Ethernet, and wherein the ECUs are wiredly (Please note Paragraph [43] details Ethernet Cables as example of “wired connections”) connected to the backbone network as vehicle interior communication, such as CAN or Ethernet protocols (Itatsu, ¶52 “The vehicle interior communication units 23 are input/output interfaces that employ a communication protocol such as a CAN (Control Area Network) or Ethernet (registered trademark), and the control unit 20 communicates with the on-board ECUs 3 that are connected to the vehicle interior LAN 4 or another on-board device such as a relay device with each other via the vehicle interior communication units 23.”).
With regard to claim 18 Zellen teaches A computer-implemented method as the method (Zellen, ¶27) for replicating data as performing software update (Zellen, ¶20 “FIG. 1 is a block diagram illustrating one embodiment of an automotive software update arrangement 10 of the present invention. Apparatus 10 may include an automobile 12 having a memory device 14 storing a database of installed software files and versions”) among [[ as the communication within the automobile (Zellen, ¶20 “Also within automobile 12 is a hard drive 16 that may include a processor, and which may be in communication with memory device 14.”) of a marine vessel as the automobile (Id), the method comprising:
controlling, by processing circuitry as the processor (Zellen, ¶20) of a computer system as apparatus 10 (Zellen, ¶20), a first ECU as a USB port (Zellen, ¶22 “Thus. USB memory device 24 may be inserted into the USB port such that the updated files may be copied from USB memory device 24 to memory device 14.”) from among the plurality of ECUs to update as update (Zellen, ¶22) a virtual data storage as the database within the automobile (Zellen, ¶20 “Apparatus 10 may include an automobile 12 having a memory device 14 storing a database of installed software files and versions.”; Figure 1, 14) based on configuration data as update files (Zellen, ¶22 “Alternatively, automobile 12 may receive updated files from a virtual repository 24, which may be in the form of a portable memory device, such as a USB memory device storing the latest versions of the software files stored in memory device 14.”) from a data carrier device as the virtual repository 24, which may be in the form of a portable memory device, such as a USB memory device (Id), the virtual data storage being locally accessible as the database being within the automobile (Zellen, ¶20; Please note this claim limitation has been read in light of Paragraph [0046] as being within the perimeters of the vehicle) by [[
controlling, by the processing circuitry as the processor (Zellen, ¶20), the other ECUs to identify data parts as the files of the list not already stored (Zellen, ¶25 “The processor of automobile 12 may look at the version number of the software files on USB memory device 24 and compare the version numbers to the version numbers of the software files already stored in memory device 14. Next, the processor may copy from USB memory device 24 only the software files whose latest versions are not already stored in memory device 14.”; Please note this claim limitation has been read in light of Paragraph [0065] of the original specification which defines ‘data parts’ as “individual segments or portions of the complete configuration data”) of the configuration data as update files (Zellen, ¶22 “Alternatively, automobile 12 may receive updated files from a virtual repository 24, which may be in the form of a portable memory device, such as a USB memory device storing the latest versions of the software files stored in memory device 14.”) [that would cause one or more updates] as the latest versions are not already stored (Id; Please note this claim limitation has been read in light of Paragraph [0065] of the original specification as being defined to mean “that the identified data parts, when applied or installed, would modify or enhance the existing data stored in the other ECUs”) to [[ as receiving the updated files (Zellen, ¶22 “automobile 12 may receive updated files from a virtual repository 24”; ¶27 “after automobile 12 has received the request to update the software files stored in automobile 12, automobile 12 may transmit a query to network repository 18 to list the following three software files that are stored in memory device 14 and that may need to be updated:”) said one or more data parts of the configuration data as the files of the list not already stored (Zellen, ¶25 “The processor of automobile 12 may look at the version number of the software files on USB memory device 24 and compare the version numbers to the version numbers of the software files already stored in memory device 14. Next, the processor may copy from USB memory device 24 only the software files whose latest versions are not already stored in memory device 14.”) [responsive to a successful access request] as a request to access (Zellen, ¶27 “after automobile 12 has received the request to update the software files stored in automobile 12, automobile 12 may transmit a query to network repository 18 to list the following three software files that are stored in memory device 14 and that may need to be updated:”; Please note this claim limitation has been read in light of Paragraph [69] where it is defined as ‘the virtual data storage acknowledges and grants the access request, allowing the other ECU to retrieve the requested data parts”) [[as the database within the automobile (Zellen, ¶20 “Apparatus 10 may include an automobile 12 having a memory device 14 storing a database of installed software files and versions.”; Figure 1, 14).
Zellen does not explicitly teach a plurality of electronic control units, ECUs, wherein the ECUs are connected to the same backbone network…. from among the plurality of ECUs via the backbone network; one or more other ECUs from among the plurality of ECUs via the backbone network; and controlling… the other ECUs to:…updates to data stored by said other ECUs… between said other ECUs.
Itatsu teaches replicating data as updating programs (Itatsu, ¶44 “An on-board ECU 3 provided in the vehicle acquires an update program transmitted from the program providing device S1 via wireless communication, adopts the update program as a program to be executed, and is thus able to update the program to be executed by the ECU (reprogram).”) among a plurality of electronic control units as the plurality of on-board ECUs (Itatsu, ¶46 “The vehicle C is provided with the vehicle exterior communication device 1, the on-board update device 2, a display device 5, and a plurality of on-board ECUs 3 for controlling various on-board devices”), ECUs, wherein the ECUs (Id) are connected to the same backbone network as an interior LAN, CAN, or Ethernet (Itatsu, ¶46 “The vehicle exterior communication device 1 and the on-board update device 2 are connected via a harness such as a serial cable harness so as to be able to communicate with each other. The on-board update device 2 and the on-board ECU 3 are connected via a vehicle interior LAN 4 that conforms to a communication protocol such as a CAN (Control Area Network (registered trademark)) or Ethernet (registered trademark) so as to be able to communicate with each other.”) of a marine vessel as vehicle C (Itatsu, ¶46)…
Controlling, by processing circuitry as control unit 20 (Figure 2, 20) of a computer system as the vehicle system (Figure 1, C), a first ECU as the on-board update device 2 (Itatsu, ¶49; Figure 1, 2) from among the plurality of ECUs as the plurality of ECUs (Itatsu, ¶46; Figure 1, 3) to update a virtual storage as storage unit 21 (Itatsu, ¶51; Figure 2, 21) based on configuration data as updated control program (Itatsu, ¶51 “Also, the control program may be a control program downloaded from an external computer (not shown) connected to a communication network (not shown), and stored in the storage unit 21. Furthermore, configuration information regarding all the on-board ECUs 3 provided in the vehicle C is stored in the storage unit 21 (the predetermined storage area). The storage unit 21 stores the update program acquired from the program providing device S1”) from a data carrier device as downloaded from external computer (Id), the virtual data storage as storage unit 21 (Id) being locally accessible (Itatsu, ¶52) by one or more other ECUs from among the plurality of ECUs via the backbone network (Itatsu, ¶52 “The vehicle interior communication units 23 are input/output interfaces that employ a communication protocol such as a CAN (Control Area Network) or Ethernet (registered trademark), and the control unit 20 communicates with the on-board ECUs 3 that are connected to the vehicle interior LAN 4 or another on-board device such as a relay device with each other via the vehicle interior communication units 23.”); and
Controlling, by processing circuitry as control unit 20 (Figure 2, 20), the other ECUs as each ECU 3 performing the update (Itatsu, ¶59 “After the reception of the update program is completed normally, i.e. after the reception of all of the divided blocks is complete, upon a predetermined operation such as the IG switch of the vehicle C being switched ON and OFF, the control unit 30 of the on-board ECU 3 performs switching of the operating region, and adopts and executes the received update program as the current version of the program.”) to identify [data parts] as the divided block segments (Itatsu, ¶52 “In this way, the vehicle interior LAN 4 is divided into a plurality of segments by providing a plurality of vehicle interior communication units 23, and each on-board ECU is connected to any of the segments according to the function (the control system function, the safety system function, or the body system function) of the on-board ECU.”; ¶59) of the configuration data [that would cause one or more updates] to data stored by said other ECUs (Itatsu, ¶53 “Each on-board ECU 3 includes a control unit 30… a program or data for the on-board ECU 3 is stored therein. This program or data is the update target that is to be updated with the update program transmitted from the on-board update device 2.”), and
obtain said one or more data part of the configuration data [responsive to a successful access request] between said other ECUs as the control unit 30 of each ECU receives the update program (Itatsu, ¶57 “The control unit 30 of the on-board ECU 3 receives an update program transmitted from the on-board update device 2, via the vehicle interior communication unit 32, and acquires the update program.”) and the virtual data storage as the update is received from the on-board update device 2 (Id).
It would have been obvious to one of ordinary skill to which said subject matter pertains at the time the invention was filed to have implemented the vehicle on-board update device taught by Itatsu to acquire the update data (Itatsu, ¶44) using the portable memory device taught by Zellen (¶8, 22, ¶25) and the file-by-file granularity software update (Zellen, ¶19). The proposed combination simply substitutes the wireless communication taught by Itatsu (¶44 “An on-board ECU 3 provided in the vehicle acquires an update program transmitted from the program providing device S1 via wireless communication, adopts the update program as a program to be executed, and is thus able to update the program to be executed by the ECU (reprogram).”) with the portable memory device taught by Zellen (Zellen, ¶22, ¶25). This combination would yield the predictable results of providing flexible source of software (Zellen, ¶12).
One of ordinary skill in the art would recognize the file-by-file granularity software update taught by Zellen (¶19) using the version numbers (¶25; ¶29) may be used as the means of performing the block division (Itatsu, ¶58). Within the proposed combination this would improve the device taught by Itatsu to enable the version numbers (Itatsu, Fig 10, see Version numbers in Vehicle configuration information table) to be used to enable the file-by-file granularity yielding the predictable results of minimizing the number of transactions and necessary size of target memory (Zellen, ¶9, ¶10), improving traceability (Zellen, ¶11),
It should be noted that Zellen is silent regarding the internal structure of the motor vehicle. One of ordinary skill in the art would recognize that within the proposed combination, the internal structure of the device may be implemented as taught by Itatsu while using the updating method taught by Zellen as detailed above for the above recited reasoning.
With regard to claim 19 the proposed combination further teaches A computer program product comprising program code as the code implemented to perform the disclosed method (Zellen, ¶33 “One embodiment of a method 200 of updating software files in a motor vehicle is illustrated in FIG. 2.”), for performing, when executed by the processing circuitry as the processor (Zellen, ¶20), the method of claim 18 (See above mapping for claim 18).
With regard to claim 20 the proposed combination further teaches A non-transitory computer-readable storage medium comprising instructions as the method (Zellen, ¶33 “One embodiment of a method 200 of updating software files in a motor vehicle is illustrated in FIG. 2.”), which when executed by the processing circuitry, cause the processing circuitry as the processor (Zellen, ¶20) to perform the method of claim 18 (See above mapping for claim 18).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Schweikert [2017/0292467] teaches master/slave ECU communicating via one bi-directional high-speed network (Zellen, ¶24).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMANDA WILLIS whose telephone number is (571)270-7691. The examiner can normally be reached Monday-Friday 8am-2pm.
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, Ajay Bhatia can be reached at 571-272-3906. 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.
/AMANDA L WILLIS/Primary Examiner, Art Unit 2156
Prosecution Insights