DETAILED ACTION
Claims 1-20 are presented for examination.
Claims 1, 9, 13-14, 16, and 20 have been amended.
Claims 8, 10-12, and 18 have been cancelled.
This office action is in response to the amendment submitted on 23-JUN-2026.
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 .
Examiner’s Note (EN)
The prior art rejections below cite particular paragraphs, columns, and/or line numbers in the references for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art.
Response to Arguments – 35 USC 101
In the Applicant/Arguments Remarks, Applicant argues the amended claims have overcome the rejection under 35 USC 101. The arguments have been fully considered and are persuasive. The rejection has been withdrawn.
Response to Arguments – 35 USC 103
Applicant’s arguments with respect to the 103 rejections have been considered, but are moot in view of the new ground(s) of rejection provided below.
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-3, 5-7, 9, 13, 16-18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Jung et al. (US20250094319A1) in view of Berat (US20250021438A1) and further in view of Kuwabara et al. (US20240303071A1)
Regarding Claim 1, Jung teaches a non-transitory computer-readable medium having instructions recorded thereon that, in response to execution by one or more processors, cause performance of operations comprising ([0130] “Accordingly, the operations of the method or algorithm described in connection with the example embodiments disclosed in the specification may be directly implemented with a hardware module, a software module, or a combination of the hardware module and the software module, which is executed by the processor 1100. The software module may reside on a storage medium (i.e., the memory 1300 and/or the storage 1600) such as a random access memory (RAM), a flash memory, a read only memory (ROM), an erasable and programmable ROM (EPROM), an electrically EPROM (EEPROM), a register, a hard disk drive, a removable disc, or a compact disc-ROM (CD-ROM).”)
building a new version of an upstream software part in the software system based on the updated hardware communication specification ([0093] and [0115] "In operation S910, the development apparatus may extract the settings and functional clusters of the ARXML-based BSW. For example, the development apparatus may perform settings for generating the first wrapper that may be executed in the first operating system by extracting the settings of the BSW included in the ARXML. For reference, the settings of the BSW illustrated in FIG. 9 may be the same as the settings of the adaptive AUTOSAR platform. In operation S920, the development apparatus may implement and/or generate a wrapper code that may be executed in a Windows development environment and a wrapper code that may be executed in a Linux development environment. For example, the development apparatus may generate a first wrapper that may be executed in a Windows development environment based on the settings of the extracted BSW. As in the above description, the development apparatus may generate a second wrapper that may be executed in a Linux development environment based on the settings of the extracted BSW. In particular, the development apparatus may generate a first wrapper that includes functional clusters and to which test vectors may be applied. In addition, the development apparatus may generate a second wrapper that includes functional clusters and to which the proxy-skeleton may be applied.")
testing the new version of the upstream software part ([0117] "In operation S930, the development apparatus may apply the first wrapper to the application core. The development apparatus may perform testing of the application core by applying the first wrapper to the application core. Thereafter, the development apparatus may determine whether an API is complete by performing a test of the application core.")
in response to the testing of the new version of each downstream software part among the plurality of downstream software parts being successful, releasing the new version of each downstream software part in the software system ([0125-0126] “In operations S1040 to S1060, the development apparatus may store the code of the application core in the development repository based on when testing or verification of the application core is completed. Thereafter, the development apparatus may build the application cores by applying the second wrapper to the application core in a real development environment. The development apparatus may verify the built application core. In operation S1070, the development apparatus may perform distribution of the application core through an automatic distribution management tool, based on the case where verification of the built application core is completed.” Fig. 7 and [0098-0104] describe the plurality of software parts)
building a new version of the software system based on the new version of each among the plurality of downstream software parts ([0004] “Due to the development characteristics of the adaptive AUTOSAR platform (hereinafter referred to as adaptive AUTOSAR) among the AUTOSAR platforms, Application Software Layer (ASW) developers have no choice but to have dependency on a Basic Software Layer (BSW).” EN: ASW is the downstream layer, while BSW is the upstream layer. [0105-0111] describe the interaction between the upstream and downstream layers in development context. [0010] “In addition, an aspect of the present disclosure provides a development apparatus and development method that may generate an adaptive application with the same application core even when the version of the adaptive AUTOSAR is changed and may ensure the reusability of the application core, by applying the adaptive application generated using the first wrapper and the second wrapper to the AUTOSAR to perform the control logic included in the application core.” And Fig. 10, [0120-0126] “In operations S1040 to S1060, the development apparatus may store the code of the application core in the development repository based on when testing or verification of the application core is completed. Thereafter, the development apparatus may build the application cores by applying the second wrapper to the application core in a real development environment. The development apparatus may verify the built application core. In operation S1070, the development apparatus may perform distribution of the application core through an automatic distribution management tool, based on the case where verification of the built application core is completed.” Fig. 7 and [0098-0104] describe the plurality of software parts)
in response to the testing of the new version of each among the plurality of downstream software parts being successful ([0125-0126])
implementing the new version of the software system into the vehicle for operation ([0125-0126])
However, Jung is not relied on for:
detecting an update of a hardware communication specification of a vehicle to include one of a new signal or a new data type to a list of one of signals or data types for communication between software parts in a software system for vehicle operation
in response to detecting the update
in response to the testing of the new version of the upstream software part being successful, releasing the new version of the upstream software part in the software system
determining that a plurality of downstream software parts depend on the upstream software part
building a new version of each downstream software part among the plurality of downstream software parts based on the new version of the upstream software part
testing the new version of each downstream software part among the plurality of downstream software parts
Berat teaches in response to the testing of the new version of the upstream software part being successful, releasing the new version of the upstream software part in the software system ([0016] "After completing this initial testing of the updated software package 102, the developer 104 may interact with the computer system 132 to trigger a rebuild engine 110. For example, the developer 104 can interact with a graphical user interface provided by the computer system 132 to trigger the rebuild engine 110. The rebuild engine 110 can perform more comprehensive testing to detect integration problems between the updated software package 102 and one or more downstream products.")
determining that a plurality of downstream software parts depend on the upstream software part ([0016-0018] and [0046-0047] Also see Jung [0105-0111])
building a new version of each downstream software part among the plurality of downstream software parts based on the new version of the upstream software part ([0017-0019] "More specifically, the rebuild engine 110 can identify a set of downstream products 112 that rely on the software package (e.g., the updated version 102 or a prior version of the software package). In some examples, the rebuild engine 110 can determine the set of downstream products 112 from a predefined file 114…After obtaining the source code for the downstream products 112 that rely on the software package 102, the rebuild engine 110 can attempt to rebuild each of the downstream products 112 using their source code and the updated software package 102. For example, the rebuild engine 110 can perform a first rebuild process 122 a on a downstream product (e.g., Product A) using source code 118 for the downstream product and the updated software package 102. This can involve generating a binary file 130 a based on the source code 118 and the updated software package 102, for example by compiling the source code 118 into the binary file 130 a. One or more tests 124 a can then be executed on the binary file 130 a to detect defects. A report 126 a can be generated indicating whether the binary file 130 a passed or failed the tests 124 a.")
testing the new version of each downstream software part among the plurality of downstream software parts ([0019] and [0011] "Through the above process, the testing system can automatically assess the impact of an updated software package on a large number of dependent downstream products, so that any bugs can be resolved preemptively before the update is formally released." )
Jung and Berat are analogous art because they are from the same field of endeavor in software component dependency testing, build and release. Before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art, to combine Jung and Berat to incorporate Berat more extensive treatment of dependency testing and building into Jung’s software dependency testing and release in the context of automotive software development.
Kuwabara teaches detecting an update of a hardware communication specification of a vehicle to include one of a new signal or a new data type to a list of one of signals or data types for communication between software parts in a software system for vehicle operation ([0083] “Basic data is already registered in the development device 2. Therefore, in the next update of the vehicle software, new vehicle software is generated using the update data input from the request side and the information other than the update data stored in the storage 21. Then, the updated vehicle software is provided to the request side. In other words, when the vehicle software is updated, the request side does not need to provide all the information related to the development of vehicle software to the development side. The request side may provide the development side with information specifying the vehicle software to be updated including the version and information indicating the update portion. The information specifying the vehicle software to be updated includes the version, the package information, or base software information. The information indicating the update portion is a file described in a predetermined format, such as a spreadsheet software file, an ARXML format file, or a JSON format file.” Also [0095], [0039] “The routing map is generated based on a specification provided by the request side. However, when the number of communication nodes 11 increases or the path becomes complicated, there is a possibility that the correspondence described in the specification is erroneously read or erroneously input at the time of programming. Therefore, in the present embodiment, information necessary for generating the routing map is input as the communication specification in a predetermined format. This communication specification corresponds to update information” EN: The signals and data type definitions associated with the additional nodes are new. Also see Jung [0093 and 0114] )
building a new version of an upstream software part in the software system based on the updated hardware communication specification in response to detecting the update ([0049-0050] “The instruction unit 34 specifies the vehicle software to be developed based on the update data, passes the update data to the development environment 4 of the specified vehicle software, and generates new vehicle software in which the update data is reflected. The generation unit 35 generates new vehicle software in which the update data is reflected based on the instruction from the instruction unit 34. In the generation unit 35, a source code is generated from the update information by a code generation tool 35 a, and an object of new vehicle software is generated from the source code by an object generation tool 35 b.”)
Jung. Berat, and Kuwabara are analogous art because they are from the same field of endeavor in software component dependency testing, build and release. Kuwabara teaches the known method of detecting updates to the CAN including new nodes being added and re-generating the software based on the updates. Before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art, to combine Jung, Berat and Kuwabara to incorporate Kuwabara’s known method into Jung’s software dependency testing and release in the context of automotive software development in order to streamline the development and release process of automotive applications.
Regarding Claim 2, Jung in view of Berat and further in view of Kuwabara teaches the medium of claim 1. Berat further teaches wherein the operations further comprise indicating, in response to the testing of the new version of the downstream software part not being successful, unsuccessful testing of the downstream software part ([0019] " A report 126 a can be generated indicating whether the binary file 130 a passed or failed the tests 124 a. The report 126 a can also include build logs, test logs, or both. If the binary file 130 a passed all of the tests 124 a, then the rebuild engine 110 can determine that the updated software package 102 does not negatively impact that particular downstream product. If the binary file 130 a failed one or more of the tests 124 a, then the rebuild engine 110 can perform additional operations to determine a root cause of the failure."). Refer to claim 1 for the motivation to combine.
Regarding Claim 3, Jung in view of Berat and further in view of Kuwabara teaches the medium of claim 2. Berat further teaches wherein the operations further comprise maintaining the new version of the upstream software part in response to the testing of the new version of the downstream software part not being successful ([0019-0021] "The report 126 a can also include build logs, test logs, or both. If the binary file 130 a passed all of the tests 124 a, then the rebuild engine 110 can determine that the updated software package 102 does not negatively impact that particular downstream product. If the binary file 130 a failed one or more of the tests 124 a, then the rebuild engine 110 can perform additional operations to determine a root cause of the failure…Conversely, if the binary file 130 b failed one or more of the tests 124 b (e.g., the same tests that were failed during the first rebuild process 122 a), then it may be harder to discern the root cause of the problem—the root cause could be the update to the software package, a defect in the downstream product, or something else. So, the rebuild engine 110 can transmit an output 128 to the developer 104 that indicates the problem and that its root cause cannot be determined by the rebuild engine 110. The output 128 may also include at least some of the reports 124 a, 126 b, such as their build logs and/or test logs, which can be used to help the developer 104 further narrow down the root cause of the problem." EN: if the build fails, and the testing process can’t figure out what the source problem is, the upstream is maintained and a report is sent to the user to further investigate the problem.) Refer to claim 1 for the motivation to combine.
Regarding Claim 5, Jung in view of Berat and further in view of Kuwabara teaches the medium of claim 1. Berat further teaches wherein the testing the new version of the upstream software part includes testing functionality specific to the upstream software part (R, [0015] "In some examples, prior to uploading the updated software package 102 to the computer system 132, the developer 104 may test the updated software package 102 for defects such as bugs. This initial set of tests can be more about detecting defects in the updated software package 102 itself, independently of any downstream products, rather than detecting unwanted side effects from integrating the updated software package 102 with downstream products. For example, the developer 104 can execute testing software on the client device 106 to perform software tests (e.g., units tests and integration tests) on the updated software package 102. Additionally, or alternatively, the developer 104 can upload the updated software package 102 to the computer system 132, which can execute the testing software to perform at least some of the software tests. If any defects are flagged at this stage, the developer 104 can modify the update to resolve the defects." EN: Also see Jung [0091-0092] where the upstream functionality used in the build of the upstream component is specifically related to the automotive control components.). Refer to claim 1 for the motivation to combine.
Regarding Claim 6, Jung in view of Berat and further in view of Kuwabara teaches the medium of claim 5. Jung further teaches wherein the testing the new version of the upstream software part includes determining one or more functional requirements of the upstream software part ([0084-0085] "The development apparatus may perform a test of the application core 430 by comparing the expected output corresponding to the test input with the test output. For example, the expected output corresponding to the test input may represent an output that a typical ASW and/or a BSW developer may estimate based on the test input and the application core 430 described above. That is, the expected output corresponding to the test input may include an output that may be obtained when the test input and the vehicle control logic included in the application core 430 are executed on the adaptive AUTOSAR platform." EN: expected output based on test input reflect the intended functional behavior, ie. requirements)
Regarding Claim 7, Jung in view of Berat and further in view of Kuwabara teaches the medium of claim 5. Jung further teaches wherein the testing the new version of the upstream software part includes simulating a hardware component ([0076-0078] "FIG. 3 is a diagram illustrating a method of testing an application core in a virtual environment and applying an application core in a real environment in a development apparatus. Referring to FIG. 3 , FIG. 3 illustrates a software architecture in which a development apparatus (e.g., the development apparatus 100 of FIG. 1 ) applies wrappers to an application core 300. The development apparatus may symmetrically include a virtual environment 301, which is a virtual development environment, and a real environment 311, which is a real development environment. In this case, the application core 300 may be used equally in both environments, without distinction between the virtual environment 301 and the real environment 311. In contrast, the wrappers may be used as a first wrapper in the virtual environment 301 and as a second wrapper in the real environment 311." EN: The virtual environment simulates the hardware components of the real environment by running the BSW/ASW without any real ECU hardware)
Regarding Claim 9, Jung in view of Berat and further in view of Kuwabara teaches the medium of claim 1. Jung further teaches wherein the hardware communication specification is for a Controller Area Network (CAN) of a vehicle ([0003] "The AUTOSAR (AUTomotive Open System Architecture) platform, an international standard applied to effectively perform computational processing and improve development convenience in response to changes in vehicle architecture, is being applied to vehicle controllers. The AUTOSAR platform may be available in two varieties: an classic AUTOSAR platform (also referred to as AUTOSAR Classic Platform), which uses a microcontroller unit (MCU) to meet real-time requirements, and an adaptive AUTOSAR platform (also referred to as AUTOSAR Adaptive Platform), which is implemented with a high-performance processor." EN: CAN is the standard AUTOSAR bus system)
Regarding Claim 13, Jung in view of Berat and further in view of Kuwabara teaches the medium of claim 1. Jung further teaches wherein the building and the testing of the new version of the downstream software part is performed in parallel with the building and the testing of the new version of each other among the plurality of downstream software parts ([0028-0029] "The control logic may be included in the application core. Testing the application core may include: dividing the control logic into a plurality of software components; and applying the first wrapper to the plurality of software components. The development method may further include: invoking a plurality of threads, whose quantity is equal to a quantity of software components in the plurality of software components; and executing, via a different one of the plurality of threads, each of the plurality of software components.").
Claims 16-18 are method claims reciting limitations similar to claims 1-3 and are rejected under the same rationale.
Claim 20 is an apparatus claim reciting limitations similar to claim 1 and is rejected under the same rationale.
Claims 4, 14 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Jung et al. (US20250094319A1) in view of Berat (US20250021438A1) and further in view of Kuwabara et al. (US20240303071A1) and further in view of Lin et al. (US20110239195A1)
Regarding Claim 4, Jung in view of Berat and further in view of Kuwabara teaches the medium of claim 2. Lin further teaches wherein the operations further comprise rebuilding the downstream software part in response to receiving a modified package of the downstream software part ([0041] “Embodiments of dependence-based software builds also provide for an efficient and accurate incremental build. The incremental build capability enables rebuilding only the subset of the source project which is actually impacted by a change while producing accurate output. When a subset of the source project has previously been built on a given machine and some source code changes are made, subsequent rebuilds are fast and reliable. With the dependency graph 402 and a build trace 410, updates to a buildable unit can be detected and rebuilt. Further, partial build and incremental build scenarios can be combined together. For example, a developer can incrementally rebuild a component after project files have been modified and transitively rebuild all of its consumers incrementally.”)
Jung, Berat and Lin are analogous art because they are from the same field of endeavor in software component dependency testing, build and release. Before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art, to combine Jung, Berat and Lin to incorporate Lin’s more explicit testing of downstream components in response to new updates into Jung’s software dependency testing and release in the context of automotive software development with expected results.
Regarding Claim 14, Jung in view of Berat and further in view of Kuwabara teaches the medium of claim 1. Lin further teaches wherein the operations further comprise building a new version of a further downstream software part based on the new version of the downstream software part further in response to the testing of the new version of the downstream software part being successful ( [0027] "A developer at the developer computer device 302 can author source code 312 as a buildable unit 314 of the software build project 308. The computer device 302 receives the authored source code 312 as inputs to the computer device, and the buildable unit 314 of the software build project 308 is developed. Dependent buildable units 316 are identified as buildable units that have a dependency relationship with the buildable unit 314 for execution. For example, the dependent buildable units 316 may be one or more child buildable units that are dependent on the buildable unit 314 for execution. Alternatively or in addition, the dependent buildable units 316 may be one or more parent buildable units from which the buildable unit 314 is dependent on for execution." [0033-0034] "With this dependency information, a build 404 (e.g., a software build project) can be scheduled so that the identified dependencies are respected for subsequent builds (i.e., consumer buildable units are not scheduled until producer buildable units have all completed successfully). Any target buildable unit can then be built successfully by traversing its producer chain, rather than employing the possibly error-prone manual processes or with an ad-hoc script. All of the consumers of a given buildable unit can also be built, thus minimizing the risk of inadvertently providing or introducing a change which may break future instantiations of build 404. Furthermore, a detailed analysis of the build processes can be performed to evaluate whether a predefined set of software development policies are followed. Potentially unsafe operations can be intercepted at an early stage of development, rather than being discovered later in the product cycle, or potentially not recognized until after the final product has been distributed for use. Conceptually, a build process to build a large-scale software project can be outlined as follows: a top level build processes starts; it reads and/or writes files; it generates a number of child processes; the child processes each read and/or write files, run other child processes, and then completes; and the top level build process finishes and is complete. The example architecture 400 includes a build tracer 406 that monitors the top level build processes as it executes.")
testing the new version of the further downstream software part ([0028] “The developer computer device 302 may also include a dependence validation application 318 used to validate that the authored source code 312 of the buildable unit 314 executes with the dependent buildable units 316 for error-free execution before the buildable unit 314 is subsequently provided to the software build service 304 and compiled into the software build project 308.”)
For motivation to combine, please see claim 4.
Claim 19 is a method claim reciting limitations similar to claim 4 and is rejected under the same rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Mesde et al. (US20210382814A1): discloses versioned testing and release methods for automotive software.
Qian et al. (US20230229417A1): discloses automotive firmware release and update.
Gu et al. (US20170097821A1): discloses parallel build system.
Yao et al. (US20200387611A1): discloses automatic firmware validation in vehicles.
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 AMIR DARWISH whose telephone number is (571)272-4779. The examiner can normally be reached 7:30-5:30 M-Thurs.
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, Lewis Bullock can be reached on 571-272-3759. 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.
/A.E.D./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights