DETAILED ACTION
Response to Amendment
The reply filed 2026/06/17, has been fully considered. Claims 7, 18, 19, and 20 have been amended. No claims have been cancelled. Claims 1–20 are pending.
In view of the Replacement Sheet for Figure 5 and the accompanying amendment to the specification at ¶[0088], the objection to the drawings is withdrawn.
The objection to Claims 7 and 18 has been rendered moot by Applicant's amendment, which now recites "a Charging Point Management System (CPMS)" in full before subsequent shorthand use in both claims, curing the informalities identified in the prior Office action.
The rejection of Claims 19 and 20 under 35 U.S.C. § 112(b) has been rendered moot by Applicant's amendment, which corrected claims 19 and 20 to depend from claim 18 as "The computing device of claim 18" rather than "the computer-implemented method of claim 18," resolving the claim-type/antecedent mismatch identified in the prior Office action. The rejection under 35 U.S.C. § 112(d) has also been rendered moot by the same amendment, which added recitation of "the at least one memory and the computer code configured to, with the at least one processor, cause the computing device to perform operations" to claims 19 and 20, such that each now incorporates all limitations of claim 18, including the apparatus elements.
Response to Arguments
Applicant's arguments filed 2026/06/17 have been fully considered but they are not persuasive.
On page 2 of the Remarks, Applicant argues that claims 1, 7, 12, and 18 integrate the abstract idea into a practical application because the recited operations of instructing the charging station to implement the charging profile, set/reset the timer, and implement the default profile at timer expiry mean that "the charging station carries out the fallback behavior and changes its charging behavior under defined operating conditions," and that the specification supports that this behavior is applied locally to "avoid unsafe charging and over-current scenarios." Applicant further states that "the same eligibility reasoning applies" to claims 7 and 18.
Under § 2106.04(d)(1), an asserted improvement must be reflected in the claim language itself; a benefit disclosed only in the specification does not integrate a judicial exception into a practical application. Under MPEP § 2111.01, claims are given their broadest reasonable interpretation and are not limited by details appearing only in the specification.
Claims 1, 7, 12, and 18 recite only that the charging station "implement[s]" a charging profile, "set[s]"/"reset[s]" a timer, and "implement[s] a default profile" upon expiration of that timer — functional, result-oriented steps carried out using the generic "at least one processor" and "at least one memory including computer program code" addressed in the prior office action. None of the four independent claims recites communication loss, an over-current condition, or any other technical problem; those details appear only in the specification and in Applicant's remarks, not in the claims. An unclaimed benefit cannot supply the practical application MPEP § 2106.04(d)(1) requires. Considered as an ordered combination, the claims still do no more than apply the identified abstract concepts using generic computer components invoked as a tool.
Thus, these remarks are not persuasive.
On page 3 – 4 of the Remarks, Applicant argues that SAMOJEDEN is silent as to any time-limited enforceability of charging profiles or station-side default behavior triggered by expiry, and that OCPP 2.0.1, "[e]ven if individual protocol elements relating to profile validity or replacement are disclosed therein," provides no teaching or suggestion to modify SAMOJEDEN to implement "a safety-oriented expiry-enforcement scheme," such that a prima facie case of obviousness has not been established.
Under MPEP § 2143(I)(A) and § 2145(IV), combining known prior art elements according to their established functions to yield a predictable result supports a prima facie case, and an applicant cannot rebut a combination rejection by arguing a reference in isolation.
Applicant's argument attacks OCPP 2.0.1 individually rather than addressing the combination the rejection actually relies upon. Applicant asks whether OCPP 2.0.1, standing alone, supplies an explicit teaching or suggestion to modify SAMOJEDEN — but the correct inquiry under MPEP § 2145(IV) is what the combined teachings of SAMOJEDEN and OCPP 2.0.1 would have suggested to a PHOSITA, not whether either reference in isolation states the modification. SAMOJEDEN discloses the underlying server-to-charger profile framework (¶¶[0038]–[0040]); OCPP 2.0.1 supplies the missing expiry, timer-enforcement, and default-fallback features (K01.FR.37, p. 235; Section 3.2, p. 228); and a PHOSITA would have been motivated to combine them for the reason OCPP 2.0.1 itself states for its offline-behavior provisions (K07, Objective, p. 246: 'to enable the Charging Station to continue to use a ChargingProfile for a transaction which is started Offline'). Applicant's remarks do not address this combination-based rationale.
Thus, these remarks are not persuasive.
On page 4 of the Remarks, Applicant argues that the OCPP provisions cited for offline default behavior describe execution "as if no constraints apply," which "merely reflects the absence of any actively enforced charging profile" and does not correspond to or suggest "a deliberately defined default profile as claimed."
MPEP § 2112, 2131 govern what a reference's technical content discloses. MPEP § 2111.01 governs the broadest reasonable interpretation of the claim term at issue ("default profile").
This argument is directed to K06.FR.02 (p. 246), which was the only OCPP citation the prior Office action relied on for the "default profile" limitations. Applicant is correct that K06.FR.02, which addresses a Charging Station that goes offline without having received any charging profile at all, describes the absence of an enforced profile rather than a "default profile." On further review of OCPP 2.0.1, however, the reference discloses a "default profile" by that name: Section 3.2 (p. 228) defines the ChargingProfilePurpose value TxDefaultProfile as "[d]efault schedules for new transactions," and states that a transaction-specific TxProfile "overrules the default charging profile with purpose TxDefaultProfile for the duration of the current transaction only" — using the term "default" in the reference's own words, not merely in the examiner's characterization. Section 3.6 (p. 230) further illustrates a TxDefaultProfile-purposed ChargingProfile as "a daily default profile." K01.FR.13 (p. 234) additionally provides that the Charging Station "SHALL fall back to default behavior after ChargingSchedule duration ends" once a governing schedule's defined duration lapses. This is a materially better fit for "implement a default profile at the expiration of the timer" than K06.FR.02.
Applicant's argument is persuasive as to the sufficiency of the K06.FR.02 citation specifically, yet not persuasive as to the broader conclusion that OCPP 2.0.1 fails to disclose a default profile. The rejection is maintained, modified to rely on OCPP 2.0.1 Section 3.2 (p. 228), Section 3.6 (p. 230), and K01.FR.13 (p. 234) in place of K06.FR.02 for the "default profile" limitations of claims 1, 4, 5, 6, 7, 10, 12, 15, 16, and 18. This modification relies on the same two references and the same underlying combination rationale as the prior Office action and is accordingly not a new ground of rejection (See MPEP §706.07(a)).
On page 4 of the Remarks, Applicant argues that OCPP's rule governing replacement of a charging profile upon receipt of a further profile with the same identifier "does not amount to, and does not suggest, the claimed expiry-enforcement mechanism in which continued communication actively maintains profile validity, whereas loss of communication leads to expiry and default behavior."
Under MPEP § 2111.01, claims are given their broadest reasonable interpretation.
Under the broadest reasonable interpretation (BRI), replacing an existing ChargingProfile, including its governing validTo value, with a newly received ChargingProfile of the same identifier functionally resets which validity period governs the profile's expiration (K01.FR.05, p. 234), because the newly received profile's own validTo now controls when the profile lapses (K01.FR.37, p. 235). Periodic re-sending of a profile under K01.FR.05, combined with the validTo mechanism of K01.FR.37, requires the receiving station to reassess when the currently governing profile expires each time a replacement is received. Applicant's characterization of this as "a rule governing profile replacement" rather than "resetting a timer" identifies a difference in terminology, not in substance, and does not overcome the rejection under BRI.
Thus, these remarks are not persuasive.
Claim Rejections - 35 USC § 101
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior office action.
Claims 1 – 20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to patent-ineligible subject matter.
Step 1
Claims 1–11 are directed to a computer-implemented method without significantly more. Claims 12–20 are directed to a computing device without significantly more. Thus, the claims are directed to a process and a machine, each of which is one of the statutory categories of invention.
Step 2A, Prong 1
Regarding claims 1 and 12, representative claim 12 recites:
receiving a notification of an event related to a charging session at a charging station, the charging station being subjected to load management; [the examiner finds that the foregoing element recites a certain method of organizing human activity because it defines a triggering condition governing the initiation of commercial resource management activity between networked systems]
calculating an available charging current at the charging station; [the examiner finds that the foregoing element recites a mathematical concept because it involves applying mathematical relationships to numerical inputs to derive a numerical current value from available supply and load data]
determining a charging profile for the charging station based on the available charging current at the charging station; [the examiner finds that the foregoing elements recite a mathematical concept because they involve mapping a derived numerical current value to a set of charging parameters to produce a defined output]
sending the charging profile to the charging station, wherein the charging profile is configured to expire after a predefined amount of time; [the examiner finds that the foregoing elements recite a certain method of organizing human activity because they specify rules governing the dispatch and temporal validity of the charging resource allocation — a method of organizing commercial resource management activity between networked systems]
instructing the charging station to implement the charging profile, set a timer with the predefined amount of time, and implement a default profile at the expiration of the timer; [the examiner finds that the foregoing elements recite a certain method of organizing human activity because they define rules governing how charging resources are allocated, enforced, and recovered — a method of organizing commercial resource management activity between networked systems]
re-sending the charging profile to the charging station; [the examiner finds that the foregoing element recites a certain method of organizing human activity because it specifies a rule governing the periodic refresh of the charging resource allocation]
instructing the charging station to reset the timer each time the charging profile is re-sent; [the examiner finds that the foregoing element recites a certain method of organizing human activity because it specifies a rule governing timer reset upon each re-send of the charging profile]
Step 2A, Prong 2
This judicial exception is not integrated into a practical application because
the following additional elements merely use a computer as a tool to perform the abstract idea: "computer-implemented method"; "at least one processor; and at least one memory including computer program code; the at least one memory and the computer code configured to, with the at least one processor, cause the computing device to perform operations comprising." The claims invoke computers merely as a tool to execute the abstract load management rules; the computer does not impose any meaningful limit on the practice of the abstract idea.
the following additional elements do no more than generally link the use of the abstract idea to a particular technological environment or field of use: "a charging session"; "the charging station being subjected to load management." These limitations confine the abstract ideas to the EV charging context but do not alter the nature of those ideas or amount to significantly more than the exception itself.
Step 2B
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements do not integrate the abstract idea into a practical application. Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually.
Claims 2 and 13 recite
wherein re-sending the charging profile comprises re-sending the charging profile at a regular interval.
The limitation simply further defines the abstract idea — it adds only a frequency parameter to the already-abstract re-sending rule — and, thus, does not make the abstract idea any less abstract. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because they are merely incidental or token additions to the claims that do not alter or affect how the process steps are performed.
Claims 3, 9, and 14 recite
wherein the event is a new charging session or an end of a charging session.
The limitation simply further defines the abstract idea — it narrows which events qualify under the abstract triggering condition without tying the claims to any concrete practical application — and, thus, does not make the abstract idea any less abstract. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because they are merely incidental or token additions to the claims that do not alter or affect how the process steps are performed.
Claims 4 and 15 recite
wherein the default profile is set to a minimum power.
The limitation simply further defines the abstract idea — it specifies a numerical boundary value for the output of the abstract fallback rule — and, thus, does not make the abstract idea any less abstract. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because they are merely incidental or token additions to the claims that do not alter or affect how the process steps are performed.
Claims 5 and 16 recite
wherein the minimum power is zero.
The limitation simply further defines the abstract idea — it assigns a specific numerical value to the fallback charging parameter defined in the parent claim — and, thus, does not make the abstract idea any less abstract. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because they are merely incidental or token additions to the claims that do not alter or affect how the process steps are performed.
Claims 6 and 17 recite
receiving a notification of a new event at the charging station;
calculating a new available charging current at the charging station;
determining a new charging profile for the charging station based on the new available charging current at the charging station;
sending the new charging profile to the charging station, wherein the new charging profile is configured to expire after a predefined amount of time;
instructing the charging station to implement the new charging profile, and reset the timer with the predefined amount of time;
re-sending the new charging profile to the charging station;
and instructing the charging station to reset the timer each time the new charging profile is re-sent.
The limitations simply further define the abstract idea — they reiterate the identical abstract load management framework for a subsequent triggering event without introducing any concrete element — and, thus, do not make the abstract idea any less abstract. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because they are merely incidental or token additions to the claims that do not alter or affect how the process steps are performed.
Step 2A, Prong 1
Regarding claims 7 and 18, representative claim 18 recites:
detecting an event related to a charging session at a charging station subjected to load management; [the examiner finds that the foregoing element recites a certain method of organizing human activity because it defines a triggering condition governing the initiation of commercial resource management activity between networked systems]
sending a notification to a Charging Point Management System (CPMS); [the examiner finds that the foregoing element recites a certain method of organizing human activity because it specifies a rule governing communication of charging session events to the central resource management system]
receiving a charging profile from the CPMS, wherein the charging profile is configured to expire after a predefined amount of time; [the examiner finds that the foregoing elements recite a certain method of organizing human activity because they specify rules governing the receipt and temporal validity of the charging resource allocation — a method of organizing commercial resource management activity between networked systems]
implementing the charging profile at the charging station; [the examiner finds that the foregoing element recites a certain method of organizing human activity because it specifies a rule governing execution of the received charging resource allocation at the station]
setting a timer with the predefined amount of time; [the examiner finds that the foregoing element recites a certain method of organizing human activity because it specifies a rule governing time-limited enforcement of the charging resource allocation]
resetting the timer each time the charging profile is received again from the CPMS; [the examiner finds that the foregoing element recites a certain method of organizing human activity because it specifies a rule governing timer reset upon re-receipt of the charging profile.]
implementing a default profile at the charging station at the expiration of the timer; [the examiner finds that the foregoing element recites a certain method of organizing human activity because it specifies a rule governing fallback to safe default charging behavior upon expiration of the active profile's validity window]
Step 2A, Prong 2
This judicial exception is not integrated into a practical application because
the following additional elements merely use a computer as a tool to perform the abstract idea: "at least one processor; and at least one memory including computer program code; the at least one memory and the computer code configured to, with the at least one processor, cause the computing device to perform operations comprising." The claims invoke computers merely as a tool to execute the abstract load management rules; the computer does not impose any meaningful limit on the practice of the abstract idea.
the following additional elements do no more than generally link the use of the abstract idea to a particular technological environment or field of use: "a charging station subjected to load management." This limitation confines the abstract ideas to the EV charging context but does not alter the nature of those ideas or amount to significantly more than the exception itself.
Step 2B
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements do not integrate the abstract idea into a practical application. Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually.
Claims 8 and 19 recite
wherein the default profile is stored at the charging station.
The limitation simply further defines the abstract idea — it specifies an operational detail of the abstract fallback rule governing where the default configuration resides within the resource management framework — and, thus, does not make the abstract idea any less abstract. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because they are merely incidental or token additions to the claims that do not alter or affect how the process steps are performed.
Claim 10 recites
wherein the default profile is set to a minimum power or to zero power.
The limitation simply further defines the abstract idea — it specifies a numerical boundary value, or the specific value of zero, for the output of the abstract fallback rule — and, thus, does not make the abstract idea any less abstract. The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because it is merely an incidental or token addition to the claims that does not alter or affect how the process steps are performed.
Claims 11 and 20 recite
detecting a new event at the charging station; sending a new notification to the CPMS;
receiving a new charging profile from the CPMS, wherein the new charging profile is configured to expire after the predefined amount of time;
implementing the new charging profile at the charging station;
and resetting the timer each time the new charging profile is received from the CPMS.
The limitations simply further define the abstract idea — they reiterate the identical abstract load management framework for a subsequent triggering event on the station side without introducing any concrete element — and, thus, do not make the abstract idea any less abstract. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because they are merely incidental or token additions to the claims that do not alter or affect how the process steps are performed.
Claim Rejections - 35 USC § 103
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior office action.
Claims 1 – 20 are rejected under 35 U.S.C. 103 as being unpatentable over SAMOJEDEN et al. (US 2018/0334040 A1), and in view of OCPP 2.0.1 (Open Charge Alliance, Open Charge Point Protocol 2.0.1, Part 2 — Specification, FINAL, Mar. 31, 2020).
Regarding claims 1 and 12, SAMOJEDEN discloses receiving a notification of an event related to a charging session at a charging station, the charging station being subjected to load management (see Par. [0038]: “The plurality of EV chargers 130 communicate with the server 510 over the communication network 160 to provide the charging information.”)
SAMOJEDEN further discloses calculating an available charging current at the charging station (see Par. [0039]: “The server 510 analyzes the charging information received from the plurality of EV chargers 130 within the geographic boundary to optimize the load on the power grid 120 … The server 510 analyzes the charging information received from the plurality of EV chargers 130 to delay and distribute the load across the plurality of EV chargers 130 within the geographic boundary.”)
Furthermore, SAMOJEDEN discloses determining a charging profile for the charging station based on the available charging current at the charging station (see Par. [0039]: “The server 510 generates a charging profile for each of the plurality of EV chargers 130 based on the charging information received from the plurality of EV chargers 130. The charging profile may include … the amount of current draw (i.e., charge rating) the EV charger 130 should use … The charging profiles are generated to minimize the load on the power grid 120.”)
SAMOJEDEN further discloses sending the charging profile to the charging station, instructing the charging station to implement the charging profile, and re-sending the charging profile to the charging station (see Par. [0040]: “The server 510 transmits a charging profile assigned to a particular EV charger 130 to that EV charger 130 over the communication network 160. The EV charger 130 implements the charging profile upon receiving the charging profile 160 from the server 510.”)
Furthermore, SAMOJEDEN discloses a computing device comprising at least one processor and at least one memory including computer program code configured to perform the operations recited in claim 12 (see Par. [0034]–[0035]: “the EV charger 130 includes a server electronic processor 610, a server memory 620, a server transceiver 630 … The server memory 620 may store instructions that are received and executed by the server electronic processor 610 to carry out the functionality described herein.”)
SAMOJEDEN is silent to wherein the charging profile is configured to expire after a predefined amount of time, set a timer with the predefined amount of time, implement a default profile at the expiration of the timer, and instructing the charging station to reset the timer each time the charging profile is re-sent.
OCPP 2.0.1 discloses wherein the charging profile is configured to expire after a predefined amount of time (see ChargingProfileType, field validTo, p. 373: “Optional. Point in time at which the profile stops to be valid. If absent, the profile is valid until it is replaced by another profile.”)
OCPP 2.0.1 further discloses set a timer with the predefined amount of time (see K01.FR.37: “When validTo of a ChargingProfile is set, the Charging Station SHALL consider the ChargingProfile to be valid when current time < validTo.”)
Furthermore, OCPP 2.0.1 discloses implement a default profile at the expiration of the timer (see Section 3.2, p. 228: TxDefaultProfile definition); see Section 3.6, p. 230: illustrative "daily default profile"); see K01.FR.13, p. 234: "fall back to default behavior after ChargingSchedule duration ends")
OCPP 2.0.1 further discloses instructing the charging station to reset the timer each time the charging profile is re-sent (see K01.FR.05: “When a SetChargingProfileRequest with an already known ChargingProfile.id is received, the Charging Station SHALL replace the existing ChargingProfile with the one specified.”)
It would have been obvious for a PHOSITA to incorporate OCPP 2.0.1’s SetChargingProfile validity period and fallback behavior into SAMOJEDEN’s server-to-charger profile transmission framework, to provide communication-loss resilience by ensuring that charging stations revert to safe default charging behavior when CSMS contact is interrupted and no valid profile remains active, and to enable the Charging Station to continue to use a ChargingProfile for a transaction which is started offline. Such a combination would result in a system that sends a charging profile configured to expire after a predefined amount of time, instructs the charging station to set a timer and implement a default profile upon expiration, and instructs the charging station to reset the timer upon each re-send of the profile.
Regarding claims 2 and 13, SAMOJEDEN does not explicitly disclose wherein re-sending the charging profile comprises resending the charging profile at a regular interval (see Par. [0040]: “The server 510 transmits a charging profile assigned to a particular EV charger 130 to that EV charger 130 over the communication network 160.”)
It would have been obvious for a PHOSITA to implement SAMOJEDEN’s periodic profile retransmission at a fixed regular interval into SAMOJEDEN’s server-to-charger profile framework, to reliably maintain the validity window established by OCPP 2.0.1’s validTo mechanism and prevent inadvertent profile expiration during continuous charging operations.
Regarding claims 3, 9, and 14, SAMOJEDEN does not explicitly disclose wherein the event is a new charging session or an end of a charging session (see Par. [0038]: “The plurality of EV chargers 130 communicate with the server 510 over the communication network 160 to provide the charging information. The charging information includes, for example, … a state of charge of an electric vehicle 140 being charged by the EV charger 130 …”)
Regarding claims 4 and 15, SAMOJEDEN is silent to wherein the default profile is set to a minimum power.
OCPP 2.0.1 discloses wherein the default profile is set to a minimum power (see ChargingSchedulePeriodType, field limit, p. 373: “Required. Charging rate limit during the schedule period, in the applicable chargingRateUnit, for example in Amperes (A) or Watts (W). Accepts at most one digit fraction (e.g. 8.1).”)
It would have been obvious for a PHOSITA to configure the default fallback profile in SAMOJEDEN’s charging station framework to a minimum power level, to protect grid infrastructure from uncontrolled load while permitting continued charging at a safe reduced rate upon loss of CSMS communication.
Regarding claims 5 and 16, SAMOJEDEN is silent to wherein the minimum power is zero.
OCPP 2.0.1 discloses a charging rate limit value of zero as a valid parameter (see ChargingSchedulePeriodType, field limit, p. 373: “Required. Charging rate limit during the schedule period, in the applicable chargingRateUnit, for example in Amperes (A) or Watts (W). Accepts at most one digit fraction (e.g. 8.1).”)
It would have been obvious for a PHOSITA to set the minimum power of the default fallback profile in SAMOJEDEN’s charging station framework to zero, to immediately halt charging upon loss of CSMS communication and thereby eliminate any uncontrolled load on the electrical distribution network.
Regarding claims 6 and 17, SAMOJEDEN discloses receiving a notification of a new event at the charging station (see Par. [0038]: “The plurality of EV chargers 130 communicate with the server 510 over the communication network 160 to provide the charging information.”)
SAMOJEDEN further discloses calculating a new available charging current at the charging station (see Par. [0039]: “The server 510 analyzes the charging information received from the plurality of EV chargers 130 within the geographic boundary to optimize the load on the power grid 120 … The server 510 analyzes the charging information received from the plurality of EV chargers 130 to delay and distribute the load across the plurality of EV chargers 130 within the geographic boundary.”)
Furthermore, SAMOJEDEN discloses determining a new charging profile for the charging station based on the new available charging current at the charging station (see Par. [0039]: “The server 510 generates a charging profile for each of the plurality of EV chargers 130 based on the charging information received from the plurality of EV chargers 130. The charging profile may include … the amount of current draw (i.e., charge rating) the EV charger 130 should use … The charging profiles are generated to minimize the load on the power grid 120.”)
SAMOJEDEN further discloses sending the new charging profile to the charging station, instructing the charging station to implement the new charging profile, and re-sending the new charging profile to the charging station (see Par. [0040]: “The server 510 transmits a charging profile assigned to a particular EV charger 130 to that EV charger 130 over the communication network 160. The EV charger 130 implements the charging profile upon receiving the charging profile 160 from the server 510.”)
SAMOJEDEN is silent to wherein the new charging profile is configured to expire after a predefined amount of time, reset the timer with the predefined amount of time, and instructing the charging station to reset the timer each time the new charging profile is re-sent.
OCPP 2.0.1 discloses wherein the new charging profile is configured to expire after a predefined amount of time (see ChargingProfileType, field validTo, p. 373: “Optional. Point in time at which the profile stops to be valid. If absent, the profile is valid until it is replaced by another profile.”)
OCPP 2.0.1 further discloses reset the timer with the predefined amount of time (see K01.FR.37: “When validTo of a ChargingProfile is set, the Charging Station SHALL consider the ChargingProfile to be valid when current time < validTo.”)
Furthermore, OCPP 2.0.1 discloses instructing the charging station to reset the timer each time the new charging profile is re-sent (see K01.FR.05: “When a SetChargingProfileRequest with an already known ChargingProfile.id is received, the Charging Station SHALL replace the existing ChargingProfile with the one specified.”)
It would have been obvious for a PHOSITA to incorporate OCPP 2.0.1’s SetChargingProfile validity period and fallback behavior into SAMOJEDEN’s server-to-charger profile transmission framework, to provide communication-loss resilience by ensuring that charging stations revert to safe default charging behavior when CSMS contact is interrupted and no valid profile remains active, and to enable the Charging Station to continue to use a ChargingProfile for a transaction which is started offline. Such a combination would result in a system that sends a charging profile configured to expire after a predefined amount of time, instructs the charging station to set a timer and implement a default profile upon expiration, and instructs the charging station to reset the timer upon each re-send of the profile.
Regarding claims 7 and 18, SAMOJEDEN discloses detecting an event related to a charging session at a charging station subjected to load management (see Par. [0038]: “The plurality of EV chargers 130 communicate with the server 510 over the communication network 160 to provide the charging information. The charging information includes, for example, … a state of charge of an electric vehicle 140 being charged by the EV charger 130 …”)
SAMOJEDEN further discloses sending a notification to a Charging Point Management System (CPMS) (see Par. [0038]: “The plurality of EV chargers 130 communicate with the server 510 over the communication network 160 to provide the charging information.”)
Furthermore, SAMOJEDEN discloses receiving a charging profile from the CPMS, and implementing the charging profile at the charging station (see Par. [0040]: “The EV charger 130 implements the charging profile upon receiving the charging profile 160 from the server 510.”)
SAMOJEDEN further discloses a computing device comprising at least one processor and at least one memory including computer program code configured to perform the operations recited in claim 18 (see Par. [0018]–[0019]: “the EV charger 130 includes an electronic processor 210, a memory 220, a transceiver 230, and a charging circuit 240 … the memory 220 includes non-transitory, computer-readable memory that stores instructions that are received and executed by the electronic processor 210 to carry out functionality of the EV charger 130 described herein.”)
SAMOJEDEN is silent to wherein the charging profile is configured to expire after a predefined amount of time, setting a timer with the predefined amount of time, resetting the timer each time the charging profile is received again from the CPMS, and implementing a default profile at the charging station at the expiration of the timer.
OCPP 2.0.1 discloses wherein the charging profile is configured to expire after a predefined amount of time (see ChargingProfileType, field validTo, p. 373: “Optional. Point in time at which the profile stops to be valid. If absent, the profile is valid until it is replaced by another profile.”)
OCPP 2.0.1 further discloses setting a timer with the predefined amount of time (see K01.FR.37: “When validTo of a ChargingProfile is set, the Charging Station SHALL consider the ChargingProfile to be valid when current time < validTo.”)
Furthermore, OCPP 2.0.1 discloses resetting the timer each time the charging profile is received again from the CPMS (see K01.FR.05: “When a SetChargingProfileRequest with an already known ChargingProfile.id is received, the Charging Station SHALL replace the existing ChargingProfile with the one specified.”)
OCPP 2.0.1 further discloses implementing a default profile at the charging station at the expiration of the timer (see K01.FR.37: “When validTo of a ChargingProfile is set, the Charging Station SHALL consider the ChargingProfile to be valid when current time < validTo.”; see Section 3.2, p. 228: TxDefaultProfile definition); see Section 3.6, p. 230: illustrative "daily default profile"); see K01.FR.13, p. 234: "fall back to default behavior after ChargingSchedule duration ends")
It would have been obvious for a PHOSITA to incorporate OCPP 2.0.1’s SetChargingProfile validity period and fallback behavior into SAMOJEDEN’s station-side profile implementation framework, to provide communication-loss resilience by ensuring that the charging station maintains safe default charging behavior upon expiration of the active profile’s validity window, and to enable the Charging Station to continue to use a ChargingProfile for a transaction which is started offline. Such a combination would result in a system in which the charging station receives a charging profile configured to expire, sets a timer based on the expiration, resets the timer upon re-receipt of the profile, and implements a default profile upon timer expiration.
Regarding claims 8 and 19, SAMOJEDEN is silent to wherein the default profile is stored at the charging station.
OCPP 2.0.1 discloses wherein the default profile is stored at the charging station (see K01.FR.27: “ChargingProfiles set via SetChargingProfileRequest SHALL be persistent across reboots/power cycles.”; see K07.FR.01: “If a Charging Station goes Offline before a transaction is started or before a transaction-specific ChargingProfile with purpose TxProfile was received, the Charging Station SHALL use the charging profiles which are available.”)
K01.FR.27 requires all installed profiles to be persisted locally on the Charging Station. K07.FR.01 confirms the station draws upon locally stored profiles when offline, establishing that the default fallback profile is stored at the station. It would have been obvious for a PHOSITA to rely upon SAMOJEDEN’s charging station’s locally stored OCPP profiles as the default fallback configuration, to ensure that safe charging behavior is applied upon CSMS communication loss without requiring a live connection to retrieve the profile.
Regarding claim 10, SAMOJEDEN is silent to wherein the default profile is set to a minimum power or to zero power.
OCPP 2.0.1 discloses a charging rate limit at a minimum power or zero power value (see ChargingSchedulePeriodType, field limit, p. 373: “Required. Charging rate limit during the schedule period, in the applicable chargingRateUnit, for example in Amperes (A) or Watts (W). Accepts at most one digit fraction (e.g. 8.1).”)
It would have been obvious for a PHOSITA to configure the station-side default fallback profile in SAMOJEDEN’s charging station framework to a minimum power or zero power level, for the same reasons established for claims 4, 5, 15, and 16 above.
Regarding claims 11 and 20, SAMOJEDEN discloses detecting a new event at the charging station (see Par. [0038]: “The plurality of EV chargers 130 communicate with the server 510 over the communication network 160 to provide the charging information. The charging information includes, for example, … a state of charge of an electric vehicle 140 being charged by the EV charger 130 …”)
SAMOJEDEN further discloses sending a new notification to the CPMS (see Par. [0038]: “The plurality of EV chargers 130 communicate with the server 510 over the communication network 160 to provide the charging information.”)
Furthermore, SAMOJEDEN discloses receiving a new charging profile from the CPMS, and implementing the new charging profile at the charging station (see Par. [0040]: “The EV charger 130 implements the charging profile upon receiving the charging profile 160 from the server 510.”)
SAMOJEDEN is silent to wherein the new charging profile is configured to expire after the predefined amount of time, and resetting the timer each time the new charging profile is received from the CPMS.
OCPP 2.0.1 discloses wherein the new charging profile is configured to expire after the predefined amount of time (see ChargingProfileType, field validTo, p. 373: “Optional. Point in time at which the profile stops to be valid. If absent, the profile is valid until it is replaced by another profile.”)
OCPP 2.0.1 further discloses resetting the timer each time the new charging profile is received from the CPMS (see K01.FR.05: “When a SetChargingProfileRequest with an already known ChargingProfile.id is received, the Charging Station SHALL replace the existing ChargingProfile with the one specified.”)
It would have been obvious for a PHOSITA to incorporate OCPP 2.0.1’s SetChargingProfile validity period and profile replacement behavior into SAMOJEDEN’s station-side profile implementation framework, to provide communication-loss resilience by ensuring that the charging station maintains safe default charging behavior upon expiration of the active profile’s validity window, and to enable the Charging Station to continue to use a ChargingProfile for a transaction which is started offline. Such a combination would result in a system in which the charging station receives a new charging profile configured to expire, and resets the timer upon re-receipt of the profile.
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 JOHANN DJANAL-MANN whose telephone number is (571)272-4697. The examiner can normally be reached Monday - Thursday 8:00 - 17:00.
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, Drew Dunn can be reached at (571) 272-2312. 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.
/D. JOHANN DJANAL-MANN/Examiner, Art Unit 2859
/DREW A DUNN/Supervisory Patent Examiner, Art Unit 2859
Prosecution Insights