DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Application
This action is in reply to the correspondence received through October 8, 2024.
Claims 1-19 are pending.
Claim Rejections - 35 U.S.C. § 112
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 7 and 16 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 pre-AIA the applicant regards as the invention.
Claims 7 and 16 recite “A2L”, “ASAM”, “MCD-2”, and “MC.” However, these abbreviations are not defined or specified in the claims. Accordingly, the one of ordinary skill in the art would not be reasonably apprised of the scope of the invention.
Claim Rejections - 35 U.S.C. § 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 1-10 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to non-statutory subject matter.
Claim 1 recites a software build tool system comprising several subsystems. Under the broadest reasonable interpretation consistent with the specification, these subsystems can be software per se, which is not a statutory class of invention. Accordingly, claim 1 is rejected because it is not directed to statutory subject matter.
Claims 2-10 fail to introduce sufficient limitations to remedy the deficiencies of claim 1 and are similarly rejected for being directed to non-statutory subject matter.
Claim Rejections - 35 U.S.C. § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. § 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-6, 8, 11-15, and 17 are rejected under 35 U.S.C. § 102(a)(1)-(2) as being anticipated by Moeller et al. (U.S. Pub. No. 2016/0371075 A1) (hereinafter “Moeller”).
Claims 1 and 11: Moeller, as shown, discloses the following limitations:
A software build tool system for generating and validating a software build for execution on a target hardware device of an embedded system (see at least ¶ [0091]: FIG. 1 illustrates, in simplified form, the functionality of an embodiment of a system 100 for providing software updates to vehicles. System 100 provides for wireless distribution of vehicle software updates originating at the vehicle manufacturer including, but not limited to, enhancements or corrections or other changes to vehicular software and data. Advantageously, system 100 is operable to automatically provide such updates to individual selected vehicles or to large groups of predetermined vehicles. System 100 may be utilized to automatically provide notifications of update availability to vehicle owners, automatically download vehicle updates and to generate reports on update status; see also at least ¶ [0110]: Policy Manager 103 is utilized to generate control information for the updates including a vehicle, vehicle models, and or groups of vehicles that is to be updated. In addition Policy Manger 103 identifies the corresponding ECUs and ECU flash memory data images to be updated. Policy Manager 103 is also used to determine prerequisites to each update, update scheduling and notifications to be provided. Policy Manager 103 is additionally utilized to select update status reports to be provided back to the vehicle manufacturer.; see also at least ¶¶ [0111]-[0114] and [0132]), comprising:
a user interface subsystem configured for receiving build parameter data pertaining to software from a user (see at least ¶ [0119]: Vehicle Manager 105 includes the ability for a vehicle manufacturer to perform a vehicle search based on the vehicle identification number (VIN) for a particular vehicle, to perform a search for a particular ECU in a vehicle, and to perform a search for vehicle by make, model and year; see also at least ¶ [0124]: upon logging into Policy Manager 103, a user at terminal 101 is presented with a screen 200 shown in FIG. 2. Each screen 200 for Policy Manager 103 comprises toolbars 201, 203; see also at least ¶ [0134]: clicking on ECU Types button 203 c will open an ECU Type Manager with a screen similar to FIG. 5. A series of fields 709 similar to those shown in FIG. 5 including a Name field, a Manufacturer field and a Part Number field. A +button 705, a Filter button 707, and a Create button 719 are provided as shown on screen display 700. A search for ECUs is initiated by filing in the desired search fields 709 and clicking Create button 719. The search results are displayed in window 711; see also at least ¶ [0140]: window 1031 comprises fields to name the update package (Name), to assign a recall number to the update package (Recall Number), to assign a technical bulletin number or numbers to the update package (Technical Bulletin), select a Vehicle Group, select a Download Schedule for downloading the update package, select an Install Schedule for installing the update package, determining whether the update release should be deployed in smaller sections and selecting the number of smaller sections (Stagger Release), selecting the percentage of completion that each stage must reach before the next stage begins (Completion Threshold), and set the maximum amount of time each stage should require to reach its threshold; see also at least ¶ [0145]: the ECU update image to be included in the update package is entered in window 1041; see also at least ¶ [0146]: Window 1043 is utilized to add rules that apply to update installation. Clicking on button 1043 a will open up various rule selection options; see also at least ¶¶ [0125]-[0129] and [0141]-[0144]);
a build tool subsystem configured for receiving the build parameter data from the user interface subsystem and building the software to generate a software build for execution on a target hardware device of an embedded system (see at least ¶ [0147]: after completion of all the create package fields, clicking on button 1047 will create the package; see also at least ¶ [0094]: to reduce image download time and cost of OTA flashing of ECU images, only changes to the original image are sent instead of an entire new image. These changes are referred to herein as a Differential Upgrade Package (DUP). A DUP is created by comparing the new image to the original image and producing a set of changes required to modify the original image to the new image. The set of changes comprise instructions to copy bytes from the original image and apply a set of modifications to those bytes and/or add additional bytes to the new image; see also at least ¶ [0205]: selecting the target vehicle group; generating a differential update package (DUP) for the target vehicle group, the DUP comprising update manager software 121; selecting update prerequisites for executing the DUP; and selecting update scheduling for downloading the DUP; see also at least ¶ [0217]: providing package manager software 109, utilizing package manager 109 to select update prerequisites; utilizing package manager 109 to select update scheduling; and utilizing package manager 109 to select notifications to be generated; see also at least ¶¶ [0119], [0124], [0134], [0140]-[0146], [0220], and [0222]); and
a memory reporter subsystem configured for receiving the software build generated by the build tool subsystem and providing access to target hardware build validation data resulting from and/or used as a part of the software build during execution (see at least ¶ [0133]: Download Manager 113 downloads and authenticates software package updates to each designated vehicle 115. Download manager 113 is provided on one or more servers as described herein below and provides the update packages to client or target TCUs 119 in each target vehicle 115 being updated. [0106] The update downloads are provided via a network 117 using a wireless link, i.e., over the air (OTA). A portion of the update package comprises an Update Manager 121 that TCU 119 utilizes to update one or more ECUs 123 via CAN bus 211 of vehicle 115; see also at least ¶ [0117]: Download Manager 105 downloads each update package to a selected target vehicle TCU. The TCU, in effect, is operated as the client of the Download Manager 105 server. In this embodiment, the OMA DM download for each DUP is defined by an OMA specification for Software Component Management Object (SCOMO) that allows a management authority to perform software management on a remote device, including installation, uninstallation, activation and deactivation of software components OTA; see also at least ¶ [0118]: the update package downloaded to each vehicle 115 TCU 119 includes an Update Manager 121 that TCU 119 executes to validate an update flash memory image, validate an update rule set, monitor each ECU 123 being updated, initiate each update, and report update status to Download Manager 105; see also at least ¶ [0148]: the selected update package is shown in screen display 1100 shown in FIG. 11 Of particular interest is that the status of the pending update packages is shown. If the update package is still in the process of being built the status is indicated as “Build”. Once an update is built, it is submitted for approval, the status is indicated as “Review” and upon being approved the status is indicated as “Approved”. Clicking on the button Queue for Approval 1151 submits the update package as configured to the individuals designated for approval; see also at least ¶ [0164]: Each TCU 1430 sends ongoing progress information to a server; see also at least ¶¶ [0150], [0162], [0195], and [0212]).
Claims 2 and 12: Moeller discloses the limitations as shown in the rejections above. Further, Moeller, as shown, discloses the following limitations:
wherein the user interface subsystem, the build tool subsystem, and the memory reporter subsystem are each configured as a microservice configured and deployed as a separate module for module-specific execution (see at least ¶ [0108]: Policy Manager 103 comprises four distinct interlocking software components, i.e., a vehicle manager 105, ECU manager 107, package manager 109, and reports manager 111; see also at least ¶ [0113]: Download Manager 113 downloads and authenticates software package updates to each designated vehicle 115; see also at least ¶ [0106]).
Claims 3 and 13: Moeller discloses the limitations as shown in the rejections above. Further, Moeller, as shown, discloses the following limitations:
wherein the user interface subsystem is configured to receive the build parameter data from a user via a command line interface and/or a graphical user interface (GUI) (see at least ¶ [0119]: Vehicle Manager 105 includes the ability for a vehicle manufacturer to perform a vehicle search based on the vehicle identification number (VIN) for a particular vehicle, to perform a search for a particular ECU in a vehicle, and to perform a search for vehicle by make, model and year; see also at least ¶ [0124]: upon logging into Policy Manager 103, a user at terminal 101 is presented with a screen 200 shown in FIG. 2. Each screen 200 for Policy Manager 103 comprises toolbars 201, 203; see also at least ¶ [0134]: clicking on ECU Types button 203 c will open an ECU Type Manager with a screen similar to FIG. 5. A series of fields 709 similar to those shown in FIG. 5 including a Name field, a Manufacturer field and a Part Number field. A +button 705, a Filter button 707, and a Create button 719 are provided as shown on screen display 700. A search for ECUs is initiated by filing in the desired search fields 709 and clicking Create button 719. The search results are displayed in window 711; see also at least ¶ [0140]: window 1031 comprises fields to name the update package (Name), to assign a recall number to the update package (Recall Number), to assign a technical bulletin number or numbers to the update package (Technical Bulletin), select a Vehicle Group, select a Download Schedule for downloading the update package, select an Install Schedule for installing the update package, determining whether the update release should be deployed in smaller sections and selecting the number of smaller sections (Stagger Release), selecting the percentage of completion that each stage must reach before the next stage begins (Completion Threshold), and set the maximum amount of time each stage should require to reach its threshold; see also at least ¶ [0145]: the ECU update image to be included in the update package is entered in window 1041; see also at least ¶ [0146]: Window 1043 is utilized to add rules that apply to update installation. Clicking on button 1043 a will open up various rule selection options; see also at least ¶¶ [0125]-[0129] and [0141]-[0144]).
Claims 4 and 14: Moeller discloses the limitations as shown in the rejections above. Further, Moeller, as shown, discloses the following limitations:
wherein the software build tool system includes a platform-independent build tool configured for generate the software build for execution on the target hardware device (see at least ¶ [0147]: after completion of all the create package fields, clicking on button 1047 will create the package; see also at least ¶ [0094]: to reduce image download time and cost of OTA flashing of ECU images, only changes to the original image are sent instead of an entire new image. These changes are referred to herein as a Differential Upgrade Package (DUP). A DUP is created by comparing the new image to the original image and producing a set of changes required to modify the original image to the new image. The set of changes comprise instructions to copy bytes from the original image and apply a set of modifications to those bytes and/or add additional bytes to the new image; see also at least ¶ [0205]: selecting the target vehicle group; generating a differential update package (DUP) for the target vehicle group, the DUP comprising update manager software 121; selecting update prerequisites for executing the DUP; and selecting update scheduling for downloading the DUP; see also at least ¶ [0217]: providing package manager software 109, utilizing package manager 109 to select update prerequisites; utilizing package manager 109 to select update scheduling; and utilizing package manager 109 to select notifications to be generated; see also at least ¶¶ [0113], [0119], [0124], [0134], [0140]-[0146], [0220], and [0222]).
Claims 5 and 15: Moeller discloses the limitations as shown in the rejections above. Further, Moeller, as shown, discloses the following limitations:
wherein the build parameter data is specified via key-value pairs (see at least ¶ [0119]: Vehicle Manager 105 includes the ability for a vehicle manufacturer to perform a vehicle search based on the vehicle identification number (VIN) for a particular vehicle, to perform a search for a particular ECU in a vehicle, and to perform a search for vehicle by make, model and year; see also at least ¶ [0124]: upon logging into Policy Manager 103, a user at terminal 101 is presented with a screen 200 shown in FIG. 2. Each screen 200 for Policy Manager 103 comprises toolbars 201, 203; see also at least ¶ [0134]: clicking on ECU Types button 203 c will open an ECU Type Manager with a screen similar to FIG. 5. A series of fields 709 similar to those shown in FIG. 5 including a Name field, a Manufacturer field and a Part Number field. A +button 705, a Filter button 707, and a Create button 719 are provided as shown on screen display 700. A search for ECUs is initiated by filing in the desired search fields 709 and clicking Create button 719. The search results are displayed in window 711; see also at least ¶ [0140]: window 1031 comprises fields to name the update package (Name), to assign a recall number to the update package (Recall Number), to assign a technical bulletin number or numbers to the update package (Technical Bulletin), select a Vehicle Group, select a Download Schedule for downloading the update package, select an Install Schedule for installing the update package, determining whether the update release should be deployed in smaller sections and selecting the number of smaller sections (Stagger Release), selecting the percentage of completion that each stage must reach before the next stage begins (Completion Threshold), and set the maximum amount of time each stage should require to reach its threshold; see also at least ¶ [0145]: the ECU update image to be included in the update package is entered in window 1041; see also at least ¶ [0146]: Window 1043 is utilized to add rules that apply to update installation. Clicking on button 1043 a will open up various rule selection options; see also at least ¶¶ [0125]-[0129] and [0141]-[0144]).
Claim 6: Moeller discloses the limitations as shown in the rejections above. Further, Moeller, as shown, discloses the following limitations:
wherein the memory reporter subsystem is configured to generate the target hardware build validation data and to use the build validation data to determine whether the build was successful (see at least ¶ [0117]: Download Manager 105 downloads each update package to a selected target vehicle TCU. The TCU, in effect, is operated as the client of the Download Manager 105 server. In this embodiment, the OMA DM download for each DUP is defined by an OMA specification for Software Component Management Object (SCOMO) that allows a management authority to perform software management on a remote device, including installation, uninstallation, activation and deactivation of software components OTA; see also at least ¶ [0118]: the update package downloaded to each vehicle 115 TCU 119 includes an Update Manager 121 that TCU 119 executes to validate an update flash memory image, validate an update rule set, monitor each ECU 123 being updated, initiate each update, and report update status to Download Manager 105; see also at least ¶ [0148]: the selected update package is shown in screen display 1100 shown in FIG. 11 Of particular interest is that the status of the pending update packages is shown. If the update package is still in the process of being built the status is indicated as “Build”. Once an update is built, it is submitted for approval, the status is indicated as “Review” and upon being approved the status is indicated as “Approved”. Clicking on the button Queue for Approval 1151 submits the update package as configured to the individuals designated for approval; see also at least ¶ [0164]: Each TCU 1430 sends ongoing progress information to a server; see also at least ¶¶ [0150], [0162], [0195], and [0212]).
Claims 8 and 17: Moeller discloses the limitations as shown in the rejections above. Further, Moeller, as shown, discloses the following limitations:
wherein the target hardware device is an electronic control unit (ECU) of an embedded vehicle system (see at least ¶ [0147]: after completion of all the create package fields, clicking on button 1047 will create the package; see also at least ¶ [0094]: to reduce image download time and cost of OTA flashing of ECU images, only changes to the original image are sent instead of an entire new image. These changes are referred to herein as a Differential Upgrade Package (DUP). A DUP is created by comparing the new image to the original image and producing a set of changes required to modify the original image to the new image. The set of changes comprise instructions to copy bytes from the original image and apply a set of modifications to those bytes and/or add additional bytes to the new image; see also at least ¶ [0205]: selecting the target vehicle group; generating a differential update package (DUP) for the target vehicle group, the DUP comprising update manager software 121; selecting update prerequisites for executing the DUP; and selecting update scheduling for downloading the DUP; see also at least ¶¶ [0110]-[0113] and [0118]).
Claim Rejections - 35 U.S.C. § 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. § 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 7 and 16 are rejected under AIA 35 U.S.C. § 103 as being unpatentable over Moeller et al. (U.S. Pub. No. 2016/0371075 A1) (hereinafter “Moeller”) in view of Lim et al. (U.S. Pub. No. 2025/0187475 A1) (hereinafter “Lim”).
Claim 7: Moeller discloses the limitations as shown in the rejections above.
Moeller does not explicitly disclose, but Lim, as shown, teaches the following limitations:
wherein the target hardware build validation data includes A2L (ASAM MCD-2 MC) and/or PCAL (Parameter Calibration) data (see at least ¶ [0006]: based on the XCP (Universal Measurement and Calibration Protocol) standard and the transmission and reception of an A2L file (i.e., a file with the A2L extension that refers to the ASAP2 (ASAM MCD-2 MC) ECU description file, there is a need for technology that uses only standardized parameter symbols to translate into the addresses of the corresponding variables, thus enabling the control of the slave (e.g., the vehicle), without altering the Application Software (ASW) logic; see also at least ¶ [0062]: the process of reading (measuring) the parameter value (or variable value) at the corresponding symbol address and modifying and applying (calibrating) the parameter value (or variable value) at the corresponding symbol address may be performed at least once in order to apply an optimal parameter value (or variable value)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine the techniques for automatically tuning software parameters taught by Lim with the systems for developing and updating vehicle software disclosed by Moeller, because Lim teaches at ¶ [0006] that its techniques enable modification of values “without altering the Application Software (ASW) logic” and at ¶ [0062] that its techniques allow “modifying and applying (calibrating) the parameter value (or variable value) at the corresponding symbol address may be performed at least once in order to apply an optimal parameter value (or variable value).” See M.P.E.P. § 2143(I)(G).
Moreover, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine the techniques for automatically tuning software parameters taught by Lim with the systems for developing and updating vehicle software disclosed by Moeller, because the claimed invention is merely a combination of old elements (the techniques for automatically tuning software parameters taught by Lim and the systems for developing and updating vehicle software disclosed by Moeller), in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. See M.P.E.P. § 2143(I)(A).
Claim 16: Moeller discloses the limitations as shown in the rejections above.
Moeller does not explicitly disclose, but Lim, as shown, teaches the following limitations:
wherein the target hardware build validation data includes A2L (ASAM MCD-2 MC) and/or PCAL (Parameter Calibration) data (see at least ¶ [0006]: based on the XCP (Universal Measurement and Calibration Protocol) standard and the transmission and reception of an A2L file (i.e., a file with the A2L extension that refers to the ASAP2 (ASAM MCD-2 MC) ECU description file, there is a need for technology that uses only standardized parameter symbols to translate into the addresses of the corresponding variables, thus enabling the control of the slave (e.g., the vehicle), without altering the Application Software (ASW) logic; see also at least ¶ [0062]: the process of reading (measuring) the parameter value (or variable value) at the corresponding symbol address and modifying and applying (calibrating) the parameter value (or variable value) at the corresponding symbol address may be performed at least once in order to apply an optimal parameter value (or variable value)).
The rationales to modify/combine the teachings of Moeller to include the teachings of Lim are presented above regarding claim 7 and incorporated herein.
Claims 9, 10, 18, and 19 are rejected under AIA 35 U.S.C. § 103 as being unpatentable over Moeller et al. (U.S. Pub. No. 2016/0371075 A1) (hereinafter “Moeller”) in view of Lu (U.S. Pub. No. 2002/0147855 A1).
Claims 9 and 18: Moeller discloses the limitations as shown in the rejections above.
Moeller does not explicitly disclose, but Lu, as shown, teaches the following limitations:
wherein the build tool subsystem is configured to compile object files from source code of the software in a multi-threaded fashion whereby multiple object files of the same source code are generated (see at least ¶ [0063]: command server 306 is adapted to be multithreaded thus enabling command server 306 to launch multiple streams/threads of execution, each thread capable of processing (i.e., compiling, linking, etc.) a separate target. Additionally, in the exemplary embodiment, command server 306 pools threads. That is, command server 306 is adapted to launch several threads and then, when required, use one or more threads for the compiling of targets. The pooling of threads will improve CPU throughput utilization while minimizing the overhead of creating a new thread each time a target requires compiling. As a consequence, command server 306 reduces the wasting of CPU resources; see also at least ¶ [0173]: embodiments of the invention could designed to parallelize across multiple machines (i.e., multiple computer systems); see also at least ¶ [0002]: generally, many source code files will be created by application developers which will be compiled using a compiler and a “make” utility. As a result of compiling the source code files and linking the resulting object files, a usable and executable application can be created; see also at least ¶ [0059]: command server 306 receives processing commands (e.g., commands to compile, commands to link, etc.) from command client 308, buffers these processing commands, and when instructed to do so by command client 308, may perform or execute the buffered processing commands in a parallel manner; see also at least ¶¶ [0026], [0061], [0135], and [0146]).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine the cross platform, parallel processing techniques taught by Lu with the systems for developing and updating vehicle software disclosed by Moeller, because Lu teaches at ¶ [0063] that its techniques “reduces the wasting of CPU resources.” See M.P.E.P. § 2143(I)(G).
Moreover, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine the cross platform, parallel processing techniques taught by Lu with the systems for developing and updating vehicle software disclosed by Moeller, because the claimed invention is merely a combination of old elements (the cross platform, parallel processing techniques taught by Lu and the systems for developing and updating vehicle software disclosed by Moeller), in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. See M.P.E.P. § 2143(I)(A).
Claims 10 and 19: The combination of Moeller and Lu teaches the limitations as shown in the rejections above.
Moeller does not explicitly disclose, but Lu, as shown, teaches the following limitations:
wherein the object files are linked after being generated in the multi-threaded fashion (see at least ¶ [0063]: command server 306 is adapted to be multithreaded thus enabling command server 306 to launch multiple streams/threads of execution, each thread capable of processing (i.e., compiling, linking, etc.) a separate target. Additionally, in the exemplary embodiment, command server 306 pools threads. That is, command server 306 is adapted to launch several threads and then, when required, use one or more threads for the compiling of targets. The pooling of threads will improve CPU throughput utilization while minimizing the overhead of creating a new thread each time a target requires compiling. As a consequence, command server 306 reduces the wasting of CPU resources; see also at least ¶ [0173]: embodiments of the invention could designed to parallelize across multiple machines (i.e., multiple computer systems); see also at least ¶ [0002]: generally, many source code files will be created by application developers which will be compiled using a compiler and a “make” utility. As a result of compiling the source code files and linking the resulting object files, a usable and executable application can be created; see also at least ¶ [0059]: command server 306 receives processing commands (e.g., commands to compile, commands to link, etc.) from command client 308, buffers these processing commands, and when instructed to do so by command client 308, may perform or execute the buffered processing commands in a parallel manner; see also at least ¶¶ [0026], [0061], [0135], and [0146]).
The rationales to modify/combine the teachings of Moeller to include the teachings of Lu are presented above regarding claims 9 and 18 and incorporated herein.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure. The following references have been cited to further show the state of the art with respect to distributed software development.
Moeller et al. (U.S. Pub. No. 2016/0364232 A1) (OTA updating vehicle ECU);
Ishigooka et al. (U.S. Pub. No. 2015/0309920 A1) (testing control software of a controlled system); and
Moon et al. (“The migration of engine ECU software from single-core to multi-core.” IEEE Access 9 (2021): 55742-55753).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Christopher Tokarczyk, whose telephone number is 571-272-9594. The examiner can normally be reached Monday-Thursday between 6:00 AM and 4:00 PM Eastern.
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, Mamon Obeid, can be reached at 571-270-1813. 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.
/CHRISTOPHER B TOKARCZYK/Primary Examiner, Art Unit 3687
Prosecution Insights