Office Action 1: Non-Final Rejection (2024-09-30)
Rejection types: 102 - Lack of Novelty, 103 - Obviousness, 112 - Written Description/Enablement

CLAIMS:
Claims

1\. A method of configuring a vehicle to integrate an accessory comprising:
generating for display a graphical user interface allowing the user to specify one or more high-level accessory-related rules relating to the operation of a vehicle equipped with the accessory;
receiving user-specified high-level accessory-related rules entered by the user via the graphical user interface translating the rules into a lower-level accessory-related configuration readable by an accessory interface unit adapted for communication with sensors or actuators associated with the vehicle accessory;
providing the lower-level accessory-related configuration to the accessory interface unit;
whereby the accessory interface unit cooperates with the sensors or actuators associated with the vehicle accessory to operate the vehicle accessory in accordance with the high-level accessory-related rules.

2\. The method of claim 1, further comprising translating the accessory-related rules to a low-level driver console configuration file for specifying the appearance of one or more GUI elements on the console providing an operator of the vehicle with one or both of control of the vehicle accessory and visibility of the status of the vehicle accessory.

3\. The method of claim 1, further comprising storing the high-level accessory- related rules in persistent storage accessible to users tasked with configuring other vehicles with the accessory.

4\. The method of claim 3, further comprising:
retrieving one or more high-level accessory-related rules from the persistent storage;
generating a graphical user interface for editing the accessory-related rules; receiving user edits of the retrieved accessory-related rules;
storing the edited accessory-related rules in the persistent storage accessible to users tasked with configuring other vehicles with the accessory.

5\. The method of claim 1, further comprising generating for display a graphical user interface enabling the modification of a stored high-level accessory-related rule.

6\. The method of claim 1 wherein providing the lower-level accessory-related configuration to the accessory interface unit comprising transmitting the accessory-related configuration to the accessory interface unit over an external communication link to the vehicle.

7\. The method of claim 1 wherein the high-level accessory related rules comprise event-action rules or condition-action rules.

8\. The method of claim 7 wherein the high-level accessory related rules comprise condition-action rules in which the condition includes a parameter from a sensor associated with the accessory.

9\. The method of claim 7 wherein the action comprises operating an actuator to change the state of the accessory.

10\. The method of claim 1 further comprising simulating the operation of a vehicle equipped with the accessory, the simulation comprising generating a software model of the accessory-equipped vehicle operating in accordance with the accessory-related rules entered by the user.

11\. The method of claim 10 further comprising:
generating for display an initial state of an accessory-equipped vehicle; generating a graphical user interface allowing a user to enter user-specified events or conditions;
receiving user-specified events or conditions;
determine a resultant state of the accessory-equipped vehicle subject to user-specified events or conditions when operating in accordance with the user-specified rules; and
Display a resultant state of the accessory-equipped vehicle.

12\. A system comprising control circuitry configured to:
Display a graphical user interface allowing the user to specify one or more high-level accessory-related rules relating to the operation of a vehicle equipped with the accessory;
receive user-specified high-level accessory-related rules entered by the user via the graphical user interface; and
translate the received user-specified high-level accessory-related rules into a lower-level accessory-related configuration.

13\. A system according to claim 12 in which:
the system comprises an embedded system, the embedded system further comprising:
a controller area network port connectable to a vehicle controller area network;
one or more accessory ports connectable to electrical systems of respective accessories;
a processor;
the control circuitry being further configured to:
store the lower-level accessory-related configuration;
interpret the lower-level accessory-related configuration to generate a control signal on one of the ports in response to a sensor signal received on the accessory port, or to cause the generation of a control signal on the accessory port in response to a sensor signal received on one of the other ports.

14\. A system according to claim 13 in which the received sensor signal is indicative of a driver input on an accessory control element displayed on the driver console.

15\. A system according to claim 13 in which the output control signal controls the output of an accessory state display element on the driver console.

16\. A computer-readable medium tangibly embodying instructions executable by a processor to:
Display a graphical user interface allowing the user to specify one or more high- level accessory-related rules relating to the operation of a vehicle equipped with the accessory;
receive user-specified high-level accessory-related rules entered by the user via the graphical user interface;
translate the user-specified rules into a lower-level accessory-related configuration readable by an accessory interface unit adapted for communication with sensors or actuators associated with the vehicle accessory;
provide the lower-level accessory-related configuration to the accessory interface unit;
whereby the accessory interface unit cooperates with the sensors or actuators associated with the vehicle accessory to operate the vehicle accessory in accordance with the high-level accessory-related rules.

17\. A vehicle comprising a system according to claim 12.

OFFICE ACTION:
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 .
Claim Objections
Claims 1-2 and 4-16 are objected to because of the following informalities:
In claim 1, “generating for display a graphical user interface allowing the user to specify one or more high-level accessory-related rules relating to the operation of a vehicle equipped with the accessory” should be “generating, for display, a graphical user interface allowing [[the]] a user to specify one or more high-level accessory-related rules relating to [[the]] operation of [[a]] the vehicle equipped with the accessory
In claim 1, “receiving user-specified high-level accessory-related rules entered by the user via the graphical user interface” should be “receiving the one or more user-specified high-level accessory-related rules entered by the user via the graphical user interface;
In claim 1, “in accordance with the high-level accessory-related rules.” should be “in accordance with the one or more high-level accessory-related rules.
In claim 2, “specifying the appearance” should be “specifying [[the]] an appearance
In claim 2, “control of the vehicle accessory and visibility of the status of the vehicle accessory.” should be “control of the a status of the
In claim 4, “generating a graphical user interface for editing the accessory-related rules; receiving user edits of the retrieved accessory-related rules; storing the edited accessory-related rules in the persistent storage” should be “generating a graphical user interface for editing the one or more retrieved accessory-related rules; receiving user edits of the one or more retrieved accessory-related rules; storing the one or more edited accessory-related rules in the persistent storage
In claim 5, “generating for display a graphical user interface enabling the modification of a stored high-level accessory-related rule.” should be “generating, for display, a graphical user interface enabling [[the]] modification of a stored high-level accessory-related rule.
In claim 6, “comprising transmitting the accessory-related configuration” should be “comprises transmitting the lower-level accessory-related configuration
In claim 7, “wherein the high-level accessory related rules comprise event-action rules or condition-action rules.” should be “wherein the one or more high-level accessory related rules comprise event-action rules or condition-action rules.
In claim 8, “in which the condition includes” should be “in which [[the]] a condition includes
In claim 9, “wherein the action” should be “wherein [[the]] an action
In claim 10, “simulating the operation of a vehicle equipped with the accessory, the simulation comprising generating a software model of the accessory-equipped vehicle operating in accordance with the accessory-related rules entered by the user.” should be “simulating the operation of [[a]] the vehicle equipped with the accessory, the simulation comprising generating a software model of the accessory-equipped vehicle operating in accordance with the high-level accessory-related rules entered by the user.
In claim 11, “generating for display an initial state of an accessory-equipped vehicle; generating a graphical user interface allowing a user to enter user-specified events or conditions; receiving user-specified events or conditions; determine a resultant state of the accessory-equipped vehicle subject to user-specified events or conditions when operating in accordance with the user-specified rules; and Display a resultant state of the accessory-equipped vehicle.” should be “generating, for display, an initial state of [[an]] the accessory-equipped vehicle; generating a graphical user interface allowing [[a]] the user to enter user-specified events or conditions; receiving the user-specified events or conditions; determining a resultant state of the accessory-equipped vehicle subject to the user-specified events or conditions when operating in accordance with the user-specified high-level accessory-related rules; and displaying the resultant state of the accessory-equipped vehicle.
In claims 12 and 16, “Display” should be “display
In claim 13-15, “A system according to” should be “[[A]] The system according to
In claim 13, “one of the ports in response to a sensor signal received on the accessory port, or to cause the generation of a control signal on the accessory port in response to a sensor signal received on one of the other ports.” should be “one of the one or more accessory ports in response to a sensor signal received on the  one of the one or more accessory ports, or to cause the generation of a control signal on the  one of the one or more accessory ports in response to a sensor signal received on one of the other ports of the one or more accessory ports.
In claims 14-15, “on the driver console.” should be “on [[the]] a driver console.
In claim 15, “in which the output control signal controls” should be “in which [[the]] an output control signal controls
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.
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) because the claim limitations use 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 limitations are:
“graphical user interface” which receives input in claim 1, edits rules in claims 4-5, and allows a user to enter events in claim 11
“accessory interface unit” which reads and processes data in claims 1 and 16
Because these claim limitations are being interpreted under 35 U.S.C. 112(f), they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. A review of the specification reveals the following:
“graphical user interface”: disclosed as a touchscreen in at least [0041] in the specification. This is adequate structure.
“accessory interface unit”: disclosed in at least [0021] of applicant’s specification. However, it is not clear whether this component is hardware, software, or another form entirely. Therefore, the claims containing the limitation are indefinite and rejected under 35 USC 112(a) and 112(b).
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f), applicant may:  (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) (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).
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
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.
Claims 1-11 and 16 are rejected under 35 U.S.C. 112(a) for lacking written description and 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Regarding claims 1 and 16, the claims contain the limitation “accessory interface unit”, which invokes 35 U.S.C. 112(f). However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. In particular, the component is disclosed in at least [0021] of applicant’s specification. However, it is not clear whether this component is hardware, software, or another form entirely. Therefore, the claims containing the limitation lack written description under 35 USC 112(a) and are indefinite under 35 USC 112(b). These claims are therefore rejected under those statutes.
Applicant may:
(a)        Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f);
(b)        Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c)        Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a)        Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b)        Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Regarding claims 2-11, these claims are rejected by virtue of their dependence from claim 1, as they do not resolve the 112(a) and 112(b) issues discussed above with respect to that claim.
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 1-2 and 5-17 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Bongard et al. (US 20200369148 A1), hereinafter referred to as Bongard.
Regarding claim 1, Bongard discloses A method of configuring a vehicle to integrate an accessory (See at least Fig. 1 in Bongard: Bongard discloses that the system 10 is associated with a plurality of the accessories 12 installed to the vehicle 14 [See at least Bongard, 0033]) comprising:
generating for display a graphical user interface (See at least Fig. 1 in Bongard: Bongard discloses that the UI module 16 is configured to facilitate the interface controls by operating a graphical user interface (GUI) displayed on a haptic control arrangement [See at least Bongard, 0036]) allowing the user to specify one or more high-level accessory-related rules relating to the operation of a vehicle equipped with the accessory (See at least Fig. 1 in Bongard: Bongard disclose that the UI module 16 is configured to provide interface controls to allow a user 13 to provide input, for example, to affect operation of any of the accessories 12 associated with the vehicle 14 [See at least Bongard, 0036]);
receiving user-specified high-level accessory-related rules entered by the user via the graphical user interface (See at least Fig. 1 in Bongard: Bongard discloses that the UI module 16 is configured to provide interface controls to allow a user 13 to provide input, for example, to affect operation of any of the accessories 12 associated with the vehicle 14 [See at least Bongard, 0036])
translating the rules into a lower-level accessory-related configuration readable by an accessory interface unit adapted for communication with (See at least Fig. 1 in Bongard: Bongard discloses that the UI module 16 output is configured for controlling operation of the one or more accessories 12, this typically involves communicating with the at least one or more accessories via the wireless communication interface 25 to cause at least one of initiating operation of at least one of the one or more accessories 12, ceasing operation of at least one of the one or more accessories 12, and adjusting operation of at least one of the one or more accessories 12 [See at least Bongard, 0044]. Preparing the rules for transmission to the accessories via communication interface 25 and transmitting them may be regarded as translating them) sensors or actuators associated with the vehicle accessory (See at least Fig. 1 in Bongard: Bongard discloses that the accessories include a pair of driving lights 121, a pair of air springs 122, an air compressor 123, and a locking differential 124 [See at least Bongard, 0033]. Bongard further discloses that at least some of the accessories 12 are associated with sensor apparatus 28 [See at least Bongard, 0033]);
providing the lower-level accessory-related configuration to the accessory interface unit (See at least Fig. 1 in Bongard: Bongard discloses that the UI module 16 output is configured for controlling operation of the one or more accessories 12, this typically involves communicating with the at least one or more accessories via the wireless communication interface 25 to cause at least one of initiating operation of at least one of the one or more accessories 12, ceasing operation of at least one of the one or more accessories 12, and adjusting operation of at least one of the one or more accessories 12 [See at least Bongard, 0044]);
whereby the accessory interface unit cooperates with the sensors or actuators associated with the vehicle accessory to operate the vehicle accessory in accordance with the high-level accessory-related rules (See at least Fig. 1 in Bongard: Bongard discloses that the UI module 16 output is configured for controlling operation of the one or more accessories 12, this typically involves communicating with the at least one or more accessories via the wireless communication interface 25 to cause at least one of initiating operation of at least one of the one or more accessories 12, ceasing operation of at least one of the one or more accessories 12, and adjusting operation of at least one of the one or more accessories 12 [See at least Bongard, 0044]. Bongard further discloses that the accessories include a pair of driving lights 121, a pair of air springs 122, an air compressor 123, and a locking differential 124 [See at least Bongard, 0033]. Bongard further discloses that at least some of the accessories 12 are associated with sensor apparatus 28 [See at least Bongard, 0033]).
Regarding claim 2, Bongard discloses The method of claim 1, further comprising translating the accessory-related rules to a low-level driver console configuration file for specifying the appearance of one or more GUI elements on the console providing an operator of the vehicle with one or both of control of the vehicle accessory and visibility of the status of the vehicle accessory (See at least Fig. 1 in Bongard: Bongard discloses the first memory 19 storing a respective one or more UI rules 21 governing generation of the one or more UI module outputs, and storing a copy of a shared parameter list 38 [See at least Bongard, 0030]).
Regarding claim 5, Bongard discloses The method of claim 1, further comprising generating for display a graphical user interface enabling the modification of a stored high-level accessory-related rule (See at least Fig. 1 in Bongard: Bongard discloses that the UI module 16 is configured to provide interface controls to allow a user 13 to provide input, for example, to affect operation of any of the accessories 12 associated with the vehicle 14 [See at least Bongard, 0036]).
Regarding claim 6, Bongard discloses The method of claim 1 wherein providing the lower-level accessory-related configuration to the accessory interface unit comprising transmitting the accessory-related configuration to the accessory interface unit over an external communication link to the vehicle (See at least Fig. 1 in Bongard: Bongard discloses that the UI module 16 output is configured for controlling operation of the one or more accessories 12, this typically involves communicating with the at least one or more accessories via the wireless communication interface 25 to cause at least one of initiating operation of at least one of the one or more accessories 12, ceasing operation of at least one of the one or more accessories 12, and adjusting operation of at least one of the one or more accessories 12 [See at least Bongard, 0044]. Since it is wirelessly connected to the vehicle rather than wired, this UI module may be regarded as “external” to the vehicle).
Regarding claim 7, Bongard discloses The method of claim 1 wherein the high-level accessory related rules comprise event-action rules or condition-action rules (See at least Fig. 1 in Bongard: Bongard discloses that the UI module 16 is configured to provide interface controls to allow a user 13 to provide input, for example, to affect operation of any of the accessories 12 associated with the vehicle 14 [See at least Bongard, 0036]).
Regarding claim 8, Bongard discloses The method of claim 7 wherein the high-level accessory related rules comprise condition-action rules in which the condition includes a parameter from a sensor associated with the accessory (Bongard discloses that at least some of the accessories 12 are associated with sensor apparatus 28 [See at least Bongard, 0033]. Bongard further discloses that a rule 21,23 being configured to require the presence of states 39 generated responsive to at least one vehicle input, at least one accessory input, at least one user input, and/or at least one sensor input [See at least Bongard, 0067]. Also see at least Fig. 6 in Bongard: Bongard further discloses that a third-level view 70 of the GUI displaying various settings for the air springs 122 which can be adjusted by the user operating setting tiles 72 [See at least Bongard, 0081]. Bongard further discloses that this allows the user 13 to fine-tune operating parameters for one of the operational modes [See at least Bongard, 0081]. It will be appreciated that this is responsive to sensing particular pressure values).
Regarding claim 9, Bongard discloses The method of claim 7 wherein the action comprises operating an actuator to change the state of the accessory (See at least Fig. 1 in Bongard: Bongard discloses that the UI module 16 output is configured for controlling operation of the one or more accessories 12, this typically involves communicating with the at least one or more accessories via the wireless communication interface 25 to cause at least one of initiating operation of at least one of the one or more accessories 12, ceasing operation of at least one of the one or more accessories 12, and adjusting operation of at least one of the one or more accessories 12 [See at least Bongard, 0044]. Also see at least Fig. 6 in Bongard: Bongard further discloses that a third-level view 70 of the GUI displaying various settings for the air springs 122 which can be adjusted by the user operating setting tiles 72 [See at least Bongard, 0081]. Bongard further discloses that this allows the user 13 to fine-tune operating parameters for one of the operational modes [See at least Bongard, 0081]. It will be appreciated that this is responsive to sensing particular pressure values).
Regarding claim 10, Bongard discloses The method of claim 1 further comprising simulating the operation of a vehicle equipped with the accessory, the simulation comprising generating a software model of the accessory-equipped vehicle operating in accordance with the accessory-related rules entered by the user (See at least Fig. 6 in Bongard: Bongard discloses a third-level view 70 of the GUI displaying various settings for the air springs 122 which can be adjusted by the user operating setting tiles 72 [See at least Bongard, 0081]. Bongard further discloses that operating the setting tiles 72 allows the user 13 to manually affect operating parameters for each air spring 122 to tailor vehicle 14 ride characteristics according to personal preferences [See at least Bongard, 0081]. The “simulation” is claimed so broadly that this software representation of the accessory may be regarded as a “software model of the accessory-equipped vehicle operating in accordance with the accessory-related rules entered by the user”).
Regarding claim 11, Bongard discloses The method of claim 10 further comprising:
generating for display an initial state of an accessory-equipped vehicle (See at least Fig. 6 in Bongard: Bongard discloses a third-level view 70 of the GUI displaying various settings for the air springs 122 which can be adjusted by the user operating setting tiles 72 [See at least Bongard, 0081]. The settings before adjustment by the user may be regarded as an initial state);
generating a graphical user interface allowing a user to enter user-specified events or conditions (See at least Fig. 6 in Bongard: Bongard discloses that operating the setting tiles 72 allows the user 13 to manually affect operating parameters for each air spring 122 to tailor vehicle 14 ride characteristics according to personal preferences [See at least Bongard, 0081]);
receiving user-specified events or conditions (See at least Fig. 6 in Bongard: Bongard further discloses that operating the setting tiles 72 allows the user 13 to manually affect operating parameters for each air spring 122 to tailor vehicle 14 ride characteristics according to personal preferences [See at least Bongard, 0081]);
determine a resultant state of the accessory-equipped vehicle subject to user-specified events or conditions when operating in accordance with the user-specified rules (See at least Fig. 6 in Bongard: Bongard discloses that once the user 13 has operated the setting tiles 72 and then operates the GUI to return to the air suspension tile 523 view, this causes the UI processor 17 to define at least one new state 39 in the parameter list 38 [See at least Bongard, 0081]); and
Display a resultant state of the accessory-equipped vehicle (See at least Fig. 6 in Bongard: Bongard discloses that once the user 13 has operated the setting tiles 72 and then operates the GUI to return to the air suspension tile 523 view (of Fig. 5), this causes the UI processor 17 to define at least one new state 39 in the parameter list 38 [See at least Bongard, 0081]).
Regarding claim 12, Bongard discloses A system comprising control circuitry (See at least Fig. 1 in Bongard: Bongard discloses that the system 10 is associated with a plurality of the accessories 12 installed to the vehicle 14 [See at least Bongard, 0033]) configured to:
Display a graphical user interface (See at least Fig. 1 in Bongard: Bongard discloses that the UI module 16 is configured to facilitate the interface controls by operating a graphical user interface (GUI) displayed on a haptic control arrangement [See at least Bongard, 0036])  allowing the user to specify one or more high-level accessory-related rules relating to the operation of a vehicle equipped with the accessory (See at least Fig. 1 in Bongard: Bongard disclose that the UI module 16 is configured to provide interface controls to allow a user 13 to provide input, for example, to affect operation of any of the accessories 12 associated with the vehicle 14 [See at least Bongard, 0036]);
receive user-specified high-level accessory-related rules entered by the user via the graphical user interface (See at least Fig. 1 in Bongard: Bongard discloses that the UI module 16 is configured to provide interface controls to allow a user 13 to provide input, for example, to affect operation of any of the accessories 12 associated with the vehicle 14 [See at least Bongard, 0036]); and
translate the received user-specified high-level accessory-related rules into a lower-level accessory-related configuration (See at least Fig. 1 in Bongard: Bongard discloses that the UI module 16 output is configured for controlling operation of the one or more accessories 12, this typically involves communicating with the at least one or more accessories via the wireless communication interface 25 to cause at least one of initiating operation of at least one of the one or more accessories 12, ceasing operation of at least one of the one or more accessories 12, and adjusting operation of at least one of the one or more accessories 12 [See at least Bongard, 0044]. Preparing the rules for transmission to the accessories via communication interface 25 and transmitting them may be regarded as translating them).
Regarding claim 13, Bongard discloses A system according to claim 12 in which:
the system comprises an embedded system (See at least Fig. 1 in Bongard: Bongard discloses that the UI module 16 may be further configured to receive vehicle input from electrical systems and/or sensors integrated in the vehicle 14 via the wireless communication interface 25 [See at least Bongard, 0040]. The electrical systems and/or sensors integrated in the vehicle 14 may be regarded as an embedded system), the embedded system further comprising:
a controller area network port connectable to a vehicle controller area network (See at least Fig. 1 in Bongard: Bongard discloses that where a controller area network (CAN bus) of the vehicle 14 is configured for wireless communication, such as having a Bluetooth dongle associated therewith, the UI module is configured to receive vehicle input from the CAN bus via the wireless communication interface 25 [See at least Bongard, 0040]);
one or more accessory ports connectable to electrical systems of respective accessories (See at least Fig. 1 in Bongard: Bongard discloses that the controller module 18 includes a plurality of analogue and/or digital outputs 26 [See at least Bongard, 0056]. Bongard further discloses that the outputs 26 facilitate communicating an output signal generated by the processor 20 to any of the accessories 12 [See at least Bongard, 0056]);
a processor (See at least Fig. 1 in Bongard: Bongard discloses a configurable controller module 18 associated with a second processor 20 [See at least Bongard, 0030]);
the control circuitry being further configured to (See at least Fig. 1 in Bongard: Bongard discloses the controller module 18 configured to receive inputs, and configured to generate one or more outputs to control operation of the one or more accessories 12, the second memory 22 storing a respective one or more controller rules 23 governing generation of the one or more controller module outputs, and storing a copy of the shared parameter list 38 [See at least Bongard, 0030]):
store the lower-level accessory-related configuration (See at least Fig. 1 in Bongard: Bongard discloses that each of the UI module 16 and the controller module 18 is configured such that, responsive to each input, the processor 17, 20 of the respective module 16, 18 defines a state 39 in the associated copy of the shared parameter list 38 and communicates with the other module 16, 18 to cause the state 39 to be defined in the other copy of the shared parameter list 38 [See at least Bongard, 0031]);
interpret the lower-level accessory-related configuration to generate a control signal on one of the ports in response to a sensor signal received on the accessory port, or to cause the generation of a control signal on the accessory port (See at least Fig. 2 in Bongard: Bongard discloses that at 114, the controller processor 20 determines that each state 39 required by the controller rule 23 relating to operation of the selected accessory 12 is present in the shared parameter list 382, causing the processor 20 to determine that the rule 23 is satisfied and generating an output signal at 116 [See at least Bongard, 0062]. Bongard further discloses that at 118, the selected accessory 12 receives the output signal, causing the accessory 12 to commence operation [See at least Bongard, 0062]. Also see at least Fig. 1 in Bongard: Bongard further discloses that the outputs 26 facilitate communicating an output signal generated by the processor 20 to any of the accessories 12 [See at least Bongard, 0056]) in response to a sensor signal received on one of the other ports (See at least Fig. 2 in Bongard: Bongard discloses that at 102, the user 13 operates the GUI displayed on the touch screen 34 to provide user input, by selecting instantaneous operation of the selected accessory 12 [See at least Bongard, 0060]. Bongard further discloses that this causes the processor 17 of the UI module 16, at 104, to define a state 391 in the associated copy of the shared parameter list 381 and communicate with the controller module 18 to cause the controller processor 20 to define the state 391 in its copy of the shared parameter list 382, at 106 [See at least Bongard, 0060]. It will be appreciated that all of this is a prerequisite to steps 114-118 discussed in at least [Bongard, 0062] above).
Regarding claim 14, Bongard discloses A system according to claim 13 in which the received sensor signal is indicative of a driver input on an accessory control element displayed on the driver console (See at least Fig. 2 in Bongard: Bongard discloses that at 102, the user 13 operates the GUI displayed on the touch screen 34 to provide user input, by selecting instantaneous operation of the selected accessory 12 [See at least Bongard, 0060]. Bongard further discloses that this causes the processor 17 of the UI module 16, at 104, to define a state 391 in the associated copy of the shared parameter list 381 and communicate with the controller module 18 to cause the controller processor 20 to define the state 391 in its copy of the shared parameter list 382, at 106 [See at least Bongard, 0060]. It will be appreciated that all of this is a prerequisite to steps 114-118 discussed in at least [Bongard, 0062] above).
Regarding claim 15, Bongard discloses A system according to claim 13 in which the output control signal controls the output of an accessory state display element on the driver console (See at least Fig. 6 in Bongard: Bongard discloses that once the user 13 has operated the setting tiles 72 and then operates the GUI to return to the air suspension tile 523 view (of Fig. 5), this causes the UI processor 17 to define at least one new state 39 in the parameter list 38 [See at least Bongard, 0081]).
Regarding claim 16, Bongard discloses A computer-readable medium tangibly embodying instructions executable by a processor (See at least Fig. 1 in Bongard: Bongard discloses the processor 17, 20 of the respective module 16, 18 assesses the, or each, associated rule 21, 23 to determine if the, or each, required state 39 is present in the shared parameter list 38, and, responsive to determining the, or each, required state is present, the processor 17, 20 of the module 16, 20 effects generation of the associated output [See at least Bongard, 0032]) to:
Display a graphical user interface (See at least Fig. 1 in Bongard: Bongard discloses that the UI module 16 is configured to facilitate the interface controls by operating a graphical user interface (GUI) displayed on a haptic control arrangement [See at least Bongard, 0036])  allowing the user to specify one or more high- level accessory-related rules relating to the operation of a vehicle equipped with the accessory (See at least Fig. 1 in Bongard: Bongard disclose that the UI module 16 is configured to provide interface controls to allow a user 13 to provide input, for example, to affect operation of any of the accessories 12 associated with the vehicle 14 [See at least Bongard, 0036]);
receive user-specified high-level accessory-related rules entered by the user via the graphical user interface (See at least Fig. 1 in Bongard: Bongard discloses that the UI module 16 is configured to provide interface controls to allow a user 13 to provide input, for example, to affect operation of any of the accessories 12 associated with the vehicle 14 [See at least Bongard, 0036]);
translate the user-specified rules into a lower-level accessory-related configuration readable by an accessory interface unit adapted for communication with (See at least Fig. 1 in Bongard: Bongard discloses that the UI module 16 output is configured for controlling operation of the one or more accessories 12, this typically involves communicating with the at least one or more accessories via the wireless communication interface 25 to cause at least one of initiating operation of at least one of the one or more accessories 12, ceasing operation of at least one of the one or more accessories 12, and adjusting operation of at least one of the one or more accessories 12 [See at least Bongard, 0044]. Preparing the rules for transmission to the accessories via communication interface 25 and transmitting them may be regarded as translating them) sensors or actuators associated with the vehicle accessory (See at least Fig. 1 in Bongard: Bongard discloses that the accessories include a pair of driving lights 121, a pair of air springs 122, an air compressor 123, and a locking differential 124 [See at least Bongard, 0033]. Bongard further discloses that at least some of the accessories 12 are associated with sensor apparatus 28 [See at least Bongard, 0033]);
provide the lower-level accessory-related configuration to the accessory interface unit (See at least Fig. 1 in Bongard: Bongard discloses that the UI module 16 output is configured for controlling operation of the one or more accessories 12, this typically involves communicating with the at least one or more accessories via the wireless communication interface 25 to cause at least one of initiating operation of at least one of the one or more accessories 12, ceasing operation of at least one of the one or more accessories 12, and adjusting operation of at least one of the one or more accessories 12 [See at least Bongard, 0044]);
whereby the accessory interface unit cooperates with the sensors or actuators associated with the vehicle accessory to operate the vehicle accessory in accordance with the high-level accessory-related rules (See at least Fig. 1 in Bongard: Bongard discloses that the UI module 16 output is configured for controlling operation of the one or more accessories 12, this typically involves communicating with the at least one or more accessories via the wireless communication interface 25 to cause at least one of initiating operation of at least one of the one or more accessories 12, ceasing operation of at least one of the one or more accessories 12, and adjusting operation of at least one of the one or more accessories 12 [See at least Bongard, 0044]. Bongard further discloses that the accessories include a pair of driving lights 121, a pair of air springs 122, an air compressor 123, and a locking differential 124 [See at least Bongard, 0033]. Bongard further discloses that at least some of the accessories 12 are associated with sensor apparatus 28 [See at least Bongard, 0033]).
Regarding claim 17, Bongard discloses A vehicle comprising a system (See at least Fig. 1 in Bongard: Bongard discloses a system 10 for controlling operation of one or more accessories 12 for a vehicle 14 [See at least Bongard, 0030]) according to claim 12 (See at least the prior art rejection of claim 12 above).
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 3 is rejected under 35 U.S.C. 103 as being unpatentable over Bongard et al. (US 20200369148 A1) in view of Uthaicharoenpong et al. (US 20200231168 A1), hereinafter referred to as Uthaicharoenpong.
Regarding claim 3, Bongard discloses The method of claim 1.
However, Bongard does not explicitly teach the method further comprising storing the high-level accessory- related rules in persistent storage accessible to users tasked with configuring other vehicles with the accessory.
However, Uthaicharoenpong does teach a vehicle control method further comprising storing the high-level accessory- related rules in persistent storage accessible to users tasked with configuring other vehicles with the accessory (See at least Fig. 7 in Uthaicharoenpong: Uthaicharoenpong teaches that process 700 begins by obtaining, using an interface controller, configuration data for a host vehicle from a plurality of configuration data for different host vehicles (701) [See a least Uthaicharoenpong, 0128]. Uthaicharoenpong further teaches that configuration data can be retrieved from a storage device on the interface board (e.g., flash memory), from cache memory in the interface controller 422 or from computer system 300 [See a least Uthaicharoenpong, 0128]. Uthaicharoenpong further teaches that, for example, in an embodiment computer system 300 queries cloud data center 204a for configuration data by sending a query to the cloud data center 204a that includes HV identifying information [See a least Uthaicharoenpong, 0128]. Uthaicharoenpong further teaches that a driver may select a host vehicle using a GUI [See at least Uthaicharoenpong, 0005]). Both Uthaicharoenpong and Bongard teach methods for configuring vehicles. However, only Uthaicharoenpong explicitly teaches where a number of vehicles may be connected to a computer system in order share and exchange driving parameter data.
It would have been obvious to anyone of ordinary skill in the art prior to the effective filing date of the claimed invention to modify the vehicle operation method of Bongard to also connect a number of vehicles to a computer system in order share and exchange driving parameter data, as in Uthaicharoenpong. Doing so improves driving of the vehicles by sharing valuable data for this purpose.
Claims 4 is rejected under 35 U.S.C. 103 as being unpatentable over Bongard et al. (US 20200369148 A1) in view of Uthaicharoenpong et al. (US 20200231168 A1) in further view of Kim et al. (US 20200216087 A1), hereinafter referred to as Kim.
Regarding claim 4, Bongard in view of Uthaicharoenpong teaches The method of claim 3, further comprising:
retrieving one or more high-level accessory-related rules from the persistent storage (See at least Fig. 7 in Uthaicharoenpong: Uthaicharoenpong teaches that process 700 begins by obtaining, using an interface controller, configuration data for a host vehicle from a plurality of configuration data for different host vehicles (701) [See a least Uthaicharoenpong, 0128]).
However, Bongard does not explicitly teach the method further comprising generating a graphical user interface for editing the accessory-related rules;
receiving user edits of the retrieved accessory-related rules;
storing the edited accessory-related rules in the persistent storage accessible to users tasked with configuring other vehicles with the accessory.
However, Kim does teach a method for controlling vehicle operations using a user interface further comprising generating a graphical user interface for editing the accessory-related rules (See at least Fig. 1 in Kim: Kim teaches that the driver performs the change and the setting for a parameter value from the user terminal 150, but it is possible that, without using the user terminal 150, the change and the setting are performed by inputting a parameter value directly into the controller 110 of the vehicle through an input unit of the interface unit 120, referring to the display screen of the interface unit 120 (the screen for the setting mode) [See at least Kim, 0050]. Also see at least Figs. 5-6 in Kim: Kim teaches that the modifications are made on an existing value of a parameter at S21-S22 [See at least Kim, 0212-0213]);
receiving user edits of the retrieved accessory-related rules (See at least Fig. 1 in Kim: Kim teaches that the controller 110 performs control in such a manner that parameter values that result from the driver performing the change and the setting using the user terminal 150 or the interface unit 120 are applied to the control logic for the vehicle traveling control [See at least Kim, 0051]);
storing the edited accessory-related rules in the persistent storage accessible to users tasked with configuring other vehicles with the accessory (See at least Fig. 1 in Kim: Kim teaches that a setting value of every parameter is collected, and data (that is, the drivability data) that results from the collection is transmitted, on request, to the user terminal 150 or the external server 160 [See at least Kim, 0052]. Kim further teaches that data that contain a parameter value that is determined as a default value, that is, a default value that is determined for every parameter, as well as a parameter value that results from previously performing the change and the setting is transmitted, on request, to the user terminal 150 and the external server 160 [See at least Kim, 0054]. Kim further teaches that the user terminal 150 to which the controller 110, as described above, transmits the data on request may be a terminal on which the setting is previously performed for a parameter value, or may be a terminal of another driver [See at least Kim, 0053]). Both Kim and Bongard in view of Uthaicharoenpong teach methods of modifying vehicle operations using GUIs and data gathered from other vehicles. However, only Kim explicitly teaches where the changes made by the user may be transmitted back to the remote device from which the previous parameter values are obtained, so that the new values can be accessed by other users.
It would have been obvious to anyone of ordinary skill in the art prior to the effective filing date of the claimed invention to modify the parameter setting and sharing method of Bongard in view of Uthaicharoenpong to also cause the changes made by the user to be transmitted back to the remote device from which the previous parameter values are obtained, so that the new values can be accessed by other users, as in Kim. Doing so improves vehicle operation by allowing users to share preferred operating parameters with each other.
Conclusion


NEXT OFFICE ACTION: 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 .
Prosecution History
Claims 1-17 of US application 17/948,031 filed 9/19/22 were examined. Examiner filed a non-final rejection on 9/30/24.
Applicant filed remarks and amendments on 2/27/25. Claims 1-10 and 12-16 were amended. Claim 11 was cancelled. Claims 1-10 and 12-17 are presently pending and presented for examination.
Reasons for Allowance
Claims 1-10 and 12-17 are allowed over the prior art of record.
The closest prior art of record is Bongard et al. (US 20200369148 A1) in view of Oh (US 20220036758 A1) in further view of Chan et al. (US 20230059562 A1), hereinafter referred to as Bongard, Oh and Chan, respectively. The following is an examiner’s statement of reasons for allowance:
Regarding claims 1, 12 and 16, Bongard discloses A method of configuring a vehicle to integrate an accessory (See at least Fig. 1 in Bongard: Bongard discloses that the system 10 is associated with a plurality of the accessories 12 installed to the vehicle 14 [See at least Bongard, 0033])  comprising:
generating, for display on a touchscreen, an initial state of an accessory-equipped vehicle, wherein the initial state includes default values of operational parameters of vehicle and accessory components and sub-systems (See at least Fig. 5 in Bongard: Bongard discloses current values of certain operational parameters of the vehicle, which may be regarded as default values [See at least Bongard, 0079]);
generating a graphical user interface, on the touchscreen, allowing a user to specify a test configuration (See at least Fig. 1 in Bongard: Bongard discloses that the UI module 16 is configured to provide interface controls to allow a user 13 to provide input, for example, to affect operation of any of the accessories 12 associated with the vehicle 14 [See at least Bongard, 0036]) comprising:
a user-specified high-level accessory-related rule relating to the operation of the accessory-equipped vehicle (See at least Fig. 1 in Bongard: Bongard discloses that the UI module 16 is configured to provide interface controls to allow a user 13 to provide input, for example, to affect operation of any of the accessories 12 associated with the vehicle 14 [See at least Bongard, 0036]); and
an operational parameter setting a state of the vehicle and accessory components and sub-systems (See at least Fig. 1 in Bongard: Bongard discloses that the UI module 16 output is configured for controlling operation of the one or more accessories 12, this typically involves communicating with the at least one or more accessories via the wireless communication interface 25 to cause at least one of initiating operation of at least one of the one or more accessories 12, ceasing operation of at least one of the one or more accessories 12, and adjusting operation of at least one of the one or more accessories 12 [See at least Bongard, 0044]);
receiving the user-specified high-level accessory-related rule at the accessory-equipped vehicle (See at least Fig. 1 in Bongard: Bongard discloses that the UI module 16 is configured to provide interface controls to allow a user 13 to provide input, for example, to affect operation of any of the accessories 12 associated with the vehicle 14 [See at least Bongard, 0036]);
translating the received user-specified high-level accessory-related rule into a lower- level accessory-related configuration readable by an accessory interface unit having one or more communication ports adapted for communication (See at least Fig. 1 in Bongard: Bongard discloses that the UI module 16 output is configured for controlling operation of the one or more accessories 12, this typically involves communicating with the at least one or more accessories via the wireless communication interface 25 to cause at least one of initiating operation of at least one of the one or more accessories 12, ceasing operation of at least one of the one or more accessories 12, and adjusting operation of at least one of the one or more accessories 12 [See at least Bongard, 0044]. Preparing the rules for transmission to the accessories via communication interface 25 and transmitting them may be regarded as translating them) with sensors or actuators associated with the accessory (See at least Fig. 1 in Bongard: Bongard discloses that the accessories include a pair of driving lights 121, a pair of air springs 122, an air compressor 123, and a locking differential 124 [See at least Bongard, 0033]. Bongard further discloses that at least some of the accessories 12 are associated with sensor apparatus 28 [See at least Bongard, 0033]); and
providing the lower-level accessory-related configuration to the accessory interface unit (See at least Fig. 1 in Bongard: Bongard discloses that the UI module 16 output is configured for controlling operation of the one or more accessories 12, this typically involves communicating with the at least one or more accessories via the wireless communication interface 25 to cause at least one of initiating operation of at least one of the one or more accessories 12, ceasing operation of at least one of the one or more accessories 12, and adjusting operation of at least one of the one or more accessories 12 [See at least Bongard, 0044]);
whereby the accessory interface unit cooperates with the sensors or actuators associated with the accessory to operate the accessory in accordance with the received user- specified high-level accessory-related rule (See at least Fig. 1 in Bongard: Bongard discloses that the UI module 16 output is configured for controlling operation of the one or more accessories 12, this typically involves communicating with the at least one or more accessories via the wireless communication interface 25 to cause at least one of initiating operation of at least one of the one or more accessories 12, ceasing operation of at least one of the one or more accessories 12, and adjusting operation of at least one of the one or more accessories 12 [See at least Bongard, 0044]. Bongard further discloses that the accessories include a pair of driving lights 121, a pair of air springs 122, an air compressor 123, and a locking differential 124 [See at least Bongard, 0033]. Bongard further discloses that at least some of the accessories 12 are associated with sensor apparatus 28 [See at least Bongard, 0033]).
Oh teaches wherein the initial state includes default values of environmental variables (Oh teaches that the test-driving experience service providing server may execute the vehicle test-driving virtual experience mode to provide a virtual driving environment setting interface by which at least one of a virtual driving parameter and a scenario for setting an environment of the virtual driving on the basis of the vehicle description application is set [See at least Oh, 0023]), wherein the test configuration inputted via a touchscreen further comprises a simulated event (Oh teaches that the test-driving experience service providing server may execute the vehicle test-driving virtual experience mode to provide a virtual driving environment setting interface by which at least one of a virtual driving parameter and a scenario for setting an environment of the virtual driving on the basis of the vehicle description application is set [See at least Oh, 0023]. The virtual driving may be regarded as a simulated event); and
an environmental variable describing an environment in which the vehicle is operating (Oh teaches that the test-driving experience service providing server may execute the vehicle test-driving virtual experience mode to provide a virtual driving environment setting interface by which at least one of a virtual driving parameter and a scenario for setting an environment of the virtual driving on the basis of the vehicle description application is set [See at least Oh, 0023]),
wherein the method further comprises simulating a resultant state of the accessory-equipped vehicle when operating under the control of the test configuration (Oh teaches that the test-driving experience service providing server may provide a test-driving virtual experience scenario image which is an augmented reality image providing the virtual driving experience environment on the basis of at least one of the set virtual driving parameter and scenario [See at least Oh, 0024]); and
displaying, on the touchscreen, the resultant state of the accessory-equipped vehicle (when the test-driving virtual experience scenario image is output, the test-driving experience service providing server may include event content related to a second vehicle function in the test-driving virtual experience scenario image and output the test-driving virtual experience scenario image).
However, none of the prior art of record, taken either alone or in combination, teaches or suggests where the vehicle’s resultant state after the simulation as per the user-specified test configuration is displayed before loading the test configuration into the accessory-equipped vehicle.
While Bongard does deal with integration an accessory, as discussed above, the changes made via the user interface do not involve simulating operation of a vehicle in an environment and they also immediately take effect in the vehicle, rather than displaying results of such a simulation first (See at least Fig. 1 in Bongard: Bongard discloses that the UI module 16 output is configured for controlling operation of the one or more accessories 12, this typically involves communicating with the at least one or more accessories via the wireless communication interface 25 to cause at least one of initiating operation of at least one of the one or more accessories 12, ceasing operation of at least one of the one or more accessories 12, and adjusting operation of at least one of the one or more accessories 12 [See at least Bongard, 0044]. There is no suggestion here that the state of any accessory is displayed to the user before the changes it implements take effect, nor is there any simulation of a vehicle in an environment).
Conversely, Oh does discuss simulation of driving of a vehicle using user-specified parameters as discussed above without loading any test information into an actual vehicle (See at least [Oh, 0023]). Oh further teaches displaying the results of the simulation (See at least [Oh, 0024]). However, Oh is silent as to whether or not the displaying of the results occurs before, during, or after any step of loading the test configuration into the vehicle, since Oh does not teach loading data into a real physical vehicle at all post-simulation.
Chan does not address the deficiencies of Bongard or Oh. Chan does teach a typical vehicle simulation system in the prior art whereby there is communication between the simulation system and the vehicle (See at least [Chan, 0056]). However, Chan is silent as to whether test configuration information is transferred to the vehicle before, during, or after any step of displaying simulation results to the user (See at least [Chan, 0096]). Chan also suggests that the simulation system may even be present onboard the vehicle, which would of course not be conducive to avoiding loading the test configuration information into the vehicle only after displaying it (See at least [Chan, 0056]).
In other words, the specific order of operations of a user entering in an accessory-related test configuration via a touch screen, followed by displaying the resultant state of the simulation using that test configuration to the user before ever loading the test configuration information into the particular accessory-equipped vehicle is not taught by the prior art of record.
For at least the above stated reasons, claims 1, 12 and 16 are allowed over the prior art of record.
Regarding claims 2-10, these claims are allowed at least by virtue of their dependence on claim 1.
Regarding claims 13-15 and 17, these claims are allowed at least by virtue of their dependence on claim 12.
Any comments considered necessary by applicant must be submitted no later than the payment of the issue fee and, to avoid processing delays, should preferably accompany the issue fee.  Such submissions should be clearly labeled “Comments on Statement of Reasons for Allowance.”
Conclusion

CITED REFERENCE SUMMARIES: Ref US20190202380A1: Claims:
A method for efficient power management of a finite power storage unit that provides a finite amount of power to a vehicle accessory, the method comprising: receiving an input parameter, wherein the input parameter includes one of a desired runtime for the vehicle accessory and a desired condition setting for the vehicle accessory; receiving an environment data; a processor determining an output parameter based on the input parameter and the environment data, wherein the output parameter includes one of an acceptable condition setting for the vehicle accessory and a predicted runtime for the vehicle accessory; providing the output parameter to a display for displaying the output parameter; and the processor controlling operation of the vehicle accessory based on the output parameter.
receiving an input parameter, wherein the input parameter includes one of a desired runtime for the vehicle accessory and a desired condition setting for the vehicle accessory;
receiving an environment data;
a processor determining an output parameter based on the input parameter and the environment data, wherein the output parameter includes one of an acceptable condition setting for the vehicle accessory and a predicted runtime for the vehicle accessory;
providing the output parameter to a display for displaying the output parameter; and
the processor controlling operation of the vehicle accessory based on the output parameter.
The method of claim 1 , wherein when the input parameter is the desired condition setting for the vehicle accessory, the output parameter is the predicted runtime for the vehicle accessory to achieve the desired condition setting, and wherein when the input parameter is the desired runtime of the vehicle accessory, the output parameter is the acceptable condition setting for the vehicle accessory to achieve the desired runtime.
wherein when the input parameter is the desired runtime of the vehicle accessory, the output parameter is the acceptable condition setting for the vehicle accessory to achieve the desired runtime.
The method of claim 1 , wherein the vehicle accessory includes a heating, ventilation, air conditioning or refrigeration (HVACR) system and the finite power storage unit is an auxiliary power unit (APU).
The method of claim 1 , wherein the vehicle accessory includes a transport refrigeration unit.
The method of claim 1 , wherein receiving the environment data includes receiving weather data from a server.
The method of claim 5 , wherein the weather data includes a solar load forecast.
The method of claim 1 , wherein the finite power storage unit includes one or more batteries, and wherein the environment data includes a state of charge of each of the one or more batteries.
wherein the environment data includes a state of charge of each of the one or more batteries.
The method of claim 7 , wherein determining the state of charge of each of the one or more batteries includes: connecting one of the one or more batteries to a load; measuring a current draw and a voltage drop across the one of the one or more batteries; and determining the state of charge of the one of the one or more batteries based on the current draw and the voltage drop across the one of the one or more batteries.
connecting one of the one or more batteries to a load;
measuring a current draw and a voltage drop across the one of the one or more batteries; and
determining the state of charge of the one of the one or more batteries based on the current draw and the voltage drop across the one of the one or more batteries.
The method of claim 7 , wherein determining the state of charge of the one or more batteries includes: measuring a voltage of each of the one or more batteries; engaging at least one of the one or more batteries with a load; measuring a current draw and a voltage drop across the at least one of the one or more batteries; disengaging the at least one of the one or more batteries from the load; measuring a open circuit voltage of the at least one of the one or more batteries; and determining the state of charge of the at least one of the one or more batteries based on the open circuit voltage of the at least one of the one or more batteries.
measuring a voltage of each of the one or more batteries;
engaging at least one of the one or more batteries with a load;
measuring a current draw and a voltage drop across the at least one of the one or more batteries;
disengaging the at least one of the one or more batteries from the load;
measuring a open circuit voltage of the at least one of the one or more batteries; and
determining the state of charge of the at least one of the one or more batteries based on the open circuit voltage of the at least one of the one or more batteries.
The method of claim 1 , further comprising: storing the output parameter in a memory; updating the environment data; determining an updated output parameter using the updated environment data; determining a deviation of the updated output parameter from a stored value of the output parameter that is stored in the memory; and providing an alert regarding a change to the output parameter.
storing the output parameter in a memory;
updating the environment data;
determining an updated output parameter using the updated environment data;
determining a deviation of the updated output parameter from a stored value of the output parameter that is stored in the memory; and
providing an alert regarding a change to the output parameter.
The method of claim 1 , wherein determining the output parameter includes: entering the environment data into a model correlating vehicle accessory condition setting and runtime; entering the input parameter into the model correlating vehicle accessory condition setting and runtime; and determining the output parameter based on the model correlating vehicle accessory condition setting and runtime.
entering the environment data into a model correlating vehicle accessory condition setting and runtime;
entering the input parameter into the model correlating vehicle accessory condition setting and runtime; and
determining the output parameter based on the model correlating vehicle accessory condition setting and runtime.
A finite power storage unit and vehicle accessory system, comprising: a vehicle accessory; a finite power storage unit that provides a finite amount of power to the vehicle accessory; an input device that receives an input parameter, wherein the input parameter includes one of a desired runtime for the vehicle accessory and a desired condition setting for the vehicle accessory; and a processor that: receives an environment data, determines an output parameter based on the input parameter and the environment data, and controls operation of the vehicle accessory based on the output parameter, wherein the output parameter includes one of an acceptable condition setting for the vehicle accessory and a predicted runtime for the vehicle accessor, and wherein the processor provides the output parameter to a display for displaying the output parameter.
a vehicle accessory;
a finite power storage unit that provides a finite amount of power to the vehicle accessory;
an input device that receives an input parameter, wherein the input parameter includes one of a desired runtime for the vehicle accessory and a desired condition setting for the vehicle accessory; and
a processor that: receives an environment data, determines an output parameter based on the input parameter and the environment data, and controls operation of the vehicle accessory based on the output parameter,
receives an environment data,
determines an output parameter based on the input parameter and the environment data, and
controls operation of the vehicle accessory based on the output parameter,
wherein the output parameter includes one of an acceptable condition setting for the vehicle accessory and a predicted runtime for the vehicle accessor, and
wherein the processor provides the output parameter to a display for displaying the output parameter.
The vehicle accessory and power source system of claim 12 , further comprising a communications link for receiving environment data.
The vehicle accessory and power source system of claim 12 , wherein the vehicle accessory includes a heating, ventilation, air conditioning or refrigeration (HVACR) system and the finite power storage unit is an auxiliary power unit.
The vehicle accessory and power source system of claim 12 , wherein the vehicle accessory includes a transport refrigeration unit.
The vehicle accessory and power source system of claim 12 , wherein when the input parameter is the desired condition setting for the vehicle accessory, the output parameter determined by the processor is the predicted runtime for the vehicle accessory to achieve the desired condition setting, and wherein when the input parameter is the desired runtime for the vehicle accessory, the output parameter determined by the processor is the acceptable condition setting for the vehicle accessory to achieve the desired runtime.
wherein when the input parameter is the desired runtime for the vehicle accessory, the output parameter determined by the processor is the acceptable condition setting for the vehicle accessory to achieve the desired runtime.
The vehicle accessory and power system of claim 12 , further comprising: a memory storing a model associating a vehicle accessory condition setting with a system runtime based on the input parameter and the environment data, wherein the processor determines the output parameter based on the input parameter, the environment data and the model.
a memory storing a model associating a vehicle accessory condition setting with a system runtime based on the input parameter and the environment data,
wherein the processor determines the output parameter based on the input parameter, the environment data and the model.
A user interface for a vehicle accessory powered by a finite power storage unit, comprising: a condition setting display showing a condition setting of the vehicle accessory; a condition setting control allowing a user to input a desired condition setting of the vehicle accessory; a runtime display showing a runtime of the vehicle accessory when powered by the finite power storage unit; and a runtime control allowing the user to input a desired runtime for the vehicle accessory, wherein, when the user inputs the desired condition setting of the vehicle accessory on the condition setting control, the runtime display is automatically updated based on the desired condition setting to display a predicted runtime of the vehicle accessory to achieve the desired condition setting of the vehicle accessory, and wherein, when the user inputs the desired runtime of the vehicle accessory on the runtime control, the condition setting display is automatically updated based on the desired runtime to display an acceptable condition setting of the vehicle accessory to achieve the desired runtime of the vehicle accessory.
a condition setting display showing a condition setting of the vehicle accessory;
a condition setting control allowing a user to input a desired condition setting of the vehicle accessory;
a runtime display showing a runtime of the vehicle accessory when powered by the finite power storage unit; and
a runtime control allowing the user to input a desired runtime for the vehicle accessory,
wherein, when the user inputs the desired condition setting of the vehicle accessory on the condition setting control, the runtime display is automatically updated based on the desired condition setting to display a predicted runtime of the vehicle accessory to achieve the desired condition setting of the vehicle accessory, and
wherein, when the user inputs the desired runtime of the vehicle accessory on the runtime control, the condition setting display is automatically updated based on the desired runtime to display an acceptable condition setting of the vehicle accessory to achieve the desired runtime of the vehicle accessory.
The user interface of claim 18 , further comprising an operating mode selection allowing selection of an operating mode for the vehicle accessory.
The user interface of claim 18 , further comprising: an additional vehicle accessories display that displays a list of one or more additional vehicle accessories on the finite power storage unit; and an additional vehicle accessories control allowing the user to input one or more desired additional vehicle accessories for operation, wherein, when the user inputs one or more desired additional vehicle accessory accessories for operation, at least one of: the condition setting display is automatically updated based on the inputted one or more desired additional vehicle accessories for operation and the desired runtime to display an acceptable condition setting of the vehicle accessory, and the runtime display is automatically updated based on the inputted one or more desired additional vehicle accessories for operation and the desired condition setting to display the predicted runtime of the vehicle accessory.
an additional vehicle accessories display that displays a list of one or more additional vehicle accessories on the finite power storage unit; and
an additional vehicle accessories control allowing the user to input one or more desired additional vehicle accessories for operation,
wherein, when the user inputs one or more desired additional vehicle accessory accessories for operation, at least one of: the condition setting display is automatically updated based on the inputted one or more desired additional vehicle accessories for operation and the desired runtime to display an acceptable condition setting of the vehicle accessory, and the runtime display is automatically updated based on the inputted one or more desired additional vehicle accessories for operation and the desired condition setting to display the predicted runtime of the vehicle accessory.
the condition setting display is automatically updated based on the inputted one or more desired additional vehicle accessories for operation and the desired runtime to display an acceptable condition setting of the vehicle accessory, and
the runtime display is automatically updated based on the inputted one or more desired additional vehicle accessories for operation and the desired condition setting to display the predicted runtime of the vehicle accessory.
Ref US20190118653A1: Claims:
- 10 . (canceled)
A device for controlling an interior lighting system of a vehicle, wherein the interior lighting system has an array of a plurality of light sources to produce internal lighting and/or reading lighting, the device comprising: a control unit configured to individually control the plurality of light sources of the array to produce the internal lighting and/or the reading lighting; and an input unit connected to the control unit, wherein the input unit has a touch-sensitive screen configured for input of a current set of control information for the control unit, wherein the control unit is configured to control the plurality of light sources on the basis of the current set of control information, and wherein the input unit is configured to display, on the basis of the current set of control information, associated internal lighting and/or reading lighting for an illuminable region in the vehicle interior on the screen.
a control unit configured to individually control the plurality of light sources of the array to produce the internal lighting and/or the reading lighting; and
an input unit connected to the control unit, wherein the input unit has a touch-sensitive screen configured for input of a current set of control information for the control unit,
wherein the control unit is configured to control the plurality of light sources on the basis of the current set of control information, and
wherein the input unit is configured to display, on the basis of the current set of control information, associated internal lighting and/or reading lighting for an illuminable region in the vehicle interior on the screen.
The device of claim 11 , further comprising: a first input element on the touch-sensitive screen configured to confirm the current set of control information, wherein the control unit is configured to implement internal lighting and/or reading lighting in the vehicle interior corresponding to the current set of control information by controlling the plurality of light sources correspondingly, only after selection of the first input element to confirm the current set of control information.
a first input element on the touch-sensitive screen configured to confirm the current set of control information,
wherein the control unit is configured to implement internal lighting and/or reading lighting in the vehicle interior corresponding to the current set of control information by controlling the plurality of light sources correspondingly, only after selection of the first input element to confirm the current set of control information.
The device of claim 11 , wherein the control unit is configured to implement, during the input of a current set of control information into the input unit, internal lighting and/or reading lighting associated with the current set of control information in the vehicle interior in real time by controlling the plurality of light sources correspondingly.
The device of claim 11 , wherein a set of control information comprises at least one of: a color temperature, a value of luminous flux for setting a brightness of the internal lighting and/or the reading lighting, an illumination region of the reading lighting in the vehicle interior, a lighting scenario for the internal lighting, a lighting scenario for the reading lighting, a start time and/or an end time or a period of time for the activation of the internal lighting and/or the reading lighting by the control unit, a time course of the color temperature, a time course of the value of the luminous flux for the brightness, a time course of an arrangement, shape, and/or size of the illumination region of the reading lighting in the vehicle interior, a temporally variable lighting scenario for the internal lighting, and a temporally variable lighting scenario for the reading lighting.
a color temperature,
a value of luminous flux for setting a brightness of the internal lighting and/or the reading lighting,
an illumination region of the reading lighting in the vehicle interior,
a lighting scenario for the internal lighting,
a lighting scenario for the reading lighting,
a start time and/or an end time or a period of time for the activation of the internal lighting and/or the reading lighting by the control unit,
a time course of the color temperature,
a time course of the value of the luminous flux for the brightness,
a time course of an arrangement, shape, and/or size of the illumination region of the reading lighting in the vehicle interior,
a temporally variable lighting scenario for the internal lighting, and
a temporally variable lighting scenario for the reading lighting.
The device of claim 12 , wherein the input unit having the touch-sensitive screen is configured to allow a user to select a state from predetermined states of the vehicle and/or a state from predetermined states of a surrounding region of the vehicle, and can associate the state(s) with the current set of control information, the device further comprises a memory unit configured to save the current set of control information and the selected state of the vehicle and/or the selected state of the surrounding region of the vehicle, the touch-sensitive screen further comprises a second input element configured to initiate saving the current set of control information and the associated state of the vehicle and/or of the surrounding region of the vehicle in the memory unit.
the input unit havin
[Truncated to input limit]