DETAILED ACTION
This action is in response to the claims filed March 11, 2026. Claims 12, 17-20, 24, and 26-29 are pending. Claims 12, 19, 24, and 28 are independent claims. Claims 12, 18, 19, 24, and 27 have been amended. Claims 1-11, 13-16, 21-23, 25, and 30 have been cancelled.
The objections to the claims are withdrawn in view of Applicant’s amendments to the claims.
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 Rejections - 35 USC § 112(b)
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 19 and 20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 19 recites the limitation “receiving, by the node ECU, a download address of a target software package from the master ECU, wherein the download address of the target software package in response to the master ECU determining that the size of the remaining storage space if not less than the size of the target software package”. In particular, it is unclear what “the download address of the target software package” should do “in response to the master ECU”. It is unclear what should be done with the download address when the specified condition is reached. For the purposes of examination, the claim is interpreted to mean that the download address of the target software package is received by the node ECU, as is consistent with the wording of the first portion of the limitation. Claim 20 is rejected in view of its dependency on claim 19.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 19, 20, 28, and 29 are rejected under 35 U.S.C. 103 as being unpatentable over JP 2018205896 A (hereinafter “Makita”), in view of US 20040215755 A1 (hereinafter “O’Neill”), and further in view of US 20170102934 A1 (hereinafter “Xu”).
Regarding claim 19, Makita discloses:
A data transmission method, comprising:
- transmitting, by a node electronic control unit (ECU), a [version of software] of the node ECU to a master ECU, wherein the node ECU and the master ECU are different devices (Paragraph [0017], Further, each slave ECU3 is provided with an update determination information transmission part 31 for transmitting the version information of the present software after starting communication with the master ECU2. The communication between the master ECU2 and the slave ECU3 is started, for example, when the ignition is turned on. When communication is started, the update determination information transmission unit 31 of the present embodiment transmits version information of its own software to the master ECU2 [transmitting, by a node electronic control unit (ECU), a [version] of the node ECU to a master ECU, wherein the node ECU and the master ECU are different devices”) [Examiner’s remarks: Makita discloses a node ECU (slave ECU) and master ECU (master ECU) which are different devices. The node ECU sends a version number of the software of the node ECU to the master ECU.];
- receiving, by the node ECU, a [download] of a target software package from the master ECU, wherein the [download] of the target software package in response to the master ECU determining that the [version of software] is [older] than the [version] of the target software package (Paragraph [0012], “The update determination information management unit 24 receives the version information transmitted from the slave ECU3 and writes the version information in the volatile memory 22”; Paragraph [0013], “To be specific, the software update determination unit 25 compares the version information of the slave ECU3 to be updated stored in the volatile memory 22 with the version information of the update software, and determines whether or not the update is necessary…when it is determined that the update is to be performed, the software update determination unit 25 transmits the update software to the target slave ECU3 [receiving, by the node ECU, a [download] of a target software package from the master ECU, wherein the [download] of the target software package in response to the master ECU determining that the [version] is not less than the [version] of the target software package]”) [Examiner’s remarks: The master ECU (the software update determination unit is part of the master ECU) determines that the target software package is of newer version than the current node ECU (slave ECU) version. In response, the master ECU transmits the updated software (download) to the node ECU.); and
Makita discloses “a [version] of a target software package” and “a [version of software] of the node ECU”. Makita does not explicitly disclose:
- the size of the remaining storage space of the node ECU, the size of the target software package, and when the remaining storage space is not less than the size of a target software package.
However, O’Neill discloses:
- the size of the remaining storage space of the node ECU, the size of the target software package, and when the remaining storage space is not less than the size of a target software package (Figure 2B; Paragraph [0072], “Alternatively, in the state 260, if the client device 104 determines from the update information response that the updated code version is available in the update store 133, then the client device 104 may further determine, in a state 262, from the update information query whether or not the client device 104 has enough memory available to store the update package 110. If the client device 104 determines that enough memory or storage space is available in the client device 104 for the update package 110, then the update device server 136 processes the client update request in a state 264”) [Examiner’s remarks: Makita discloses the general framework of node ECU, master ECU, and OTA server interactions, with a version comparison to determine updates. O’Neill discloses a storage size comparison to determine updates. One of ordinary skill in the art understands that a comparison of version may be replaced with a comparison of size within the same general framework.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of O’Neill into the teachings of Makita to include “the size of the remaining storage space of the node ECU”, “the size of the target software package”, and “when the remaining storage space is not less than the size of a target software package”. As stated in O’Neill, “The system and methods described herein provide a developer with an improved ability to create update information as needed and additionally allow users to proceed through a simplified update path which is not error-prone and can be performed more quickly than through the use of existing technologies” (O’Neill, paragraph [0012]). Requesting updates only when sufficient memory is available saves resources, time, and reduces download error rates. One of ordinary skill in the art may replace the comparison of one value for the comparison of another value for the purposes of determining whether an update should be performed. Thus, it would be obvious to one of ordinary skill in the art of software downloading to combine the capability of collecting data from server and ECUs, with the ability to trigger download based on the result of resource comparisons.
Makita discloses “receiving … a download of a target software package”. The combination of Makita and O’Neill does not explicitly disclose the following But Xu discloses:
Receiving…a download address (Paragraph [0035], “the determining module is arranged to determine whether to send a device management, DM, session request to a server and whether to initiate a Firmware Over The Air, FOTA, operation according to the firmware version information and its own current firmware version information”; Paragraph [0087], “According to another embodiment of the present invention, after sending a DM session request to the server and initiating a FOTA operation, when has received a DM session response message returned from the server, the DM session response message carries a downloading address of the latest software upgrade packet… [receiving… a download address]”) [Examiner’s remarks: The combination of Makita and O’Neill discloses sending a target software package to the node ECU from a master ECU in response to determining that there is sufficient space for the download. Xu discloses sending a software package using a download address. One of ordinary skill in the art may send a download address in lieu of a target software package to achieve the same result of downloading an update.]…
- receiving, based on the download address of the target software package, the target software package from an over the air (OTA) server (Paragraph [0035], “the determining module is arranged to determine whether to send a device management, DM, session request to a server and whether to initiate a Firmware Over The Air, FOTA, operation according to the firmware version information and its own current firmware version information”; Paragraph [0087], “According to another embodiment of the present invention, after sending a DM session request to the server and initiating a FOTA operation, when has received a DM session response message returned from the server, the DM session response message carries a downloading address of the latest software upgrade packet, and downloads the latest software upgrade package through the download address and install it [receiving a download address]”) [Examiner’s remarks: Xu discloses receiving a download address for an update and using the address to access an OTA server (FOTA session over a server) to download the software. One of ordinary skill in the art understands that an address may be sent in lieu of a full package and the address may be further access to complete the download.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings Xu into the combined teachings of Makita and O’Neill to include “receiving… a download address” and “receiving, based on the download address of the target software package, the target software package from an over the air (OTA) server”. As stated in Xu, current methods without use of parameter collection leads to “no latest available software upgrade package which is efficient and suitable for the terminal device, thus wasting the user traffic and increasing the load of the server” (Xu, paragraph [0008]). Checking parameters and available resources prior to providing a download link allows for better use of server and communication resources. Thus, it would be obvious to one of ordinary skill in the art of software downloading to combine the capability of collecting data from server and ECUs, with the ability to check resources to provide a download link to a software update.
Regarding claim 20, the rejection of claim 19 is incorporated; and Makita discloses:
- … based on a determination by the master ECU on whether the received [version] of the node ECU is [newer] than the [version] of the target software package (Paragraph [0009], “the master ECU2 is, for example, an Over The Air (OTA) ECU, and is an ECU that receives update software wirelessly transmitted from outside the car. An antenna (for example, a film antenna) B for receiving update software transmitted from an external device A such as a server is installed in the vehicle, and the master ECU2 receives information from the antenna B. It can be said that master ECU2 has a receive section. The external device A such as a server is installed in, for example, an OTA center”; Paragraph [0013], “The software update determination unit 25 determines, the software update determination unit 25 determines that update is not to be performed. On the other hand, when the version information of the update software is newer than the version information of the target slave ECU3 stored in the volatile memory, the software update determination unit 25 determines that the update is to be performed in principle [based on a determination by the master ECU on whether the received [version] of the node ECU is [newer] than the [version] of the target software package”).
Makita discloses master ECU and node ECU as part of a client device. Makita also discloses whether the received [version] of the node ECU is [newer] than the [version] of the target software package. Makita does not explicitly disclose:
- wherein the target software package is requested by the node ECU from the OTA server, the target software package is transmitted by the OTA server instructed by the master ECU based on a determination by the master ECU on whether the received size of the remaining storage space of the node ECU is less than the size of the target software package.
However, O’Neill discloses:
- wherein the target software package is requested by the [client] from the OTA server, the target software package is transmitted by the OTA server instructed by the [client] based on a determination by the [client] on whether the received size of the remaining storage space of the [client] is less than the size of the target software package (Figure 2B; Paragraph [0072], “Alternatively, in the state 260, if the client device 104 determines from the update information response that the updated code version is available in the update store 133, then the client device 104 may further determine, in a state 262, from the update information query whether or not the client device 104 has enough memory available to store the update package 110. If the client device 104 determines that enough memory or storage space is available in the client device 104 for the update package 110, then the update device server 136 processes the client update request in a state 264 [wherein the target software package is requested by the [client] from the OTA server, the target software package is transmitted by the OTA server instructed by the [client] based on a determination by the [client] on whether the received size of the remaining storage space of the [client] is less than the size of the target software package]”) [Examiner’s Remarks: Makita discloses the master ECU making a determination about whether a node ECU should be updated based on version. O’Neill discloses making the determination based on remaining storage, and transmitting a request from the client to the server to download an update. Combining the structure of Makita with the download request of O’Neill results in the stated limitation.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of O’Neill into the teachings of Makita to include “wherein the target software package is requested by the [client] from the OTA server, the target software package is transmitted by the OTA server instructed by the [client] based on a determination by the [client] on whether the received size of the remaining storage space of the [client] is less than the size of the target software package”. As stated in O’Neill, “The system and methods described herein provide a developer with an improved ability to create update information as needed and additionally allow users to proceed through a simplified update path which is not error-prone and can be performed more quickly than through the use of existing technologies” (O’Neill, paragraph [0012]). Requesting updates only when sufficient memory is available saves resources, time, and reduces download error rates. Thus, it would be obvious to one of ordinary skill in the art of software downloading to combine the capability of collecting data from server and ECUs, with the ability to trigger download based on the result of resource comparisons.
Regarding claim 28, Makita discloses:
A node electronic control unit (ECU), comprising (Paragraph [0016], “Similarly to a general ECU, each slave ECU3 includes a non-volatile memory that stores software and the like, and a central processing unit that executes control, which are not illustrated”):
at least one processor (Paragraph [0016], “Similarly to a general ECU, each slave ECU3 includes a non-volatile memory that stores software and the like, and a central processing unit that executes control, which are not illustrated”); and
one or more non-transitory computer-readable storage media coupled to the at least one processor and storing programming instructions for execution by the at least one processor, wherein the programming instructions, when executed, cause the node ECU to perform operations comprising (Paragraph [0016], “Similarly to a general ECU, each slave ECU3 includes a non-volatile memory that stores software and the like, and a central processing unit that executes control, which are not illustrated”):
- transmitting a [version of software] of the node ECU to a master ECU (Paragraph [0017], Further, each slave ECU3 is provided with an update determination information transmission part 31 for transmitting the version information of the present software after starting communication with the master ECU2. The communication between the master ECU2 and the slave ECU3 is started, for example, when the ignition is turned on. When communication is started, the update determination information transmission unit 31 of the present embodiment transmits version information of its own software to the master ECU2 [transmitting a [version of software] of the node ECU to a master ECU”);
- when the [version] is [newer] than the [version] of a target software package, receiving the target software package from an over the air (OTA) server (Paragraph [0009], “the master ECU2 is, for example, an Over The Air (OTA) ECU, and is an ECU that receives update software wirelessly transmitted from outside the car. An antenna (for example, a film antenna) B for receiving update software transmitted from an external device A such as a server is installed in the vehicle, and the master ECU2 receives information from the antenna B. It can be said that master ECU2 has a receive section. The external device A such as a server is installed in, for example, an OTA center”; Paragraph [0013], “The software update determination unit 25 determines, the software update determination unit 25 determines that update is not to be performed. On the other hand, when the version information of the update software is newer than the version information of the target slave ECU3 stored in the volatile memory, the software update determination unit 25 determines that the update is to be performed in principle [when the [version] is [newer] than the [version] of a target software package, receiving the target software package from an over the air (OTA) server); and
when the [version] is not less than the [version number] of a target software package, receiving a [target software package] from the master ECU (Paragraph [0012], “The update determination information management unit 24 receives the version information transmitted from the slave ECU3 and writes the version information in the volatile memory 22”; Paragraph [0013], “To be specific, the software update determination unit 25 compares the version information of the slave ECU3 to be updated stored in the volatile memory 22 with the version information of the update software, and determines whether or not the update is necessary…when it is determined that the update is to be performed, the software update determination unit 25 transmits the update software to the target slave ECU3 [when the [version] is not less than the [version number] of a target software package, receiving a [target software package] from the master ECU]”) [Examiner’s remarks: The parameter regarding ECU version number is used to indicate that the ECU version is older in comparison to the version of the target software package. A determination that the ECU version is older based on the parameter is used to indicate that a file should be sent to the node ECU.]).
Makita discloses “a [version] of a target software package” and “a [version of software] of the node ECU”, but Makita does not explicitly disclose:
- the size of the remaining storage space of the node ECU, the size of the target software package, and when the remaining storage space is not less than the size of a target software package.
However, O’Neill discloses:
- the size of the remaining storage space of the node ECU, the size of the target software package, and when the remaining storage space is not less than the size of a target software package (Figure 2B; Paragraph [0072], “Alternatively, in the state 260, if the client device 104 determines from the update information response that the updated code version is available in the update store 133, then the client device 104 may further determine, in a state 262, from the update information query whether or not the client device 104 has enough memory available to store the update package 110. If the client device 104 determines that enough memory or storage space is available in the client device 104 for the update package 110, then the update device server 136 processes the client update request in a state 264”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of O’Neill into the teachings of Makita to include “the size of the remaining storage space of the node ECU”, “the size of the target software package”, and “when the remaining storage space is not less than the size of a target software package”. As stated in O’Neill, “The system and methods described herein provide a developer with an improved ability to create update information as needed and additionally allow users to proceed through a simplified update path which is not error-prone and can be performed more quickly than through the use of existing technologies” (O’Neill, paragraph [0012]). Requesting updates only when sufficient memory is available saves resources, time, and reduces download error rates. One of ordinary skill in the art may replace the comparison of one value for the comparison of another value for the purposes of determining whether an update should be performed. Thus, it would be obvious to one of ordinary skill in the art of software downloading to combine the capability of collecting data from server and ECUs, with the ability to trigger download based on the result of resource comparisons.
Makita discloses “receiving a target software package”. The combination of Makita and O’Neill does not explicitly disclose receiving a download address.
However, Xu discloses:
receiving a download address (Paragraph [0035], “the determining module is arranged to determine whether to send a device management, DM, session request to a server and whether to initiate a Firmware Over The Air, FOTA, operation according to the firmware version information and its own current firmware version information”; Paragraph [0087], “According to another embodiment of the present invention, after sending a DM session request to the server and initiating a FOTA operation, when has received a DM session response message returned from the server, the DM session response message carries a downloading address of the latest software upgrade packet… [receiving a download address]”) [Examiner’s remarks: The combination of Makita and O’Neill discloses sending a target software package to the node ECU from a master ECU in response to determining that there is sufficient space for the download. Xu discloses sending a software package using a download address. One of ordinary skill in the art may send a download address in lieu of a target software package to achieve the same result of downloading an update.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings Xu into the combined teachings of Makita and O’Neill to include “receiving a download address”. As stated in Xu, current methods without use of parameter collection leads to “no latest available software upgrade package which is efficient and suitable for the terminal device, thus wasting the user traffic and increasing the load of the server” (Xu, paragraph [0008]). Checking parameters and available resources prior to providing a download link allows for better use of server and communication resources. Thus, it would be obvious to one of ordinary skill in the art of software downloading to combine the capability of collecting data from server and ECUs, with the ability to check resources to provide a download link to a software update.
Regarding claim 29, the rejection of claim 28 is incorporated; and Makita discloses:
- … based on a determination by the master ECU on whether the received [version] of the node ECU is [newer] than the [version] of the target software package (Paragraph [0009], “the master ECU2 is, for example, an Over The Air (OTA) ECU, and is an ECU that receives update software wirelessly transmitted from outside the car. An antenna (for example, a film antenna) B for receiving update software transmitted from an external device A such as a server is installed in the vehicle, and the master ECU2 receives information from the antenna B. It can be said that master ECU2 has a receive section. The external device A such as a server is installed in, for example, an OTA center”; Paragraph [0013], “The software update determination unit 25 determines, the software update determination unit 25 determines that update is not to be performed. On the other hand, when the version information of the update software is newer than the version information of the target slave ECU3 stored in the volatile memory, the software update determination unit 25 determines that the update is to be performed in principle [based on a determination by the master ECU on whether the received [version] of the node ECU is [newer] than the [version] of the target software package”).
Makita discloses master ECU and node ECU as part of a client device. Makita also discloses whether the received [version] of the node ECU is [newer] than the [version] of the target software package. Makita does not explicitly disclose:
- wherein the target software package is requested by the node ECU from the OTA server, the target software package is transmitted by the OTA server instructed by the master ECU based on a determination by the master ECU on whether the received size of the remaining storage space of the node ECU is less than the size of the target software package.
However, O’Neill discloses:
- wherein the target software package is requested by the [client] from the OTA server, the target software package is transmitted by the OTA server instructed by the [client] based on a determination by the [client] on whether the received size of the remaining storage space of the [client] is less than the size of the target software package (Figure 2B; Paragraph [0072], “Alternatively, in the state 260, if the client device 104 determines from the update information response that the updated code version is available in the update store 133, then the client device 104 may further determine, in a state 262, from the update information query whether or not the client device 104 has enough memory available to store the update package 110. If the client device 104 determines that enough memory or storage space is available in the client device 104 for the update package 110, then the update device server 136 processes the client update request in a state 264 [wherein the target software package is requested by the [client] from the OTA server, the target software package is transmitted by the OTA server instructed by the [client] based on a determination by the [client] on whether the received size of the remaining storage space of the [client] is less than the size of the target software package]”) [Examiner’s Remarks: Makita discloses the master ECU making a determination about whether a node ECU should be updated based on version. O’Neill discloses making the determination based on remaining storage, and transmitting a request from the client to the server to download an update. Combining the structure of Makita with the download request of O’Neill results in the stated limitation.].
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of O’Neill into the teachings of Makita to include “wherein the target software package is requested by the [client] from the OTA server, the target software package is transmitted by the OTA server instructed by the [client] based on a determination by the [client] on whether the received size of the remaining storage space of the [client] is less than the size of the target software package”. As stated in O’Neill, “The system and methods described herein provide a developer with an improved ability to create update information as needed and additionally allow users to proceed through a simplified update path which is not error-prone and can be performed more quickly than through the use of existing technologies” (O’Neill, paragraph [0012]). Requesting updates only when sufficient memory is available saves resources, time, and reduces download error rates. Thus, it would be obvious to one of ordinary skill in the art of software downloading to combine the capability of collecting data from server and ECUs, with the ability to trigger download based on the result of resource comparisons.
Allowable Subject Matter
Claims 12, 17, 18, 24, 26, and 27 are allowed.
Response to Arguments
Applicant's arguments filed March 11, 2026 have been fully considered but they are not persuasive.
In the remarks, Applicant argues:
In particular, the node ECU sends the size of the remaining storage space of the node ECU to the master ECU, and the download address of the target software package is received in response to the master ECU determining that the size of the remaining storage space is not less than the size of the target software package. The node ECU uses the download address to receive the target software package from the OTA server. The Office Action fails to cite any passages in the references to teach or suggest the above-identified limitations.
For example, the Office Action asserts that Makita states the following:
The software update determination unit 25 determines, the software update determination unit 25 determines that update is not to be performed. On the other hand, when the version information of the update software is newer than the version information of the target slave ECU3 stored in the volatile memory, the software update determination unit 25 determines that the update is to be performed in principle.
In summary, the above-cited passage of Makita merely discusses that the software update determination unit 25 (which is part of master ECU2) determines whether to perform upgrade based on the version information of the target slave ECU3. As such, Makita has not been shown to teach or suggest that the node ECU sends the parameter that has a value indicating that the remaining storage space of the node ECU is not less than a size of a target software package, and receives the download address of the target software package in response to such a parameter.
Examiner’s Response:
Examiner respectfully disagrees. First, in regards to the argument that “As such, Makita has not been shown to teach or suggest that the node ECU sends the parameter that has a value indicating that the remaining storage space of the node ECU is not less than a size of a target software package”, there is no requirement by the current claims that require that the node ECU send a parameter that has a value indicating that the remaining storage space of the node ECU is not less than a size of a target software package. In contrast, claim 19 specifies “in response to the master ECU determining that the size of the remaining storage space is not less than the size of the target software package”, which indicates that the determination should be done in the master ECU and not the node ECU as would be required by the parameter claimed in the argument. Second, Makita is not relied upon by the examiner to disclose download address of the target software package. Third, in regards to Makita disclosing a determination based on version number and not storage space, Examiner agrees. However, Examiner relies upon Makita to disclose the general three part framework of interactions between the node ECUs, master ECU, and an over the air server and where each specified task is completed within this framework. It is not used to disclose the specific comparison of values. One of ordinary skill in the art understands that a comparison of remaining storage space and version number and general comparisons of numerical values, and are interchangeable within the general framework of Makita. Therefore, the argument is not persuasive and the rejection under 35 U.S.C. 103 is maintained.
In the remarks, Applicant argues:
Furthermore, the Office Action fails to cite other references to remedy the above- identified deficiency. Furthermore, O'Neill states the following:
[0072] Alternatively, in the state 260, if the client device 104 determines from the update information response that the updated code version is available in the update store 133, then the client device 104 may further determine, in a state 262, from the update information query whether or not the client device 104 has enough memory available to store the update package 110. If the client device 104 determines that enough memory or storage space is available in the client device 104 for the update package 110, then the update device server 136 processes the client update request in a state 264. The update device server 136 then transfers the update package 110 to the client device 104 in a state 266. After receipt of the update package 110, the update installation process advances to a state 268
where the client device 104 installs the update package 110. The update installation process 250 is then terminated in an end state 280 until another update request is made. Additionally, details of the update package installation procedure will [be] discussed in connection with FIG. 10 herein below.
In summary, the above-cited portions of O'Neill describe the following operation: a client device 104 determines whether it has enough memory available to store the update package 110. If there is memory, the client device 104 sends a request for update and receives the update. As an initial matter, the O'Neill's system involves only two devices, the client device and the update device server. However, in the recited claims, three devices are involved, the node ECU sends the size of the remaining storage space to the master ECU, and receives the download address in response to the master ECU determines that the size of the remaining storage space is not less than size of target software package. Furthermore, in the recited claim, the device that performs the size comparison, i.e., the master ECU, is different from the device that receives the software package, i.e., the node ECU, and is also different from the device that provides the software package, i.e., the OTA server. In contrast, O'Neill explicitly states, "the client device 104 may further determine, in a state 262, from the update information query whether or not the client device 104 has enough memory available to store the update package 110." In other words, O'Neill teaches that the client device that receives the software package is the same device that performs the size comparison.
Moreover, the Office Action proposes to modify the version comparison operation performed by master ECU in Makita to size comparison discussed in O'Neill. Applicant respectfully disagrees. The Office Action fails to cite any passages in Makita or O'Neill to provide any teaching, suggestion, or motivation for the alleged combination. More specifically, neither Makita nor O'Neill discusses any motivations for the master ECU to perform the size comparison. In contrast, O'Neill explicitly discusses a solution for the client device that receives the software update to make the comparison. Moreover, neither Makita nor O'Neill discusses any motivations for the node ECU to send the size of the remaining storage space of the node ECU to the master ECU.
As such, there is no prima facie obviousness because a person of ordinary skill would not have been motivated or otherwise led to combine the teaching of these references in the way of the claimed invention, as discussed previously. The combination would not have been obvious to try or obvious to a person of ordinary skill in the art because it would not lead to a reasonable expectation of success.
For at least these reasons, Applicant respectfully requests allowance of independent claim 19 and its dependents.
Examiner’s response:
Examiner respectfully disagrees. Applicant argues that 1) the structure of O’Neill is not equivalent to that of the current claims and that 2) there is no motivation to combine O’Neill into Makita. In regards to the first argument, O’Neill is not used to disclose the specific three part structure between node ECU, master ECU, and OTA server as disclosed by the claims. Rather, it is used specifically to disclose that one may compare remaining storage spaces before updating software. The basic comparison of numerical values for remaining storage space may be substituted into the larger structure as taught by Makita, and merely replaces one numerical comparison with the other. In regards to the second argument, since O’Neill is not used to disclose the structure of the vehicle, but only a specific comparison, the motivation only applies to combining the specific memory comparison with the structure of Makita. As cited, “The system and methods described herein provide a developer with an improved ability to create update information as needed and additionally allow users to proceed through a simplified update path which is not error-prone and can be performed more quickly than through the use of existing technologies” (O’Neill, paragraph [0012]). One of ordinary skill in the art understands that ensuring that sufficient space is present in an ECU before downloading saves time and prevents errors, and thus, a memory capacity comparison is important. Therefore, Applicant’s arguments are not persuasive, and the rejection of claim 19 is maintained.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VIVIAN WEIJIA DUAN whose telephone number is (703)756-5442. The examiner can normally be reached Monday-Friday 8:30AM-5PM.
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, Wei Y Mui can be reached at (571) 272-3708. 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.
/V.W.D./Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191
Prosecution Insights