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 .
Claims 18-31 have been presented for examination.
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.
Claim 31 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. Specifically, claim 31 is directed to a program, i.e., software, that is not stored on a statutory computer-readable medium. Consequently, the claimed program is simply a series of mental steps, i.e., an abstract idea. And, because an abstract idea does not fall into one of the four statutory categories of invention, claim 31 is non-statutory.
While applicant has amended claim 31 to include the computer program is “stored in a storage medium”, this does not overcome the 101 rejection. Specifically, the claim is still drawn to the program itself. Second, a “storage medium” can technically be regarded as a transitory carrier wave that stores the program as it propagates through the air. The examiner recommends applicants amend claim 31 to recite something similar to, “A non-transitory computer readable medium comprising computer readable program code, which when executed by a computer processor enables the computer processor to perform a method of claim 30.”
It should be noted that including “non-transitory” into the claim is not considered new matter. See the "Subject Matter Eligibility of Computer Readable Media" memo dated January 26, 2010 (OG Cite: 1351 OG 212; OG Date: 23 Feb 2010).
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.
Claim(s) 18-19, 21-24 and 26-31 is/are rejected under 35 U.S.C. 103 as being unpatentable over Atluri1 in view of Ree2.
Referring to claim 18, A control system arranged to control transfer of energy to and from a heavy- duty vehicle, wherein the control system implements an application programming interface (API) configured to allow connections between control modules of the heavy-duty vehicle and/or from one or more external entities to the vehicle
wherein the control system is configured to determine an available amount of energy for transfer from the vehicle to an external consumer, and a desired amount of energy to transfer to the vehicle from an external energy source [abstract, 0034].
wherein the control system is configured to exchange information related to the available amount of energy for transfer from the vehicle via the API [abstract, 0034, 0051].
wherein the control system is configured to exchange information related to the available amount of energy for transfer to the vehicle via the API [abstract, 0034, 0051].
In summary, Atluri teaches a system wherein vehicle to vehicle charging can occur. The process involves a supplying vehicle to indicate how much battery power is available to provide to another vehicle. Depending on your perspective, the receiving vehicle will receive information regarding how much power it can receive from the supplying vehicle. From the other perspective, the supplying vehicle will send information regarding how much power it can supply to the receiving vehicle. The communication is interpreted as an API since it comprises application software executing in the cloud with the vehicles communicating via program [0005, 0057].
While Atluri teaches the invention substantially as claimed above it is not explicitly taught to trigger transmission of a message if a transfer is unwanted or unauthorized. Ree teaches that unauthorized charging can trigger an alert indicating the unauthorized charging [0023]. It would have been obvious to one of ordinary skill in the art before the effective filing date to include the teachings of Ree into Atluri because it would keep the user knowledgeable with regards to the charging process.
Referring to claim 19, Atluri teaches identifying optimal locations for the first and second vehicle and directs them to the common location (i.e., vehicle motion management control) and also teaches the vehicles can be a truck (i.e., heavy-duty vehicle) [0023, 0039].
Referring to claim 21, Atluri teaches that the amount of energy is requested [0010].
Referring to claim 22, Atluri teaches that cost is a factor in determining where to charge from [0016].
Referring to claim 23, Atluri teaches sending information indicating an amount of energy that is available for transfer [abstract]. The available amount is related to the total amount of energy that it is capable of transferring.
Referring to claim 24, Atluri teaches that information regarding location and supplier types are exchanged [0051]. Customer-to-customer, and customer-to-business are interpreted as different provider types.
Referring to claim 26, Atluri teaches vehicles have their own controller (i.e., vehicle controller) while also communicating information about an amount of available energy, the vehicle GPS location [0005, 0034, 0041].
Referring to claim 27, Atluri teaches that the system in part includes cloud computing [0005].
Referring to claim 28, Atluri teaches vehicles communicating information about an amount of available energy (related to energy transfer) and GPS location (related to vehicle motion management) [0034]. Because the vehicles are directed to a common location, the GPS coordinates are interpreted as being related to vehicle motion management [0023].
Referring to claims 29-31, these are rejected on the same basis as set forth hereinabove. Atluri and Ree teach the system and therefore teach the method, vehicle and program performing the same.
Claim(s) 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Atluri and Ree as applied to claims 18-19, 21-24 and 26-31 above, and further in view of Kaufman et al3.
Referring to claim 20, Atluri further teaches that an option presented to a user is the ability to charge from a charging station [0037]. But while Atluri teaches charging from a charging station, it is not explicitly taught to maintain a list of energy types available for transfer. Kaufman teaches that vehicles can further charge from solar panels, wind turbines, battery sources, engine fuel sources and can also be charged via either AC or DC forms [0035]. It would have been obvious to one of ordinary skill in the art before the effective filing date to include a list with the additional sources of power because Atluri further considers CO2 footprint with respect to charging [0055] and thus knowing if a charging source were supplied via renewable energy (i.e. wind/solar) vs an engine powered by fuel, the user would be able to make a more informed decision. Regarding AC vs DC charging, there are known benefits and shortfalls with respect to AC charging vs DC charging. For example, AC charging is cheaper and slower while DC charging is faster but generates more heat and thus adds stress to the battery system. Having a list of which charging options provide AC and DC charging would also allow a user to make a more informed decision with respect to charging.
Claim(s) 25 is/are rejected under 35 U.S.C. 103 as being unpatentable over Atluri and Ree as applied to claims 18-19, 21-24 and 26-31 above, and further in view of Daum et al4.
Referring to claim 25, while the Atluri-Ree combination teach the invention as claimed above, it is not explicitly taught to obtain information about an energy transfer capability of the vehicle; upcoming transport mission, and one or more power sources. Furthermore, the Atluri-Ree combination does not teach determining tactics for when to transfer energy to the vehicle in dependence of the energy transfer capability, the upcoming transport mission and the one or more power sources in the environment, wherein the tactics are determined under a constraint to fulfil the upcoming transport mission. Daum teaches the above [0120-0125]. In summary, Daum teaches determining a trip required by the vehicle. The route is planned by accounting for a total amount of energy that the vehicle can store (information about an energy transfer capability), locations of off-board energy sources (one or more power sources) and determines parameters like speed, energy costs, alternative routes and when to stop to recharge. These considerations are evaluated and updated when necessary. It would have been obvious to one of ordinary skill in the art to include the teachings of Daum into the Atluri-Ree combination because doing so would optimize a route plan when traveling from one location to another. Because Atluri teaches including cloud-based control, it is interpreted that the Atluri-Ree-Daum combination that the tactics taught in Daum would be generated at the command center (i.e., cloud) and then sent to the vehicle (i.e., external entity with respect to the cloud-based command center) for providing information regarding the transport mission. This has similarity to the control center sending directions to a common location for multiple vehicles [0023].
Response to Arguments
Applicant's arguments filed 3/10/26 have been fully considered but they are not persuasive.
In the REMARKs, applicants argue in substance that neither Atluri nor Ree teach the use of an API.
Referring to applicants’ argument, while the term API was not explicitly recited by name, its operation was present in Atluri. An API is simply a set of routines used by an application program to direct operations of a devices operating system. In Atluri, we have a plug command center which operates in the cloud and includes application software [0005, claim 1]. The plug command center cloud-based application receives information related to state of charge for a plurality of vehicles and their GPS locations [0016-0017, 0034]. The application then directs the vehicles to a location to perform an energy transfer between vehicles. A cloud-based application for communicating with vehicles to exchange state of charge information and location information describes API operation.
Regarding transferring a message indicating the unwanted/unauthorized energy transfer via API, Atluri describes controller (62) as communicating with both the cloud-based plug command center and the controllers of other vehicles or both simultaneously [0041]. Because the plug command center is expressly described as comprising application software, communication with it strongly suggests the use of an API. Given that controller (62) serves as a unified communication node interfacing with multiple distinct entities, including the cloud-based application and peer vehicle controllers, it would be apparent that one would implement consistent API-based communication architecture across all interactions rather than employing different communication mechanisms for each.
That said, Ree further teaches sending an alert in the event of an unauthorized charging is requested, which generate an alert signal to the network and also notifies a customer [0023]. The controller (62) in Atluri already communicates via network to the cloud-based plug command center and therefore would logically use the same to issue the alert signal to the network. Since the controller (62) communicates with the network for charging coordination and transmission of the alert signal, this strongly suggests the use of a common API for the same reasons discussed immediately above for employing consistent API-based communication architecture across all interactions.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARK A CONNOLLY whose telephone number is (571)272-3666. The examiner can normally be reached Monday-Friday 9am-5pm.
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, Kamini Shah can be reached at 571-272-2279. 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.
/MARK A CONNOLLY/Primary Examiner, Art Unit 2115 5/8/26
1 Cited in the previous office action.
2 Cited in the previous office action.
3 Cited by applicant and in the previous office action.
4 Cited by applicant and in the previous office action.
Prosecution Insights