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 .
Notice to Applicant
The following is a Final Office action. In response to Examiner’s Non-Final Rejection of 3/9/26, Applicant, on 6/9/26, amended claims. Claims 1-9 and 11-16 are pending in this application and have been rejected below.
Response to Amendment
Applicant’s amendments are acknowledged.
The objection to the specification is withdrawn in light of the amendment to the specification.
The claim objections are withdrawn in light of the amendments.
The 112a rejections are withdrawn in light of the amendments.
The 112b rejections are withdrawn in light of the amendments.
The 101 rejections are withdrawn in light of the amendments, as the claim is not directed to an abstract idea as it collects power data of buildings, and control discharging of a battery of the ride-sharing electric vehicle to the building during a calculated time zone, and is also viewed as a practical application under Step 2a, Prong 2 when viewing limitations in combination, for improving another technology (See MPEP 2106.05a) and/or is viewed as a using a judicial exception in a meaningful way under MPEP 2106.05(e). Examiner notes support for the last two limitations is found in at least [0059] as published; FIG. 2, 5, S580, “provide discharging service”; and [0059,. 0084-0086, 0115-0116, 0132] setting travel path for apparatus 100 linking ride-sharing service and guiding path for vehicle, and then having apparatus 100 communicate to “provide discharging service” in S580.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-9 and 11-16 are rejected under 35 U.S.C. 103 as being unpatentable over Harty (US 2020/0276910) in view of Daniel (US 2021/0221247) and Dytckov, “Integrate, not compete! On Potential Integration of Demand Responsive Transport Into Public Transport Network,” 2023 IEEE 26th International Conference on Intelligent Transportation Systems (ITSC), pages 2056-2063.
Concerning claim 1, Harty discloses:
An electric vehicle charging and discharging apparatus for linking ride-sharing service and vehicle-to-grid (Harty – see par 39, FIG. 1 – Electric vehicle 22 uses edge network interface circuitry 44 to communicate with a vehicle-to-grid (V2G) service 24 and a mobility service; see par 41 - The EV 22 may also be part of a fleet of vehicles that provide on demand transportation services (e.g., UBER, LYFT) to individuals such as, for example, a potential passenger 42. Potential passenger 42 may use a client device (not shown) to issue a transport request to the EV 22 via the mobility service 26, where the transport request indicates a pick-up location that is different from the discharge location of the SE 40. The EV 22 may selectively grant the transportation request in exchange for compensation), comprising:
a processor (Harty – see par 63 – computing system 120 may be incorporated into an electric vehicle such as EV 22 (FIG. 1)); and
a memory storing software, when executed by the processor, causing the processor (Harty – see par 64 - The processor(s) 122 may execute instructions 136 retrieved from the system memory 126 and/or the mass storage 134 to perform one or more aspects of the method 46 (FIG. 2), the method 56 (FIG. 4A), the method 66 (FIG. 4B), the method 80 (FIG. 5) and/or the method 106 (FIG. 8); see par 65 - execution of the instructions 136 may cause the system 120 to detect a transport request and a V2G energy request, wherein the transport request and the V2G energy request are associated with overlapping service periods, automatically select one of the transport request or the V2G energy request as a granted request, and configure an EV to satisfy the request.) to:
collect power data of buildings including past power usage data, power facility data, and … (Harty – see par 40 - the EV 22 is part of a fleet of vehicles that provide unused energy stored in the battery 32 to facilities such as, for example, a building 34 (e.g., owned, operated and/or occupied by a business, governmental entity or other organization) that experiences a gap (e.g., shortage) between renewable energy collected by a source such as, for example, a solar panel array 36 and the energy demand of the building 34.)
Harty discloses “expected” gap (shortage) in renewable energy collected by a source (See par 40) and having “predictive” grid factors related to energy requests from buildings 34 (See par 75). Harty does not disclose “contracted power.”
Daniel discloses:
collect power data of buildings including past power usage data, power facility data, and “contracted power data” (Daniel – see par 127 - The software gathers data 8 and monitor usage 9 of end devices 6 and resources, as well as processing external data 10 such as market signals 11, weather forecasts 54, and location presence 55. The software performs algorithms 12 e.g. AI & neural network 30 approaches that analyse and identify characteristics and/or events 13 from the data 8 and monitored usage 9 and, based on this, creates/updates predictions 14 of energy use in upcoming time periods and stores learnings 52 and calendar patterns 53 relating to insights into energy usage at the end sites. These predictions 14, learnings 52 and calendar patterns 53 are used in order to co-ordinate how flexibility 15 in said resources, can be scheduled 16, shared 17 or orchestrated to enable various interventions of individual or aggregate groups of resources 7, to achieve certain goals or reliable performance objectives over time, for an individual site 18, local environment 19, wider community 20.).
Harty discloses “expected” gap (shortage) in renewable energy collected by a source (See par 40) and having “predictive” grid factors related to energy requests from buildings 34 (See par 75).
To any extent that Harty does not disclose, Daniel discloses:
predict power consumption of the buildings based on the power data, (Daniel – see par 19 - Said data and usage analysis, may typically include measurement of energy use on a mains (Grid supply), on household or building circuits ; local data on generation outputs and demand data (building, EV chargers see par 52-53 - Predictions may make use of machine learning, pattern recognition and feature and event detection (e.g. of a high load, occupancy event, start of a charge cycle )… rises in consumption triggered by occupancy, e.g. return to work, holiday modes; see par 132 – home/buildings; forecast energy demand needs… includes risk scoring of occupancy or non-occupancy of building).
Harty and Daniel disclose:
calculate, for each building, a time zone requiring additional electrical power and an amount of electrical power required based on the predicted power consumption and at least one of power facility capacity … (Harty – see par 45 - Illustrated processing block 48 provides for detecting a transport request and a V2G energy request, wherein the transport request and the V2G energy request are associated with overlapping service periods (e.g., concurrent/simultaneous demands). see par 46 - More particularly, a V2G data structure 54a (e.g., relational database, table, list) may contain a plurality of V2G energy requests, where the V2G data structure 54a might be maintained on a system such as the V2G service 24 (FIG. 1), already discussed. The V2G data structure 54a documents various request attributes such as, for example, request identifier (ID), timestamp (e.g., time when the request was issued or received), numerical value (e.g., kWh, price per kWh, credits, cryptocurrency, etc.), discharge location, charge location, start time, end time; see par 58 - an EV is dispatched to the vicinity at illustrated block 94 during the weather-related reduction of solar energy exposure. Dispatching the EV to the vicinity of the reduced solar energy exposure may enable the EV to more quickly service V2G energy requests from facilities experiencing a gap/shortage between collected renewable energy and energy demand; see par 77 – the receiving module 214 determines whether the transport timing and the charge timing at least partially overlap. In other examples, the overlap may be based on geography, amount of charge the EV 22 is required to have to satisfy the requests, etc).
Harty does not disclose “contracted power”.
Daniel discloses the “contacted power data” and the limitation as a whole :
calculate, for each building, a time zone requiring additional electrical power and an amount of electrical power required based on the predicted power consumption and at least one of power facility capacity “and contracted power” (Daniel – see par 23 - an optimisation and orchestration method may seek to manage a pure BTM—in home/building customer benefit, or to align objectives between, say, a Utility supplying the customer (BTM+ATM) or across a local group of customers as peers (in a peer to peer model) or as a group (BTM+ATM+LTM) such as houses and EV customers, Utility suppliers and local network; algorithms need to consider: 1) limit export of energy from renewable or battery/EV resources, 2) constraint scoring (e.g. risk of the power network not having enough capacity to meet demand , 3) prediction of shiftable demand or flexibility in homes or vehicles, 4) risk scoring of flexibility and predictability of resources to account for… occupancy or non-occupancy of building, location of electric vehicle, or contract or market constraints; see par 129 - The flexibility 15 of resources may be traded via exchange means 5 such as data, contracts, marketplace platforms, with energy actors 46 such as aggregators, suppliers, local networks, grid, or peer-to-peer or communities 47, via contracts 49; see par 156 - Data stores may also be used to capture market signals or flexibility needs, such as designation of times of day for peak-off/peak, periods of limit e.g. congestion or constraints on networks, contract periods or needs for flexibility, DSR turn-up/turn-down, availability, at a local level (e.g. excess/demand from solar/battery/chargers), utility, network or system operator level).
Harty and Daniel disclose:
estimate travel demand information for regions where the building exist based on … transportation demand data and ride-sharing service participation record data (Harty – see par 45 - Illustrated processing block 48 provides for detecting a transport request and a V2G energy request, wherein the transport request and the V2G energy request are associated with overlapping service periods (e.g., concurrent/simultaneous demands). see par 47 - a mobility data structure 54b (e.g., relational database, table, list) may contain a plurality of transport requests. The illustrated mobility data structure 54b documents various request attributes such as, for example, request ID, timestamp, numerical value (e.g., kWh, distance, price per mile, credits, cryptocurrency, etc.), start location, end location, start time, end time, and so forth. see par 73 - request may be made by the potential passenger 42 inputting information, such as logistical factors. The logistical factors may include at least a portion of the route, the origin, the destination, address, coordinates, point of interest, one or more roadway names, and a waypoint. The logistical factors also be an event, invitation, ticket, or other item associated with a time or location (address, coordinates, point of interest, waypoints, locations disclose “regions”); see par 77 - In response to the receiving module 214 receiving multiple requests, such as a transport request and a V2G energy request, the receiving module 214 may determine the extent to which the requests overlap. For example, the receiving module 214 may calculate transport timing for transport based on the logistical factors associated with the transport request. In other examples, the overlap may be based on geography (disclose “regions”)); see par 78 - transport module 216 uses the one or more logistical factors and/or the transport request to determine a first numerical value associated with remuneration for the transport; In particular, the first numerical value may be based on proximity to the origin in the transport request, the current cost of fuel and/or power, as well as potential passenger loyalty;
see also Daniel disclosing estimate demand – see par 128 - Flexibility is the ability to provide resources that can increase or decrease demand, store or provide power to aid the energy network in managing variability and volatility and balance supply and demand on the network. the ability to manage and optimise the energy resources and their flexibility at end sites provides a range of advantages at all levels of the network, and becomes increasingly important as more variable energy supplies, such as … with the electrification of mobility and heat, that add increasing loads onto the network that vary with location, time and season. see par 130 - 2, mobile phone network masts with batteries 44, sites and buildings 45 with flexible demand side resources, and similarly an electric vehicle charger cluster 33 formed of individual Electric Vehicle charger apparatus 34 (that may also be co-located in a home or street (disclosing regions)), and an example electric vehicle 35).
Harty discloses that it’s “vehicle” includes “rail transport” (See par 35) and that the EV might be a “bus” (See par 39). Harty discloses having transport requests with demands for different service periods (See par 45) and having data on request attributes (See par 47). Daniel discloses having demand data for EV chargers (See par 19), adding or removing resources relative to demand and electrification of mobility that add loads based on location, time, and season (See par 128, 130).
Dytckov discloses:
estimate travel demand information for regions where the building exist based on “public transportation demand data” and ride-sharing service participation record data (Dytckov – see page 2056, col. 1, Introduction - Demand Responsive Transport (DRT) is an umbrella concept incorporating a big variety of transport services where travelers have the power to affect where vehicle ride, when vehicle ride, or where they stop; see page 2057, last paragraph – page 2058, Col. 1, 1st paragraph – demand generation method relies on generating trip characteristics form conditional probability distributions; page 2058, col. 1, 2nd paragraph – data used in demand generation shown in FIG. 3; data sources are “statistics Sweden (SCB), Open Street Maps (OSM), and travel survey in Scania Sweden (RVU)”; page 2058, col. 1, 3rd paragraph - RVU distinguish 17 trip purposes. To assign trip destinations to the appropriate locations, building types were extracted from SCB and supplemented by points of interest from OSM. Trip purposes are mapped onto appropriate building types so that, for example, the destination of a trip home is allocated to a residential building and trips to pick up or drop off kids to schools or preschools; page 2060, Col. 2 - The important aspect is that DRT vehicles are connected to specific bus departures in a way that the whole trip is satisfactory for a traveler as explained in section IV. The depot for DRT vehicles is assumed to be located at the main bus stop in Sjobo town (disclosing a region). The fleet size is unlimited as the goal of the service is to serve all the requested trips, but the operational costs force the routing algorithm to combine trips into the same vehicle for ride-sharing when possible).
Harty, Daniel, and Dytckov disclose:
set a travel path of a ride-sharing electric vehicle based on the time zone requiring the additional electrical power, the required amount of electrical power, and the travel demand information (Harty – see par 83 - the grant module may dispatch the EV 22 to the origin associated with the transport request or the charging location associated with the V2G energy request. Accordingly, the grant module 220 may generation a path plan for the EV 22 that facilitates the EV 22 navigating to a location associated with the grated request. For example, the grant module 220 may access the vehicle sensors 238 or the vehicle systems 240 to determine the current location of the EV 22 and store, calculate, and/or provide route and/or destination information and facilitate features like turn-by-turn direction for the EV 22 based on the granted request. Accordingly, the hybrid vehicle-to-grid and mobility service request system 202 manages the requests received for an EV 22 to facilitate maximizing the benefit that can be conferred to the EV 22. Therefore, the operator can use an EV or fleet of EVs to the greatest effect;
see also Dytckov – page 2060, Col. 1, Section C – optimization goal is to find vehicle routes that minimize operational costs);
control the ride-sharing electric vehicle to travel to a building requiring the additional electrical power during the calculated time zone (Applicant’s support for the limitation is based on FIG. 2, FIG. 5, [0059] stating “ The service manager 100 may provide and manage a service capable of moving passengers to a desired location by using the ride-sharing service, and lowering the power consumption of the building by discharging the battery of electric vehicle through the V2G technology.”; [0084-0086] where there is a “ The travel path setting module 150 may set a travel path of the ride-sharing vehicle for each time zone within the region based on a time zone requiring the additional power, the required amount of electrical power, and the travel demand.”
Harty discloses the limitations based on broadest reasonable interpretation in light of the specification – see par 35 - the term “vehicle” can include vehicles that are automated or non-automated with pre-determined paths or free-moving vehicles. see par 67-68, FIG. 11 - the hybrid vehicle-to-grid and mobility service request system 202 includes a system processor 204; processor 204 includes a grant module 220; see par 83 - the grant module 220 may generation a path plan for the EV 22 that facilitates the EV 22 navigating to a location associated with the grated request; see par 45 - Block 52 may include, for example, dispatching the EV to a pick-up location associated with the transport request, dispatching the EV to a discharge location associated with the V2G request, scheduling future dispatches, programming autonomous navigation routes, and so forth. (disclosing generation of a path by a central computer and passing path along, same as Applicant’s example); and
control discharging of a battery of the ride-sharing electric vehicle to supply electrical power to the building during the calculated time zone (Applicant’s support for the limitation is based on FIG. 2, FIG. 5, [0115] stating “ FIG. 5 shows a signal flow in providing an electric vehicle charging and discharging service linking the ride-sharing service and the V2G between the building manager 20, the service manager 100, and the customer terminal 30. [0132] stating “At step S580, the service manager 100 may provide the discharging service to the building manager 20.”
Harty discloses the limitations based on broadest reasonable interpretation in light of the specification – see par 40 - the EV 22 may include a V2G subsystem 38 that enables unused energy stored in the battery 32 to be transferred (e.g., discharged) to the building 34 via source equipment (SE) 40 installed at the location of the building 34. In this regard, when gaps/shortages are encountered or expected, the building 34 (or associated system) may issue V2G energy requests to the EV 22 via the V2G service 24).
Harty and Daniel are analogous art as they are directed to using vehicles for giving energy to respond to electricity demand (Harty Abstract par 39-40; Daniel Abstract, par 12, 172/186 (vehicle to grid)). Harty and Dytckov are analogous art as they are directed to handling transportation requests (See Harty Abstract, par 45; Dytckov Abstract). 1) Harty discloses “expected” gap (shortage) in renewable energy collected by a source (See par 40) and having “predictive” grid factors related to energy requests from buildings 34 (See par 75). Daniel improves upon Harty by disclosing predictions for usage and demand for homes/buildings on the electric grid based on scoring aspects such as occupancy or non-occupancy (See par 19, 52-53, 132). One of ordinary skill in the art would be motivated to further include predicting electric/energy demand based on factors such as occupancy to efficiently improve upon the “expected” gaps in energy collected and “predictive” energy requests from buildings in Harty. 2) Harty discloses that it’s “vehicle” includes “rail transport” (See par 35) and that the EV might be a “bus” (See par 39). Harty discloses having transport requests with demands for different service periods (See par 45) and having data on request attributes (See par 47). Dytckov improves upon Harty and Daniel by disclosing having travel/transport data from public data (See age 2058; 2060). One of ordinary skill in the art would be motivated to further include public transport data from bus usage to efficiently improve upon the mention that an EV could be a “bus” or it could be “rail transport” in Harty.
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the hybrid vehicle-to-grid and mobility service requests that maximizes benefit in Harty (see Abstract, FIG. 12, par 90) to further use predictions of electricity/energy demands based on building data such as occupancy, return to work as disclosed in Daniel (See par 19, 52-53, 132), and to further include transport data related to use of buses as disclosed in Dytckov, since the claimed invention is merely a combination of old elements, and in combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable and there is a reasonable expectation of success.
Concerning independent claim 11, Harty and Daniel disclose:
An electric vehicle charging and discharging method for linking ride-sharing service and vehicle-to-grid (Harty – see par 39, FIG. 1 – Electric vehicle 22 uses edge network interface circuitry 44 to communicate with a vehicle-to-grid (V2G) service 24 and a mobility service; see par 41 - The EV 22 may also be part of a fleet of vehicles that provide on demand transportation services (e.g., UBER, LYFT) to individuals such as, for example, a potential passenger 42. Potential passenger 42 may use a client device (not shown) to issue a transport request to the EV 22 via the mobility service 26, where the transport request indicates a pick-up location that is different from the discharge location of the SE 40. The EV 22 may selectively grant the transportation request in exchange for compensation).
The remaining limitations are similar to claim 1 and are rejected for the same reasons as above.
It would have been obvious to combine Harty and Daniel for the same reasons as claim 1 above.
Concerning claims 2 and 12, Harty and Daniel disclose:
The apparatus of claim 1, wherein the processor is configured to collect past power usage data, power facility data (Harty – see par 75 - The grid factors may include, but are not limited to, the available charge on the grid, the charge level of a particular charge point such as SE 40, traffic, geolocation, weather, etc. The grid factors may be historical, current, and/or predictive. For example, the charge level for the SE 40 may include a prediction of a weather-related reduction of the charge levels), …, and location data of respective buildings, for predicting the power consumption of the buildings (Harty – see par 40 - the EV 22 may include a V2G subsystem 38 that enables unused energy stored in the battery 32 to be transferred (e.g., discharged) to the building 34 via source equipment (SE) 40 installed at the location of the building 34. In this regard, when gaps/shortages are encountered or expected, the building 34 (or associated system) may issue V2G energy requests to the EV 22 via the V2G service 24.) …
Harty does not disclose “contracted power”.
Daniel discloses the “contacted power data” along with the “power prediction” as in claim 1:
contracted power data (Daniel – see par 3 – resources include electric vehicles; see par 109 - example and embodiment, is where distributed ledger approaches are used to create and manage a smart contract between parties or form a shareable coin to mediate e.g. how KWh's of solar generation, Battery capacity, or local flexibility is shared on either a local ledger basis—where a trusted party is an asset such as a meter/charger/network node, within a location, that is included as a location-stamp within a hash of a time-stamp and transaction between parties. see par 129 - The flexibility 15 of resources may be traded via exchange means 5 such as data, contracts, marketplace platforms, with energy actors 46 such as aggregators, suppliers, local networks, grid, or peer-to-peer or communities 47, via contracts 49 and enable financial payments 48, or other benefits 50 such as carbon offsets).
It would have been obvious to combine Harty and Daniel for the same reasons as claim 1 above. In addition, Harty discloses considering available charge on the grid, looking at grid factors that are historical, current, and/or predictive (See par 75). Daniel improves upon Harty by including contracts agreeing to supply energy (See par 109, 129) and considering flexible demand resources including vehicle charger clusters co-located in a street (See par 130).
Considering claims 3 and 13, Harty and Daniel disclose:
The apparatus of claim 2, wherein the processor is configured to predict a power usage pattern during for each building for a predetermined time period based on the collected past power usage data (Daniel – see par 52 - Predictions may make use of machine learning, pattern recognition and feature and event detection (e.g. of a high load, occupancy event, start of a charge cycle), training of neural networks to aid recognition of patterns or classifying patterns that are unusual, use of modelling, convolution and comparison, forecasting and probabilistic modelling (e.g. of energy load profiles on event detection, solar profiles, EV charge patterns), See par 53 - detecting the start of a high-load appliance such as a cooker, air-conditioner or washing machine, by detecting substantial step change in energy use, and disaggregation and pattern recognition approaches, such as referring to past profiles and learnt behaviour. This has been found to be particularly advantageous for informing forward predictions for such high-loads, or standard electric vehicle charging events, as well as rises in consumption triggered by occupancy (e.g. detection of return to work, away—e.g. holiday modes, night time slow down), and various tools such as risk-profiles can lend weight to the stability of such forecasts and past reliability to inform energy management and how predictions are used for trading, battery charge plan adjustment).
It would have been obvious to combine Harty and Daniel for the same reasons as claim 1 above.
Concerning claims 4 and 14, Harty and Daniel disclose:
The apparatus of claim 2, wherein the processor is configured to:
estimate a time zone requiring electrical power supply for each building based on the power facility data and the contracted power data (Daniel – see par 3 – resources include electric vehicles; See par 112 - distributed energy storage assets, EV charge apparatus or electric vehicles, where said vehicle contracts the management and optimisation system to perform … maximising income opportunities and contracted revenue or payments from such parties, such as may occur in Energy As A Service (EaaS) models or Transport As A Service (TaaS) models; see par 129 – as in claim 2 above – resources… use contracts … with energy actors; see par 145 - optimisation and decision logic, may also make use of linear programming techniques to focus an optimisation between maximising various properties (e.g. demand, PV supply, grid tariff price, weather) within a specific interval and time unit (TU), and establish a typical flow chart of measured or expected characteristics, and how, e.g. by varying a battery charge rate/discharge parameter in a household battery or electric vehicle charging plan, a local optimisation could occur for predicted time interval (see FIG. 8).; see par 157 - benefit, may include a method of generating a plan (for flexibility e.g. charging/discharging of an asset), based on sharing current and monitored data with a prediction engine and an economic model, wherein said economic model calculates an impact of the example plan subject to other data (e.g. battery, PV sizing, choices, tariffs) and with reference to a tariff model or store; and said prediction engine calculates a forward model of consumption and generation for applying such a plan, along with other factors and data (e.g. weather or other consumption predictions) and stores the prediction, to enable performance monitoring and feedback to the system or requests for new predictions); and
determine an amount of electrical power to be discharged from the ride-sharing electric vehicle to the building during the estimated time zone (Harty – see par 45 - dispatching the EV to a discharge location associated with the V2G request; see par 46 – V2G… discharge location, start time, end time; the numerical value of a V2G energy request may be generated by an entity in need of unused energy; see par 50 block 58 determine whether EV has resources (unused energy) to satisfy the request; see par 77 – the receiving module 214 determines whether the transport timing and the charge timing at least partially overlap. In other examples, the overlap may be based on geography, amount of charge the EV 22 is required to have to satisfy the requests, etc
see also Daniel –See par 112 - distributed energy storage assets, EV charge apparatus or electric vehicles, where said vehicle contracts the management and optimisation system to perform … maximising income opportunities and contracted revenue or payments from such parties, such as may occur in Energy As A Service (EaaS) models or Transport As A Service (TaaS) models; see par 157 - benefit, may include a method of generating a plan (for flexibility e.g. charging/discharging of an asset), based on sharing current and monitored data with a prediction engine and an economic model, wherein said economic model calculates an impact of the example plan subject to other data (e.g. battery, PV sizing, choices, tariffs) and with reference to a tariff model or store; and said prediction engine calculates a forward model of consumption and generation for applying such a plan, along with other factors and data (e.g. weather or other consumption predictions) and stores the prediction, to enable performance monitoring and feedback to the system or requests for new predictions; see par 208 - Referring now to FIG. 9, this shows a schematic of an example of a plan generator 104 method performed by software 2 within a management and optimisation system 1 of generating a plan 114 (e.g. for flexibility, charging/discharging of an asset in a location 113) under various constraints and predictions 14, 109, and external data e.g. weather 54, tariff information 108 and flexibility requests 110. ).
It would have been obvious to combine Harty and Daniel for the same reasons as claim 1 above.
Concerning claims 5 and 15, Harty discloses that it’s “vehicle” includes “rail transport” (See par 35) and that the EV might be a “bus” (See par 39). Harty discloses having transport requests with demands for different service periods (See par 45) and having data on request attributes (See par 47).
Dytckov discloses:
The apparatus of claim 1, wherein the processor is configured to generate the travel demand information based on public transportation demand data (Dytckov – see page 2056, col. 1, Introduction - Demand Responsive Transport (DRT) is an umbrella concept incorporating a big variety of transport services where travelers have the power to affect where vehicle ride, when vehicle ride, or where they stop; see page 2057, last paragraph – page 2058, Col. 1, 1st paragraph – demand generation method relies on generating trip characteristics form conditional probability distributions; page 2058, col. 1, 2nd paragraph – data used in demand generation shown in FIG. 3; data sources are “statistics Sweden (SCB), Open Street Maps (OSM), and travel survey in Scania Sweden (RVU)”; page 2058, col. 1, 3rd paragraph - RVU distinguish 17 trip purposes. To assign trip destinations to the appropriate locations, building types were extracted from SCB and supplemented by points of interest from OSM. Trip purposes are mapped onto appropriate building types so that, for example, the destination of a trip home is allocated to a residential building and trips to
pick up or drop off kids to schools or preschools; page 2060, Col. 2 - The important aspect is that DRT vehicles are connected to specific bus departures in a way that the whole trip is satisfactory for a traveler as explained in section
IV. The depot for DRT vehicles is assumed to be located at the main bus stop in Sjobo town. The fleet size is unlimited as the goal of the
service is to serve all the requested trips, but the operational costs force the routing algorithm to combine trips into the same vehicle for ride-sharing when possible.).
Harty, Daniel, and Dytckov disclose:
and ride-sharing service participation record data for each time zone and each time zone (as in claim 1 - Harty – see par 45 - Illustrated processing block 48 provides for detecting a transport request and a V2G energy request, wherein the transport request and the V2G energy request are associated with overlapping service periods (e.g., concurrent/simultaneous demands). see par 47 ; see par 73 - request may be made by the potential passenger 42 inputting information, such as logistical factors. The logistical factors may include at least a portion of the route, the origin, the destination, address, coordinates, point of interest, one or more roadway names, and a waypoint. logistical factors also be an event, invitation, ticket, or other item associated with a time or location; see par 77 - … a transport request and a V2G energy request, the receiving module 214 may determine the extent to which the requests overlap. … the overlap may be based on geography; see par 78 - transport module 216 uses the one or more logistical factors and/or the transport request to determine a first numerical value … In particular, the first numerical value may be based on proximity to the origin in the transport request, the current cost of fuel and/or power, as well as potential passenger loyalty
See also Dytckov- See page 2059, col. 1, 2nd paragraph - we define the area where the destinations of the secondary trips can be allocated. The destination of any trip is limited to this elliptical area. The limitation of the elliptical trip space aims to approximate the spacetime constraints for secondary trips (as, for example, in
[25]) by putting more potential destinations in between home and main activity; see page 2059, col. 2, 3rd paragraph - spatial distribution of the generated demand corresponds to the expectations: about half of the trips related to Sjobo happen within the municipality, while the largest long-distance demand is split between the neighbouring municipalities. Fig. 6 shows the comparison between the
number of commuters to or from Sjobo generated by the described
procedure and the number of commuters from SCB.)
It would have been obvious to combine Harty and Daniel and Dytckov for the same reasons as claim 1 above.
Concerning claims 6 and 16, Harty and Daniel and Dytckov disclose:
The apparatus of claim 5, wherein the processor is configured to estimate an actual travel demand associated with movement of the ride-sharing electric vehicle between buildings based on the generated travel demand information (Harty – see par 83 - the grant module may dispatch the EV 22 to the origin associated with the transport request or the charging location associated with the V2G energy request. Accordingly, the grant module 220 may generation a path plan for the EV 22 that facilitates the EV 22 navigating to a location associated with the grated request. For example, the grant module 220 may access the vehicle sensors 238 or the vehicle systems 240 to determine the current location of the EV 22 and store, calculate, and/or provide route and/or destination information and facilitate features like turn-by-turn direction for the EV 22 based on the granted request;
see also Dytckov – See page 2057, Col. 2, Last section - We generate the demand on the micro level explicitly allocating the origin, the destination and the start time for each trip of every individual. Such a level of detail is required to compile a vehicle routing problem; See page 2060, Col. 1, last section - The type of vehicle
routing problem that is solved is the dial-a-ride problem with time windows. The problem consists of the set of trip requests described by their origin, destination, time interval for picking up, time interval for dropping off, and maximum in-vehicle time. The optimisation goal is to find vehicle routes that minimise operational costs. The cost model is based on [26] and summarised in table I. Additionally, a very high penalty for not-serving a traveller is set. The penalty forces the optimiser to route vehicles for all the travellers as a first priority and optimise the operational costs as a second).
It would have been obvious to combine Harty and Daniel and Dytckov for the same reasons as claim 1 above.
Concerning claims 7 and 17, Harty and Daniel and Dytckov disclose:
The apparatus of claim 1, wherein: the processor is configured to determine the amount of electrical power to be discharged based on a difference between predicted power consumption and contracted power of the building (Daniel –see par 25 - a central software system arranged to receive data and monitor usage of end devices and resources at plural remote sites in a network…software system being arranged to determine a battery charging plan for charging and/or discharging batteries at the remote sites, where the batteries are Electric Vehicle (EV) batteries and/or other energy storage batteries; see par 129 - The flexibility 15 of resources may be traded via exchange means 5 such as data, contracts, marketplace platforms, with energy actors 46 such as aggregators, suppliers, local networks, grid, or peer-to-peer or communities 47, via contracts 49; see par 156 - Data stores may also be used to capture market signals or flexibility needs, such as designation of times of day for peak-off/peak, periods of limit e.g. congestion or constraints on networks, contract periods or needs for flexibility, DSR turn-up/turn-down, availability, at a local level (e.g. excess/demand from solar/battery/chargers), utility, network or system operator level); see par 208 - Referring now to FIG. 9, this shows a schematic of an example of a plan generator 104 method performed by software 2 within a management and optimisation system 1 of generating a plan 114 (e.g. for flexibility, charging/discharging of an asset in a location 113) under various constraints and predictions 14, 109, and external data e.g. weather 54, tariff information 108 and flexibility requests 110. The prediction engine 105 may for example calculate a forward model of consumption and generation for applying such a plan, along with other factors and data 107, 54.).
It would have been obvious to combine Harty and Daniel and Dytckov for the same reasons as claim 1 and 5 above.
Concerning claims 8 and 18, Harty and Daniel disclose:
The apparatus of claim 1, wherein the buildings are located within a microgrid (Applicant’s [0002, 0051] state “ electric vehicles that can be parked in buildings within a microgrid”; “ the building manager 20 may be provided as a server operating the buildings within a microgrid MG.” Harty – see par 40, FIG. 1 – building 34 has renewable energy collected by a source such as for example a solar panel array 36;
Daniel – see par 129 – flexibility of resources 15 may be traded … with energy actors such as “local networks”; see par 141 - enact a remote control change or program a local control change on an end resource, such as adjusting a battery management system or charge plan, by for example: the end user, in response to an external request or as an optimisation using data from I) local sources: such as battery State of charge, energy use, solar supply, EV demand; see par 173 - Modelling and decision logic to make or schedule adjustments to local active management plans, central or distributed battery resources and EV charging, solar curtailment, heat-resources, DSR assets, or to co-ordinate requests to share energy and flexibility between local participants or to and between local assets (such as distributed or central battery, solar, heat, charging resources; see par 202 - Referring now to FIG. 4, this shows a schematic of a configuration of the management and optimisation system 1 aiding control of a local voltage network 25, wherein an active management of resources could deliver a saving 57 or deferral of upgrade cost, and local resources such as EV chargers 34, flexible building or site resources 45, could be balanced by managed charging of central resources 31, 32 and community assets (e.g. 38) by the software system 1 and algorithms 12 with local data feeds (e.g. 6, 54, 11).)
It would have been obvious to combine Harty and Daniel for the same reasons as claim 1 above.
Concerning claims 9 and 19, Harty discloses:
The apparatus of claim 1, wherein the processor is configured to synchronize arrival of the ride-sharing electric vehicle with the calculated time zone requiring the additional electrical power (Harty - see par 35 - the term “vehicle” can include vehicles that are automated or non-automated with pre-determined paths or free-moving vehicles. see par 67-68, FIG. 11 - the hybrid vehicle-to-grid and mobility service request system 202 includes a system processor 204; processor 204 includes a grant module 220; see par 46 - More particularly, a V2G data structure 54a (e.g., relational database, table, list) may contain a plurality of V2G energy requests, where the V2G data structure 54a might be maintained on a system such as the V2G service 24 (FIG. 1), already discussed. The V2G data structure 54a documents various request attributes such as, for example, request identifier (ID), timestamp (e.g., time when the request was issued or received), numerical value (e.g., kWh, price per kWh, credits, cryptocurrency, etc.), discharge location, charge location, start time, end time; see par 77 – the receiving module 214 determines whether the transport timing and the charge timing at least partially overlap. In other examples, the overlap may be based on geography, amount of charge the EV 22 is required to have to satisfy the requests, etc; see par 83 - the grant module 220 may generation a path plan for the EV 22 that facilitates the EV 22 navigating to a location associated with the grated request).
Response to Arguments
Applicant's arguments filed 6/9/26 have been fully considered but they are not persuasive and/or are moot in view of the new rejections.
Applicant’s arguments are moot over the new rejections necessitated by the amendments.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 IVAN R GOLDBERG whose telephone number is (571)270-7949. The examiner can normally be reached 830AM - 430PM.
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, Anita Coupe can be reached at 571-270-3614. 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.
/IVAN R GOLDBERG/Primary Examiner, Art Unit 3619
Prosecution Insights