DETAILED ACTION
Case Status
This office action is in response to remarks and amendments of 4 May 2026. Claims 1-3 and 5-10 have been examined.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 2-3 and 5-10 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Claims 2-3 and 5-10 are directed to one of the eligible categories of subject matter.
With respect to independent claim 6 and dependent claims 8, 9, 10, the execute, converting, generating covers performance of the limitations manually and/or in the mind (mental processes abstract idea). The providing limitations are recited at a high level of generality and do not add meaningful limitations to the abstract idea; these limitations are directed to insignificant extra solution activities. The claims as a whole merely describe how to generally “apply” the exception in a computer environment using generic computer functions or components. Even when viewed in combination, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. The claims are not patent eligible.
With respect to dependent claim 2, 3, 5 the initiating, reading, controlling, execute, defined cover performance of the limitations manually and/or in the mind (mental processes abstract idea). The sensor, actuator, device, provide are recited at a high level of generality and do not add meaningful limitations to the abstract idea; these limitations are directed to insignificant extra solution activities. The claims as a whole merely describe how to generally “apply” the exception in a computer environment using generic computer functions or components. Even when viewed in combination, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. The claims are not patent eligible.
With respect to dependent claim 7, the convert, compile, select cover performance of the limitations manually and/or in the mind (mental processes abstract idea). No additional elements are recited and so the claims do not provide a practical application and are not considered to be significantly more. The claims are not eligible.
Claim Rejections - 35 USC § 102
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 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.
Claims 6 and 7 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Eggers et al., Pub. No.: DE102004039633A1, hereinafter Eggers (paragraph numbering refers to provided EPO English translation document).
As per claim 6, Eggers discloses a method for providing at least one vehicle software application to at least one of different vehicle systems, the vehicle systems comprising differently configured electrical/electronic architecture, the electrical/electronic architecture comprising at least one data processing device configured to execute the at least one vehicle software application configured to provide vehicle functions and/or vehicle data, and the respective electrical/electronic architecture configured to provide further vehicle functions and/or vehicle data in addition to the vehicle functions and/or vehicle data provided by the data processing device (see at least pars. 2-7 and rejection of claim 1 above), the method comprising:
providing a vehicle signal specification and/or a vehicle service specification (pars. 8, 33, 80-81 disclose vehicle signals, defining data objects and mappings in a profile, models, databases and profiles specifying available vehicle data objects which corresponds to vehicle signal and service specifications);
converting the vehicle signal specification and/or the vehicle service specification to a converted vehicle signal specification and/or a converted vehicle service specification that is compatible for use in an interface description language (pars. 73, 81 disclose vehicle data specifications are formally captured in XML, making them compatible with an interface description syntax; par. 108 includes “…offer an XML format for vehicle API accesses and data. The formats are to be matched to one another.” Par. 9 discloses “Here, the device-local base interface of the vehicle API is converted into an interface based on another target language”. Par. 48 includes “Each basic data type is assigned a mapping (low-level mapping) to a low-level source/sink, which converts the corresponding vehicle datum into the object model of the vehicle API.” See also, pars. 67-78. Claim interpretation note: par. 11 of the specification defines interface description language as “a declarative formal language and includes language syntax for describing interfaces of a software component”);
generating at least one interface description for at least one access interface using the interface description language, the at least one access interface provided to access the vehicle functions and/or vehicle data and the further vehicle functions and/or vehicle data (pars. 7, 8, 99, 103, 110 disclose generation of interface descriptions); and
generating the at least one vehicle software application using the at least one interface description generated (par. 79-80 discloses data object mapping to API (connection of manufacturer-specific application) and see par. 108 - note that OSGi is a framework for modular development of applications).
As per claim 7, Eggers discloses The method according to Claim 6, further comprising: converting the interface description to use the interface description in a desired programming language including Java, C, C++, or Rust, to generate the at least one vehicle software application in the desired programming language; compiling the generated vehicle software application; and selecting a runtime environment of the at least one data processing device to execute the compiled vehicle software application on the selected runtime environment (see rejection of claim 6 and at least pars. 107-108. Eggers describes converting the interface for use in Java or C++ and generating applications, by creating local interfaces (mappings) for specific target languages, as well as selecting a runtime environment to execute the applications by means of specific execution environments such as OSGi).
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.
The factual inquiries 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 2, 3, 5, 8, 9 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Eggers in view of Brandel et al., Pub. No.: US 20200410996 A1, hereinafter Brandel.
As per claim 1, Eggers discloses method for providing access from at least one vehicle software application to at least one of different vehicle systems, the vehicle systems comprising differently configured electrical/electronic architecture, the electrical/electronic architecture comprises at least one data processing device configured to execute the at least one vehicle software application for providing vehicle functions and/or vehicle data, and the electrical/electronic architecture configured to provide further vehicle functions and/or vehicle data in addition to the vehicle functions and/or vehicle data provided by the at least one data processing device (see at least pars. 2-7 of the provided EPO English translation and note that par. 5 discloses access by applications to vehicle information across differing vehicle bus and differing vehicle system technologies), the method comprising:
providing the at least one vehicle software application, the at least one vehicle software application configured to be executed in runtime environments of the at least one data processing device (par. 7: service framework with application programs, par. 108: services, service framework, OSGi framework, etc.); and
providing an access interface to the runtime environments for the at least one vehicle software application, the access interface defined by an interface description language (at least par. 7 discloses VAPI which is an access interface; additionally, and/or alternatively, par. 108 discloses CORBA which utilizes CORBA IDL to specify interfaces, and maps from IDL to implementation in specific programming languages like C++ or Java. Claim interpretation note: par. 11 of the specification defines interface description language as “a declarative formal language and includes language syntax for describing interfaces of a software component”),
wherein the access interface is defined by the interface description language for access to the vehicle functions and/or vehicle data and the further vehicle functions and/or vehicle data (pars. 100, 101, 107, 108 disclose XML based formal descriptions defining interfaces and metadata which corresponds to an IDL; also, par. 108 discloses CORBA which utilizes CORBA IDL to specify interfaces, and maps from IDL to implementations in specific programming languages), and
wherein the access interface is defined independently of a specific configuration of the electrical/electronic architecture (see rejection of limitations above including at least pars. 3, 4, 29, 33, 48), and Eggers does not expressly disclose, however Brandel discloses wherein the at least one vehicle software application is provided by a WebAssembly byte code, as a Wasm component, to execute the at least one vehicle software application portably on different data processing devices (Brandel, pars. 21, 28-30, 40, 58 and see Eggers as cited above).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of the cited references because Brandel would have allowed Eggers to execute vehicle application interfaces using WebAssembly based runtime so that the same application logic could be deployed and executed across differing electronic architectures without recompilation, thereby predictably improving portability and maintainability/implementation efficiency in multi-platform vehicle systems.
As per claim 2, Eggers as modified discloses The method according to Claim 1, wherein: the electrical/electronic architecture comprises (i) at least one sensor and at least one actuator, and (ii) at least one further data processing device, wherein the at least one further data processing device is used at least in part for at least semi-autonomous driving and/or for controlling the at least one actuator and/or for reading out the at least one sensor, and wherein the at least one vehicle software application initiates control and/or reading (see at least pars. 7, 41, 53, 58, 110 and note that in automotive systems, low-level data sources (sensors, ECUs) generate raw signals, while sinks (actuators, other ECUs, displays) consume them).
As per claim 3, Eggers as modified discloses The method according to Claim 1, wherein: the functions and the further vehicle functions comprise controls, regulations, and/or measurements internal to the vehicle system and/or connected to the vehicle system, and the data and further vehicle data comprise measurement data from at least one sensor internal to the vehicle system and/or a sensor connected to the vehicle system, and the respective electrical/electronic architecture and the runtime environments comprise a switching function, to provide access to the further vehicle functions and/or vehicle data via the access interface defined independently of different configurations of the electrical/electronic architecture (pars. 5, 33, 58-59, 67, 110).
As per claim 5, Eggers as modified discloses The method according to Claim 1, wherein: the access interface is additionally defined by the interface description language using a vehicle signal specification and/or vehicle service specification for access to the functions and/or data and to the further vehicle functions and/or vehicle data, and the vehicle signal specification and/or the vehicle service specification provides a syntax, to structure and standardize vehicle signals and vehicle services within a context of the at least one vehicle software application (pars. 7, 8, 99, 100, 103, 107, 108. XML based interface descriptions define vehicle data objects and access methods constitute a syntax structuring and standardizing vehicle signal/services).
As per claim 8, Eggers as modified discloses The method according to Claim 1, wherein a computer program comprises instructions that, when the computer program is executed by a computer, cause the computer to perform the method (see rejection of claim 1).
As per claim 9, Eggers as modified discloses A device for data processing, configured to perform the method according to Claim 1 (see rejection of claim 1).
As per claim 10, Eggers as modified discloses A non-transitory computer-readable storage medium, comprising instructions that, when executed by a computer, cause the computer to perform the method according to Claim 1 (see rejection of claim 1).
Response to Arguments
Applicant's arguments filed 4 May 2026 have been fully considered but they are not persuasive.
With respect to the 35 USC 101 rejection of claim 6, the remarks present that the claim provides a clear improvement to a technology or to a technical field and refers to several paragraphs of the specification (pars. 3, 5, 14, 19, 20, 22). Additionally, page 10-11 of the remarks presents:
PNG
media_image1.png
102
631
media_image1.png
Greyscale
PNG
media_image2.png
138
633
media_image2.png
Greyscale
Examiner respectfully disagrees. In both Enfish and McRo, the claims themselves recited the specific technical means found to be an improvement: a self-referential table structure in Enfish and specific timing rules tied to phoneme sub-sequences in McRo, and claim 6 recites no comparable technical mechanism. Claim 6 is recites a desired result without a specific means of accomplishing it. Even if claim 6 were to be amended to include the Wasm limitation of claim 1, it would be a further additional element directed off-the-shelf technology. The specification admits that the alleged improvement is achieved through specific, well-known off-the-shelf technologies (the WebAssembly core format, WASI, WIT, Wasmtime, wit-bindgen, the Wasm component model).
With respect to the prior art rejection of claim 1, the remarks on page 13 include:
PNG
media_image3.png
103
630
media_image3.png
Greyscale
This argument is not persuasive because the rejection does not rely on Brandel, the secondary reference, for the vehicle software environment and/or the vehicle functions; Eggers, the primary reference, is relied upon for the vehicle software environment and/or the vehicle functions. Brandel is relied upon for the known Webassembly byte code/Wasm component portability technique. A secondary reference need not disclose the entire claimed invention.
Regarding the “non-analogous content” argument, note that Brandel is directed to solving the same problem addressed by the application: improving portability, interoperability of software across different platforms, devices, operating systems, and architectures. The remarks admit that WebAssembley (Wasm) is conventional technology in the background section of the instant application. The specification does not implement in a new way, enhance, improve or otherwise modify the WebAssembly core format, WASI, WIT, Wasmtime, wit-bindgen, or the Wasm component model in any manner whatsoever. The specification merely describes using WASM entirely as pre-existing off-the-shelf technology.
With respect to the prior art rejection of claim 6, the remarks on page 15 include:
PNG
media_image4.png
94
637
media_image4.png
Greyscale
This argument is not persuasive because the claim does not require COVESA or any particular “formal” industry standard vehicle signal/service specification. Eggers’ vehicle API profiles, vehicle data-object definitions, XML mappings, and formal interface descriptions are sufficient under BRI to meet the recited vehicle signal/service specification and conversion limitations. Eggers, pars. 8, 33, 80-81 disclose vehicle signals, defining data objects and mappings in a profile, models, databases and profiles specifying available vehicle data objects which corresponds to the recited vehicle signal/service specification.
The remarks further present:
PNG
media_image5.png
172
617
media_image5.png
Greyscale
Firstly, it should be noted that the argument is directed to intended use language “compatible for use in an interface description language” - the claim does not actually do anything with “the converted vehicle signal specification and/or a converted vehicle service specification.”
Secondly, Applicant’s mischaracterizes Eggers’ XML format as solely a means of expressing runtime configuration and mapping rules. Eggers, pars. 73, 81 disclose vehicle data specifications are formally captured in XML, making them compatible with an interface description syntax; par. 108 includes “…offer an XML format for vehicle API accesses and data. The formats are to be matched to one another.” Par. 9 includes “Here, the device-local base interface of the vehicle API is converted into an interface based on another target language”. Par. 48 includes “Each basic data type is assigned a mapping (low-level mapping) to a low-level source/sink, which converts the corresponding vehicle datum into the object model of the vehicle API.” See also, pars. 67-78. These disclosures teach converting a vehicle signal/service description into a converted, IDL-compatible representation as required by the claim. Note that the specification, at par. 11, defines interface description language as “a declarative formal language and includes language syntax for describing interfaces of a software component.”
Conclusion
THIS ACTION IS MADE FINAL. 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 SYED HASAN whose telephone number is (571)270-5008. The examiner can normally be reached M-F 8am - 5 pm.
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, Boris Gorney can be reached at (571)270-5626. 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.
/SYED H HASAN/Primary Examiner, Art Unit 2154
Prosecution Insights