DETAILED ACTION
This non-final action is in reply to the application filed 30 June 2025.
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 .
Priority
Claims 1-20 are pending, having a filing date of 30 June 2025, and claiming foreign priority to Korean Patent Application Number KR10-2024-0154298, filed 4 November 2024.
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Drawings
The drawings filed 30 June 2025, are accepted by the examiner.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In January, 2019 (updated October 2019), the USPTO released new examination guidelines setting forth a two-step inquiry for determining whether a claim is directed to non-statutory subject matter. According to the guidelines, a claim is directed to non-statutory subject matter if:
• STEP 1: the claim does not fall within one of the four statutory categories of invention (process, machine, manufacture or composition of matter), or
• STEP 2: the claim recites a judicial exception, e.g. an abstract idea, without reciting additional elements that amount to significantly more than the judicial exception, as determined using the following analysis:
o STEP 2A (PRONG 1): Does the claim recite an abstract idea, law of nature, or natural phenomenon?
o STEP 2A (PRONG 2): Does the claim recite additional elements that integrate the judicial exception into a practical application?
o STEP 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
Using the two-step inquiry, it is clear that claim 1 is directed toward non-statutory subject matter as shown below.
STEP 1: Do claims 1, 11 and 19 fall within one of the statutory categories? Yes, because claim 1 is directed toward a process, claim 11 is directed toward a system, and claim 19 is directed toward an apparatus, all of which fall within one of the statutory categories.
STEP 2A (PRONG 1): Are the claims directed to a law of nature, a natural phenomenon or an abstract idea? Yes, claims 1, 11 and 19 are directed to an abstract ideas.
With regard to STEP 2A (PRONG 1), the guidelines provide three groupings of subject matter that are considered abstract ideas:
1. Mathematical concepts – mathematical relationships, mathematical formulas or equations, mathematical calculations;
2. Certain methods of organizing human activity – fundamental economic principles or practices (including hedging, insurance, mitigating risk); commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations); managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions); and
3. Mental processes – concepts that are practicably performed in the human mind (including an observation, evaluation, judgment, opinion).
As per claim 1, 11 and 19, the system is a mental process that can be performed in the mind and, therefore, an abstract idea. In particular, claim 1 recites the abstract ideas of:
“determining whether a data processing request has been received from a remote computing device via a wireless communication” (claim 1);
“check whether a data processing request has been received from the remote computing device” (claim 11, similar to the previous additional element);and
“determining whether to perform the data processing request” (claim 1, 11 and 19) ... .
These recitations merely consist of determining or checking whether a data processing request has been received and determining whether to perform the data processing request. This is equivalent to a person determining or observing whether a data request has been received, and determining or observing whether the processing request has been performed. The Examiner notes that under MPEP 2106.04(a)(2)(III), the courts consider a mental process (thinking) that "can be performed in the human mind, or by a human using a pen and paper" to be an abstract idea. CyberSource Corp. v. Retail Decisions, Inc., 654 F.3d 1366, 1372, 99 USPQ2d 1690, 1695 (Fed. Cir. 2011). As the Federal Circuit explained, "methods which can be performed mentally, or which are the equivalent of human mental work, are unpatentable abstract ideas the ‘basic tools of scientific and technological work’ that are open to all.’" 654 F.3d at 1371, 99 USPQ2d at 1694 (citing Gottschalk v. Benson, 409 U.S. 63, 175 USPQ 673 (1972)). See also Mayo Collaborative Servs. v. Prometheus Labs. Inc., 566 U.S. 66, 71, 101 USPQ2d 1961, 1965 ("‘[M]ental processes[] and abstract intellectual concepts are not patentable, as they are the basic tools of scientific and technological work’" (quoting Benson, 409 U.S. at 67, 175 USPQ at 675)); Parker v. Flook, 437 U.S. 584, 589, 198 USPQ 193, 197 (1978) (same). As such, a person, determines or observes whether a data request has been received, and determines or observes whether the processing request has been performed. The mere nominal recitations that the steps are enabled by “the data communications circuit,” (claim 11) and “the processor” (claim 19) does not take the limitations out of the mental process grouping.
STEP 2A (PRONG 2): Does the claim recite additional elements that integrate the judicial exception into a practical application? No, the claim does not recite additional elements that integrate the judicial exception into a practical application.
With regard to STEP 2A (prong 2), whether the claim recites additional elements that integrate the judicial exception into a practical application, the guidelines provide the following exemplary considerations that are indicative that an additional element (or combination of elements) may have integrated the judicial exception into a practical application:
• an additional element reflects an improvement in the functioning of a computer, or an improvement to other technology or technical field;
• an additional element that applies or uses a judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition;
• an additional element implements a judicial exception with, or uses a judicial exception in conjunction with, a particular machine or manufacture that is integral to the claim;
• an additional element effects a transformation or reduction of a particular article to a different state or thing; and
• an additional element applies or uses the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception.
While the guidelines further state that the exemplary considerations are not an exhaustive list and that there may be other examples of integrating the exception into a practical application, the guidelines also list examples in which a judicial exception has not been integrated into a practical application:
• an additional element merely recites the words “apply it” (or an equivalent) with the judicial exception, or merely includes instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea;
• an additional element adds insignificant extra-solution activity to the judicial exception; and
• an additional element does no more than generally link the use of a judicial exception to a particular technological environment or field of use.
Claims 1, 11 and 19 do not recite any of the exemplary considerations that are indicative of an abstract idea having been integrated into practical application. Claims 1, 11 and 19 further recite the additional elements of:
“generating a signal indicating whether to perform the data processing request” (claim 1);
“receive, from a computing device via a wireless communication, a data processing request, the data processing request being associated with at least one control circuit of the vehicle” (claim 19);
“transmitting the data processing request to the at least one control circuit of the vehicle” (claim 1);
“transmitting the data processing request to the at least two control circuits (claim 11, similar to the previous additional element);
“transmit the data processing request to the control circuit of the vehicle and update a status memory of the vehicle with a response from the control circuit” (claim 19, similar to the previous additional elements);
“transmitting data stored in a function buffer of the vehicle to the remote computing device” (claim 1);
“transmit data stored in the at least two function buffers to the remote computing device” (claim 11, similar to the previous additional element); and
“transmit data stored in the status memory of the vehicle to the computing device” (claim 19, similar to the previous additional elements).
These additional elements further limit the abstract idea without integrating the abstract idea into practical application or significantly more. In particular, the generating, receiving and transmitting steps are recited at a high level of generality (i.e., as a general means of gathering and distributing the requests) and amount to mere data gathering, a form of insignificant extra-solution activity added to the judicial exception per MPEP 2106.05(g).
Claims 11 and 19 still further includes the additional elements “data communications control circuit” (claim 11), and “a processor” (claim 19). These elements are not sufficient to amount to significantly more than the judicial exception because they fail to integrate the exception into practical application. The mere inclusion of instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea is indicative that the judicial exception has not been integrated into a practical application. In the instant case, the system (claim 11) and apparatus (claim 19) accomplishes receiving and transmitting steps at the “data communications control circuit”, and “processor”, i.e. via computers. Thus, it is clear that the abstract idea is merely implemented on a computer, which is indicative of the abstract idea having not been integrated in the practical application. The “data communications control circuit,” and the “processor” merely describes how to generally “apply” the otherwise metal judgements in a generic or general purpose computing environment. The data communications control circuit and the processor are recited at a high level of generality and merely automate the generating, receiving and transmitting steps.
STEP 2B: Do the claims recite additional elements that amount to significantly more than the judicial exception? No, claims 1, 11 and 19 do not recite additional elements that amount to significantly more than the judicial exception.
With regard to STEP 2B, whether the claims recite additional elements that provide significantly more than the recited judicial exception, the guidelines specify that the pre-guideline procedure is still in effect. Specifically, that examiners should continue to consider whether an additional element or combination of elements:
• adds a specific limitation or combination of limitations that are not well-understood, routine, conventional activity in the field, which is indicative that an inventive concept may be present; or
• simply appends well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception, which is indicative that an inventive concept may not be present.
Claims 1, 11 and 19 do not recite any specific limitation or combination of limitations that are well-understood, routine, conventional (WURC) activity in the field. Generating, receiving and transmitting data are fundamental, i.e. WURC, activities performed by servers, such as servers, cloud servers, computers operating on data such as the processors recited in claims 1, 11 and 19. Further, applicant’s specification does not provide any indication that the storing, extracting and creating activities of the system are performed using anything other than a conventional computer. MPEP 2106.05(d)(II), and the cases cited therein, including Intellectual Ventures I, LLC v. Symantec Corp., 838 F.3d 1307, 1321 (Fed. Cir. 2016), TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610 (Fed. Cir. 2016), and OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015), indicate that mere performance of an action is a well‐understood, routine, and conventional function when it is claimed in a merely generic manner.
Thus, since claims 1, 11 and 19 are: (a) directed toward an abstract ideas; (b) do not recite additional elements that integrate the judicial exception into practical application; and (c) do not recites additional elements that amount to significantly more than the judicial exception, it is clear that claims 1, 11 and 19 are directed to non-statutory subject matter.
Dependent claims 2-10, 12-18 and 20 further limit the abstract idea without integrating the abstract idea into practical application or addition significantly more. For example, the additional elements in claims 5-10 and 13-18 are further limitations that under their broadest reasonable interpretation are abstract using the analysis for independent claims 1, 11 and 19. Further, for example, the additional elements in claims 2-4, 12 and 20 are further limitations that under their broadest reasonable interpretation further limit the abstract idea without integrating the abstract idea into practical application or adding significantly more.
Conclusion:
As such, claims 1-20 are rejected as being drawn to an abstract idea without significantly more, and thus are ineligible.
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-7, 9, 11-15, 17, 19 and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by U.S. Patent Publication Number 2018/0307244 to Dierker et al. (hereafter Dierker).
As per claim 1, Dierker discloses [a] method performed by an apparatus of a vehicle (see at least Dierker, Abstract, [0004]), the method comprising:
determining whether a data processing request has been received from a remote computing device via a wireless communication (see at least Dierker, [0004]; [0025] disclosing that using the embedded modem of the TCU 120-A (or a mobile device 112 of the user connected to the VCS 106), the VCS 106 of the vehicle 102 may be able to send outgoing data from the vehicle 102 to network destinations on the wide-area network 122, and receive incoming data to the vehicle 102 from network destinations on the wide-area network 122; [0031] disclosing that energy estimation service 132 may further include instructions to provide the energy estimates 134 for function requests 124 to the vehicle 102 to allow the vehicle 102 to confirm whether the vehicle 102 has sufficient battery 104 reserve to perform a received function request 124; [0045] disclosing that with regard to the process in Fig. 4, at operation 402, the vehicle data server 130 determines whether a function request 124 was received. In an example, the vehicle data server 130 receives a function request 124 from the mobile device 112 as illustrated with respect to FIG. 3. If a function request was received, control passes to operation 404. Otherwise, control remains at operation 402),
wherein the data processing request is associated with at least one control circuit of the vehicle (see at least Dierker, [0023] disclosing that the VCS 106 <interpreted as at least one control circuit of the vehicle> may be further configured to communicate with other components of the vehicle 102 via one or more in-vehicle networks 118 or vehicle buses 118. The in-vehicle networks 118 may include one or more of a vehicle controller area network (CAN), an Ethernet network, and a media oriented system transfer (MOST), as some examples. The in-vehicle networks 118 may allow the VCS 106 to communicate with other vehicle 102 systems, such as a vehicle modem of the TCU 120-A, a global positioning system (GPS) module 120-B configured to provide current vehicle 102 location and heading information, and various other vehicle ECUs configured to cooperate with the VCS 106 );
determining whether to perform the data processing request (see at least Dierker, [0037] disclosing that FIG. 3 illustrates an example process 300 for the computation of feature energy estimates 134. In an example, the process 300 may be performed by the energy estimation service 132 executed by the vehicle data server 130; [0038] disclosing that operation 302, the vehicle data server 130 identifies a function request 124. In an example, the vehicle data server 130 creates an association of an identifier of a function to be provided in function requests 124 with a storage record for that identifier of the function request 124; [0046]);
generating a signal indicating whether to perform the data processing request (see at least Dierker, [0049] disclosing that with regard to Fig. 4, at 412, the vehicle data server 130 determines whether the vehicle 102 has sufficient charge to perform the function of the function request 124. In an example, the vehicle data server 130 may confirm that the current SoC from the battery information 126 has sufficient charge to perform the function of the function request 124 based on the current drain level of the vehicle 102. If no current drain level is provided, the vehicle data server 130 may confirm that the current SoC from the battery information 126 is sufficient according to the energy estimate 134 for the feature of the function request 124. If sufficient energy is available, control passes to operation 414. Otherwise, control passes to operation 416); and
based on the signal, either: transmitting the data processing request to the at least one control circuit of the vehicle (see at least Dierker, [0047] disclosing that the vehicle data server 130 powers up the vehicle 102 at operation 406. In an example, the vehicle data server 130 sends a message via TCU 120-A of the vehicle 102 that, when received, is forwarded over the vehicle bus 118 or other vehicle network to the function request application 128 of the VCS 106 of the vehicle 102. The power up request may include further information, such as indications of which vehicle components 120 should be powered up to complete the function request 124. In another example, the power up request includes the indication of the specific function request 124 to be performed, such that the vehicle 102 (e.g., the function request application 128 of the VCS 106), identifies which vehicle components 120 are to be powered up), or
transmitting data stored in a function buffer of the vehicle to the remote computing device (see at least Dierker, [0048] disclosing that a the vehicle data server 130 may send a further request to the vehicle 102 for the battery information 126 <interpreted as a function buffer of the vehicle> a predefined period of time after the sending of the power up request, while in other examples, the power up request for the vehicle 102 further causes the vehicle 102 to be requested to provide the battery information 126. The battery information 126 that is requested may include a current state of charge of the battery 104, and/or a current drain level of the vehicle 102 as powered-up. The vehicle data server 130 receives the battery information 126 from the vehicle 102 at 410).
As per claim 2, Dierker further discloses the following limitation:
wherein the remote computing device comprises a cloud-based backend system or a user terminal (see at least Dierker, [0016] disclosing that FIG. 1 illustrates an example system 100 implementing cloud-based energy budget management for remote function requests 124; [0044] disclosing that FIG. 4 illustrates an example process 400 for cloud-based energy budget management for remote function requests 124. In an example, the process 400 may also be performed by the energy estimation service 132 executed by the vehicle data server 130).
As per claim 3, Dierker further discloses the following limitations:
wherein the function buffer comprises a plurality of function buffers each provided correspondingly to each of the at least one control circuit of the vehicle (see at least Dierker, [0023] disclosing that the in-vehicle networks 118 may allow the VCS 106 to communicate with other vehicle 102 systems, such as a vehicle modem of the TCU 120-A, a global positioning system (GPS) module 120-B configured to provide current vehicle 102 location and heading information, and various other vehicle ECUs configured to cooperate with the VCS 106. The in-vehicle networks 118 may allow the VCS 106 to communicate with other vehicle 102 systems, such as a vehicle modem of the TCU 120-A, ... a climate control management (CCM) 120-F module configured to provide control and monitoring of heating and cooling system components (e.g., compressor clutch and blower fan control, temperature sensor information, etc.); and a battery control module (BACM) 120-G configured to monitor the state of charge or other parameters of the battery 104 of the vehicle 102), and
wherein each of the at least one control circuit of the vehicle comprises an electronic control unit (ECU) electrically coupled to the apparatus (see at least Dierker, Fig. 1 showing VCS 106, electrically coupled to multiple apparatus; [0016] disclosing that a mobile device 112 associated with the vehicle 102 (or other device) provides function requests 124 to the vehicle data server 130, which may be forwarded to the VCS 106 of the vehicle 102 if the feature energy estimates 134 indicate that sufficient vehicle 102 energy is available. The VCS 106 utilizes a function request application 128 installed to the VCS 106 to report the battery information 126 regarding the battery 104 to the vehicle data server 130 to allow for updating of the feature energy estimates 134, and to respond to function requests 124 to perform the requested operations).
As per claim 4, Dierker further discloses the following limitations:
wherein the data processing request comprises at least one of: a remote control request to control the at least one control circuit (see at least Dierker, [0016] disclosing a mobile device 112 associated with the vehicle 102 (or other device) provides function requests 124 to the vehicle data server 130, which may be forwarded to the VCS 106 of the vehicle 102 if the feature energy estimates 134 indicate that sufficient vehicle 102 energy is available. ; [0023] disclosing that the VCS 106 may be further configured to communicate with other components of the vehicle 102 via one or more in-vehicle networks 118 or vehicle buses 118. The in-vehicle networks 118 may include one or more of a vehicle controller area network (CAN), an Ethernet network, and a media oriented system transfer (MOST), as some examples. The in-vehicle networks 118 may allow the VCS 106 to communicate with other vehicle 102 systems), or
a remote inquiry request to inquire about a status of the at least one control circuit or a status of an electronic load managed by the at least one control circuit (see at least Dierker, [0023] disclosing that the vehicle ECUs may include a powertrain control module (PCM) 120-C configured to provide control of engine operating components (e.g., idle control components, fuel delivery components, emissions control components, etc.) and monitoring of engine operating components (e.g., status of engine diagnostic codes); a body control module (BCM) 120-D configured to manage various power control functions such as exterior lighting, interior lighting, keyless entry, remote start, and point of access status verification (e.g., closure status of the hood, doors and/or trunk of the vehicle 102)).
As per claim 5, Dierker further discloses the following limitations:
wherein the transmitting of the data processing request to the at least one control circuit comprises: identifying data by updating a status of the at least one control circuit or a status of an electrical load managed by the at least one control circuit (see at least Dierker, [0015] disclosing that when a function request is received by a vehicle, a current SoC of the vehicle is compared to an up-to-date energy usage value for that vehicle. If the SoC can support that energy usage, a power up request for the feature will be sent to the vehicle. Within a predefined number of seconds of vehicle power up, the vehicle may measure and send back to the server battery information indicative of the amount of current being used at that time as well as an updated SoC. This battery information may then be used by the server to determine whether any extra or unexpected devices are powered. ); and
updating data stored in the function buffer with the identified data (see at least Dierker, [0015]).
As per claim 6, Dierker further discloses the following limitation:
wherein the transmitting of data stored in the function buffer of the vehicle to the remote computing device comprises: blocking the data processing request and transmitting the data stored in the function buffer to the remote computing device (see at least Dierker, [0048]; [0051] disclosing that at 416, the vehicle data server 130 rejects the function request 124. After operation 414, the process 400 ends (or returns to operation 402, not shown). In some cases, if the function request 124 is denied, the vehicle data server 130 may send a message to the mobile device 112 indicating that the vehicle 102 lacks sufficient energy in the battery 104 to perform the requested function).
As per claim 7, Dierker further discloses the following limitations:
wherein the determining of whether to perform the data processing request comprises: based on the remote control request being identified, determining whether the at least one control circuit can be controlled based on the remote control request (see at least Dierker, [0040] disclosing that the vehicle data server 130 calculates an energy estimate 134 for the requested function at 306. In an example, the vehicle data server 130 may determine an energy requirement according to the amount of estimated current draw for the vehicle components 120 activated to perform the function, multiplied by the estimated amount of time during which the draw is required); and
based on the remote inquiry request being identified, determining whether to update an inquiry target corresponding to the remote inquiry request (see at least Dierker, [0040]; [0041] disclosing with regard to Fig. 3 that at operation 308, the vehicle data server 130 updates the energy usage value at the server. In an example, the vehicle data server 130 saves the calculated energy estimate 134 in a storage of the vehicle data server 130 or in a storage otherwise accessible to the vehicle data server 130; [0043]).
As per claim 9, Dierker further discloses the following limitation:
wherein the determining of whether to update the inquiry target comprises: based on a determination to update the inquiry target corresponding to the remote inquiry request, transmitting the data processing request to the at least one control circuit of the vehicle (see at least Dierker, [0043] disclosing that the vehicle data server 130 computes an updated energy estimate 134 for the function at operation 312.; [0047] disclosing that the vehicle data server 130 powers up the vehicle 102 at operation 406. In an example, the vehicle data server 130 sends a message via TCU 120-A of the vehicle 102 that, when received, is forwarded over the vehicle bus 118 or other vehicle network to the function request application 128 of the VCS 106 of the vehicle 102. The power up request may include further information, such as indications of which vehicle components 120 should be powered up to complete the function request 124. In another example, the power up request includes the indication of the specific function request 124 to be performed, such that the vehicle 102 (e.g., the function request application 128 of the VCS 106), identifies which vehicle components 120 are to be powered up).
As per claim 11, similar to claim 1, Dierker discloses [a] system (see at least Dierker, Abstract, [0004]; [0016] disclosing that FIG. 1 illustrates an example system 100 implementing cloud-based energy budget management for remote function requests 124. The vehicle 102 includes a battery 104 to power various vehicle functions during key-off, and a vehicle computing system (VCS) 106 configured to communicate over a wide-area network 122, e.g., using a telematics control unit (TCU) 120-A) comprising:
at least two control circuits (see at least Dierker, [0020] disclosing that the VCS 106 may further include various types of computing apparatus in support of performance of the functions of the VCS 106 described herein. In an example, the VCS 106 may include one or more processors 108 <interpreted as at least two control circuits> configured to execute computer instructions, and a storage 110 medium on which the computer-executable instructions and/or data may be maintained.);
electrical loads associated with the at least two control circuits respectively (see at least Dierker, [0016] disclosing that the vehicle 102 includes a battery 104 to power various vehicle functions <interrupted as imparting electrical loads to the at least two control circuits respectively> during key-off, and a vehicle computing system (VCS) 106 configured to communicate over a wide-area network 122, e.g., using a telematics control unit (TCU) 120-A); and
a data communication control circuit connected to the at least two control circuits (see at least Dierker, [0016] disclosing that the system 100 also includes a vehicle data server 130 configured to maintain feature energy estimates 134 indicative of the amounts of energy required by a vehicle 102 to perform the corresponding functions. The vehicle data server 130 executes an energy estimation service 132 configured to update the feature energy estimates 134 based on battery information 126 received over the wide-area network 122 from the vehicle 102. A mobile device 112 associated with the vehicle 102 (or other device) provides function requests 124 to the vehicle data server 130, which may be forwarded to the VCS 106 of the vehicle 102 if the feature energy estimates 134 indicate that sufficient vehicle 102 energy is available; [0023] ) and
configured to control data communication with a remote computing device (see at least Dierker, [0016]; [0023]),
wherein the data communication control circuit comprises at least two function buffers, respectively associated with the at least two control circuits (see at least Dierker, [0023] disclosing that the in-vehicle networks 118 may allow the VCS 106 to communicate with other vehicle 102 systems, such as a vehicle modem of the TCU 120-A, a global positioning system (GPS) module 120-B configured to provide current vehicle 102 location and heading information, and various other vehicle ECUs configured to cooperate with the VCS 106. The in-vehicle networks 118 may allow the VCS 106 to communicate with other vehicle 102 systems, such as a vehicle modem of the TCU 120-A, ... a climate control management (CCM) 120-F module configured to provide control and monitoring of heating and cooling system components (e.g., compressor clutch and blower fan control, temperature sensor information, etc.); and a battery control module (BACM) 120-G configured to monitor the state of charge or other parameters of the battery 104 of the vehicle 102), and
wherein the data communication control circuit is configured to: check whether a data processing request has been received from the remote computing device (see at least Dierker, [0037]; [0038]; [0046]),
wherein the data processing request is for at least one of the at least two control circuits or the electrical loads (see at least Dierker, [0016]; [0023]; [0040]),
determine whether to perform the data processing request (see at least Dierker, [0037]; [0038]; [0046]; [0049] ), and
based on a determination of whether to perform the data processing request, either: transmit the data processing request to one of the at least two control circuits (see at least Dierker, [0047]), or
transmit data stored in the at least two function buffers to the remote computing device (see at least Dierker, [0048]).
As per claim 12, similar to claim 4, Dierker further discloses the following limitations:
wherein the data processing request comprises at least one of: a remote control request to control the at least two control circuits (see at least Dierker, [0016]; [0023] ), or
a remote inquiry request to inquire about a status of the at least two control circuits or a status of the electrical loads managed by the at least two control circuits (see at least Dierker, [0023]).
As per claim 13, similar to claim 5, Dierker further discloses the following limitations:
wherein the data communication control circuit is further configured to: identify data by updating a status of the at least two control circuits or a status of the electrical loads managed by the at least two control circuits (see at least Dierker, [0015]), and
update the data stored in the at least two function buffers with the identified data (see at least Dierker, [0015).
As per claim 14, similar to claim 6, Dierker discloses the following limitations:
wherein the data communication control circuit is configured to transmit the data stored in the at least two function buffers to the remote computing device by: blocking the data processing request and transmitting the data stored in the at least two function buffers to the remote computing device (see at least Dierker, [0048]; [0051]).
As per claim 15, similar to claim 7, Dierker discloses the following limitations:
wherein the data communication control circuit is further configured to:
based on the remote control request being identified, determine whether the at least two control circuits can be controlled based on the remote control request (see at least Dierker, [0040]); and
based on the remote inquiry request being identified, determine whether to update an inquiry target corresponding to the remote inquiry request (see at least Dierker, [0040]; [0041]).
As per claim 17, similar to claim 9, Dierker further discloses the following limitation:
wherein the data communication control circuit is further configured to determine whether to update the inquiry target by: based on a determination to update the inquiry target corresponding to the remote inquiry request, transmitting the data processing request to the one of the at least two control circuits (see at least Dierker, [0043]; [0047]).
As per claim 19, Dierker discloses [a]n apparatus of a vehicle (see at least Dierker, Abstract, [0029]), the apparatus comprising:
a processor (see at least Dierker, [0020] disclosing that VCS 106 may further include various types of computing apparatus in support of performance of the functions of the VCS 106 described herein. In an example, the VCS 106 may include one or more processors 108 configured to execute computer instructions, and a storage 110 medium on which the computer-executable instructions and/or data may be maintained); and
a memory storing at least one instruction that, when executed by the processor communicating with the memory (see at least Dierker, [0020] disclosing a computer-readable storage medium (also referred to as a processor-readable medium or storage 110) includes any non-transitory (e.g., tangible) medium that participates in providing data (e.g., instructions) that may be read by a computer (e.g., by the processor(s)). In general, a processor 108 receives instructions and/or data, e.g., from the storage 110, etc., to a memory and executes the instructions using the data, thereby performing one or more processes,), is configured to cause the apparatus to:
receive, from a computing device via a wireless communication, a data processing request (see at least Dierker, [0004]; [0025]),
the data processing request being associated with at least one control circuit of the vehicle (see at least Dierker, [0023]);
determine whether to process the data processing request, based on status information associated with the vehicle (see at least Dierker, [0037]; [0038]; [0046]);
and output a signal indicating whether to process the data processing request (see at least Dierker, [0049]),
based on the signal, either: transmit the data processing request to the control circuit of the vehicle and update a status memory of the vehicle with a response from the control circuit (see at least Dierker, [0043] disclosing that vehicle data server 130 computes an updated energy estimate 134 for the function at operation 312. In an example, the vehicle data server 130 averages the received actual energy usage with that of the currently stored energy estimate 134 for the feature. In another example, the vehicle data server 130 replaces the currently-stored energy estimate 134 for the feature with the received actual energy usage for the feature [0047]), or
block transmission of the data processing request to the control circuit and transmit data stored in the status memory of the vehicle to the computing device (see at least Dierker, [0048]; [0051] disclosing that at 416, the vehicle data server 130 rejects the function request 124. After operation 414, the process 400 ends (or returns to operation 402, not shown). In some cases, if the function request 124 is denied, the vehicle data server 130 may send a message to the mobile device 112 indicating that the vehicle 102 lacks sufficient energy in the battery 104 to perform the requested function).
As per claim 20, Dierker further discloses the following limitation (as recited in the claim “at least one of”):
wherein the status information associated with the vehicle comprises at least one of: a state of charge of a low-voltage battery of the vehicle (see at least Dierker, [0049] disclosing that the vehicle data server 130 determines whether the vehicle 102 has sufficient charge to perform the function of the function request 124. In an example, the vehicle data server 130 may confirm that the current SoC from the battery information 126 has sufficient charge to perform the function of the function request 124 based on the current drain level of the vehicle 102. If no current drain level is provided, the vehicle data server 130 may confirm that the current SoC from the battery information 126 is sufficient according to the energy estimate 134 for the feature of the function request 124), a current status of a function controlled by the control circuit as stored in the status memory of the vehicle, and a fault status of an electrical load controlled by the control circuit.
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.
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 non-obviousness.
Claims 8, 10, 16 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Dierker as applied to claim 7 and 15 above, and further in view of U.S. Patent Publication Number 2024/0212400 to Wang.
As per claim 8, Dierker discloses all of the limitations of claim 7, as shown above. But, Dierker does not explicitly teach the following limitations taught in Wang:
wherein the determining of whether the at least one control circuit can be controlled comprises: detecting whether a voltage of a battery of the vehicle is less than a preset threshold value (see at least Wang, [0078] disclosing that the control module 301 determines whether the battery voltage of the vehicle 200 is less than a preset voltage threshold based on the battery voltage information of the vehicle 200 after acquiring the battery voltage information of the vehicle 200. When the battery voltage of the vehicle 200 is less than the preset voltage threshold, a stop remote diagnosis operation is performed, and when the stop remote diagnosis operation is performed, the control module 301 transmits a stop diagnosis command to the vehicle diagnosis instrument 40 through the remote VCI device 20 so that the vehicle diagnosis instrument 40 immediately stops the remote diagnosis according to the diagnosis command. When the battery voltage of the vehicle 200 is greater than or equal to the preset voltage threshold, the remote diagnosis operation is continued); and
based on the voltage being less than the preset threshold value, transmitting the data stored in the function buffer of the vehicle to the remote computing device (see at least Wang, [0078] ; [0080] disclosing that the start remote diagnosis instruction is transmitted to the vehicle diagnosis instrument 40 through the remote VCI device so that the vehicle diagnosis instrument 40 restarts the remote diagnosis according to the start remote diagnosis instruction ).
Dierker and Wang and analogous art to claim 8 because they are in the same field of a remote request processing for reducing or minimizing the discharge of a low-voltage battery. Dierker relates to a cloud-based energy budget manager for connectivity functions (see Dierker, [0001]). Wang relates to a vehicle remote diagnosis system and method (see Wang, [0003]).
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method, as disclosed in Dierker, to provide the benefit of detecting whether a voltage of a battery of the vehicle is less than a preset threshold value, and transmitting the data stored in the function buffer of the vehicle to the remote computing device, as disclosed in Wang, with a reasonable expectation of success. Doing so would provide the benefit of improving the stability and success rate of vehicle remote diagnosis (see at least Wang, [0006]).
As per claim 10, the combination of Dierker and Wang discloses all of the limitations of claim 8, as shown above. Wang further discloses the following limitations:
wherein the determining of whether the at least one control circuit can be controlled further comprises: based on the voltage being greater than or equal to the preset threshold value, identifying, for the at least one control circuit corresponding to the remote control request, the data stored in the function buffer and a status of the at least one control circuit (see at least Wang, [0017] disclosing that the control module is used for outputting the second control signal to the alarm module so that the alarm module sends an alarm signal when it is determined that the battery voltage of the vehicle is less than a preset voltage threshold according to the battery voltage information of the vehicle ;[0036] disclosing obtaining, by the power supply module, a battery voltage of a vehicle according to a control signal output by the control module, and outputting the battery voltage of the vehicle to the remote VCI device; [0069]; [0070]);
identifying a status of an electrical load managed by the at least one control circuit (see at least Wang, [0017]; [0077] disclosing that after receiving the battery voltage information of the vehicle 200 from the remote VCI device 20, the control module 301 also determines, according to the battery voltage information of the vehicle 200, that the battery voltage of the vehicle 200 is less than a preset voltage threshold (for example, the preset voltage threshold is 6V, but not limited thereto, and the preset voltage threshold can be set according to actual situations)); and
based on the status of the electrical load being indicated as faulty, transmitting the data stored in the function buffer of the vehicle to the remote computing device (see at least Wang, [0058] disclosing that the local VCI device 10 acquires diagnostic data such as fault code information from the ECU and then transmits the diagnostic data to the vehicle diagnosis instrument 40 via the remote VCI device 20 so that the vehicle diagnosis instrument 40 gives a diagnostic result according to the diagnostic data).
As per claim 16, similar to claim 8, Dierker discloses all of the limitations of claim 15, as shown above. But, Dierker does not explicitly teach the following limitations taught in Wang:
determine whether the at least two control circuits can be controlled by: detecting whether a voltage of a battery of the system is less than a preset threshold value (see at least Wang, [0078]) ; and
based on the voltage being detected as being less than the preset threshold value, transmitting the data stored in the at least two function buffers to the remote computing device (see at least Wang, [0078]; [0080]).
Dierker and Wang and analogous art to claim 16 because they are in the same field of a remote request processing for reducing or minimizing the discharge of a low-voltage battery. Dierker relates to a cloud-based energy budget manager for connectivity functions (see Dierker, [0001]). Wang relates to a vehicle remote diagnosis system and method (see Wang, [0003]).
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system, as disclosed in Dierker, to provide the benefit of detecting whether a voltage of a battery of the vehicle is less than a preset threshold value, and transmitting the data stored in the function buffer of the vehicle to the remote computing device, as disclosed in Wang, with a reasonable expectation of success. Doing so would provide the benefit of improving the stability and success rate of vehicle remote diagnosis (see at least Wang, [0006]).
As per claim 18, similar to claim 10, the combination of Dierker and Wang discloses all of the limitations of claim 16, as shown above. Wang further discloses the following limitations:
wherein the data communication control circuit is configured to: based on the voltage being greater than or equal to the preset threshold value, identify, for a control circuit corresponding to the remote control request, the data stored in the at least two function buffers and a status of the control circuit (see at least Wang, [0017]; [0036]; [0069]; [0070]),
identify a status of an electrical load managed by the control circuit (see at least Wang, [0017]; [0077] ), and
based on the status of the electrical load being indicated as faulty, transmit the data stored in the at least two function buffers to the remote computing device (see at least Wang, [0058] ).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
U.S. Patent Publication Number 2017/0011561 to Makke et al. (hereafter Makke), see Abstract, disclosing, that further, remotely operating the vehicle using the installed updated software, and responsive to the inoperability below the threshold, requesting a cessation of the further remote operation of the vehicle ; and
U.S. Patent Publication Number 2022/0111732 to He et al. (hereafter He), see [0230] disclosing that after the cumulative number N of monitoring times is recorded, then step S313 is performed to determine whether the cumulative number of monitoring times N=7 is satisfied; and if N=7 is satisfied, step S315 is performed to wake up related controllers of the vehicle and the onboard gateway, monitor the vehicle to obtain monitored vehicle data, and then upload the monitored vehicle data and accumulated status data to the remote monitoring platform by means of the vehicle control unit and the onboard gateway, and then step S317 is performed to determine a current risk probability of the traction battery; or if N=7 is not satisfied, step S317 is directly performed to determine the current risk probability of the traction battery.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PATRICK M. BRADY III whose telephone number is (571)272-7458. The examiner can normally be reached Monday - Friday 7:00 am - 4;30 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Erin Bishop can be reached at 571-270-3713. 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.
PATRICK M. BRADY III
Examiner
Art Unit 3665
/PATRICK M BRADY/Examiner, Art Unit 3665
/Erin D Bishop/Supervisory Patent Examiner, Art Unit 3665
Prosecution Insights