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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 08/05/2024 is being considered by the examiner.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
Bridge module in claim 1
Shore module
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
Based on the specification, the bridge module is interpreted to be a microcontroller (e.g. paragraph 0008).
Shore module is interpreted to be a microcontroller (e.g. paragraph 0032).
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 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.
Claim(s) 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Bauer US20200125858A1 as evidenced by Techterms 2023 (https://techterms.com/definition/plug_and_play, 2023), and Techterms 2012 (Driver Definition - What is a device driver?, 2012).
Regarding claim 1, Bauer teaches;
A computer-implemented method when executed on data processing hardware causes the data processing hardware to perform operations (taught as an automotive electrical and electronic system [E/EA] that supports autonomous vehicles to distribute, receive, process and send signals, paragraph 0082) comprising:
receiving an identification signal from a bridge module (taught by a power and data center, [hereafter PDC], e.g. paragraph 0006) associated with a component of a vehicle (indicated in the PDC using an identifier [ID] of a device [e.g. a vehicle component, such as sensors, actuators, controllers etc. paragraph 0006] to transfer data from one component to multiple computing platforms, using a discovery function to communicate [such as loading a driver] with the device with such ID, paragraph 0177; this essentially indicates that 1) there is a discovery function in the PDC that is able to search and find/match an ID for an end point device, and 2) the PDC communicates data with other computing platforms and devices, serving as an intermediary for data/communication);
[[responsive to receiving the identification signal]] retrieving a command list and a dependency list associated with the component (taught as loading a device driver, paragraph 0177);
[[responsive to detecting a selected dependency of the dependency list]], transmitting a command of the command list corresponding to the selected dependency to the bridge module (taught as the computing platform starting a driver for the component, paragraph 0175), the command when received by the bridge module causing the bridge module to control an operation of the component (taught as the PDC loading a driver that has a matching ID to the component, paragraph 0177).
While “responsive to receiving the identification signal”, and “responsive to detecting a selected dependency of the dependency list”, i.e. the specific order/triggering of steps, is not explicitly taught, such features are naturally part of device drivers and plug and play computing.
As evidenced by Techterms 2023, plug and play causes the operating system to;
detect and identify the device,
locate and install device drivers (from a library or online repository)
configure the device by assigning resources
Bauer explicitly invokes the use of Plug and Play as a way to make adding new edge devices effortless (e.g. paragraph 0201). One of ordinary skill in the art would understand that the use of plug and play includes the step order described (retrieve device ID, retrieve drivers for device, and command/configure the device), as evidenced by Techterms 2023.
Furthermore, device drivers taught in Bauer, would necessarily have command/dependency lists described.
As evidenced by Techterms 2012, device drivers enable a hardware device to work with a computer’s operating system, wherein the specific, correct drivers enable/provide the options and functionality for the operating system to control the device. In the context of Bauer, the use of identifying and installing device drivers would thus include the options and functionalities required to control a device, as evidenced by Techterms 2012.
To reiterate, one of ordinary skill in the art would recognize that Bauer, by invoking the use of plug and play, would respond to the installation of a component/device via the intermediary communication provided by the PDC, which further communicates with other computing platforms, to obtain the device drivers, which detail commands/functions of the device and the dependencies of it, in the order of operations described in the claim.
Regarding claim 2, Bauer teaches;
The method of claim 1 (see claim 1 rejection), wherein the bridge module transmits the identification signal responsive to receiving an identification request from a shore module (taught as the PDC being coupled/integrated with a small ECU, which controls vehicle functions, paragraph 0094; in this, a PDC serves as the ‘bridge module’, and the ECU serves as the ‘shore module’ that receives and controls data sent to a device).
Regarding claim 3, Bauer teaches;
The method of claim 2 (see claim 2 rejection), wherein the shore module transmits the identification request to the bridge module responsive to detecting installation of the bridge module at the vehicle.
While “responsive to detecting installation of the bridge module at the vehicle”, i.e. the specific order/triggering of steps, is not explicitly taught, such features are naturally part of device drivers and plug and play computing.
As evidenced by Techterms 2023, plug and play causes the operating system to;
detect and identify the device,
locate and install device drivers (from a library or online repository)
configure the device by assigning resources
Bauer explicitly invokes the use of Plug and Play as a way to make adding new edge devices effortless (e.g. paragraph 0201). The use of plug and play inherently includes the step order described (retrieve device ID, retrieve drivers for device, and command/configure the device).
To reiterate; the basic structure of plug and play would, upon a device being installed/plugged in, cause the operating system [akin to a shore module or program] automatically to detect and identify the device through an identification protocol.
Regarding claim 4, Bauer teaches;
The method of claim 2 (see claim 2 rejection), wherein the bridge module comprises one bridge module of a plurality of bridge modules connected to the shore module (taught as PDCs, here each zone includes one or more PDCs, paragraph 0104, and each PDC integrates a small ECU, paragraph 0094, that corresponds to a shore module by controlling functions of the connected device).
Regarding claim 5, Bauer teaches;
The method of claim 4 (see claim 4 rejection), wherein the shore module and the plurality of bridge modules connected to the shore module are operable to control operation of a respective set of components of the vehicle (taught as dividing a vehicle into zones, where each zone includes one or more PDCs coupled to sensors and components, paragraph 0104), each bridge module of the plurality of bridge modules associated with one or more of the components of the respective set of components (taught as each PDC [which integrates a small ECU] controls loads, sensors, actuators and vehicle functions in the zone, paragraph 0094).
Regarding claim 6, Bauer teaches;
The method of claim 5 (see claim 5 rejection), wherein the shore module is assigned to a respective zone of the vehicle (taught as dividing a vehicle into zones, where each zone includes one or more PDCs, paragraph 0104) and the respective set of components of the vehicle controlled by the bridge module and the plurality of bridge modules are installed at or near the respective zone of the vehicle that the shore module is assigned (taught as dividing a vehicle into zones, where each zone includes one or more PDCs, paragraph 0104, where each PDC controls loads, sensors, actuators and vehicle functions in the zone, paragraph 0094).
Regarding claim 7, Bauer teaches;
The method of claim 1 (see claim 1 rejection), wherein retrieving the command list and the dependency list comprises retrieving the command list and the dependency list wirelessly from a remote server (taught as using an open server platform [OSP] system architecture to provide plug and play drivers, paragraph 0201).
While not explicitly retrieved from a remote server, such a feature is naturally tied to the plug and play driver. As evidenced by Techterms 2023, plug and play causes the operating system to;
detect and identify the device,
locate and install device drivers (from a library or online repository)
configure the device by assigning resources
Thus, the source of device drivers, using an OSP as described by Bauer, would include online repositories for device drivers, as evidenced by Techterms 2023.
Regarding claim 8, Bauer teaches;
The method of claim 1 (see claim 1 rejection), wherein detecting the selected dependency comprises detecting a signal associated with the operation of the component on a communication network of the vehicle (taught as the PDC receiving data from the component, paragraph 0175, where communication occur, in an example, along a scalable automotive server hardware platform, paragraph 0171).
Regarding claim 9, Bauer teaches;
The method of claim 1 (see claim 1 rejection), wherein the bridge module is connected to a communication network of the vehicle (taught as the PDC providing a continuous communication links between the PDC and the computing platform, e.g. paragraph 0148).
Regarding claim 10, Bauer teaches;
The method of claim 1 (see claim 1 rejection), wherein the bridge module comprises a microcontroller unit (MCU) operable to control the operation of the component (taught as the PDC, via the computing platform, enabling control of the component, paragraph 0175, such as by integrating a small ECU with the PDC, paragraph 0094).
Regarding claims 11-20, it has been determined that no further limitations exist apart from those previously addressed in claims 1-10. Therefore, claims 11-20 are rejected under the same rationale as claims 1-10 respectively.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
For further zonal architectures of vehicles; US20250296582A1, US20240073093A1, US10848488B2
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GABRIEL ANFINRUD whose telephone number is (571)270-3401. The examiner can normally be reached M-F 9:30-5:30.
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, Jelani Smith can be reached at (571)270-3969. 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.
/GABRIEL ANFINRUD/Examiner, Art Unit 3662
/JELANI A SMITH/Supervisory Patent Examiner, Art Unit 3662
Prosecution Insights