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 .
Status of Claims
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/03/2025 has been entered.
This application 18/199,039 claims earliest priority from provisional application 63343820 filed 05/19/2022.
Claims 1, 4, 11 and 20 have been amended.
Claims 3, 4 and 14-15 have been canceled.
Claims 1, 11 & 20 being independent claims and claims 2, 4-10, 12-13, and 15-19 being dependent.
Claims 1-2, 5-13 and 16-20 are currently pending and have been examined.
Response to Arguments
Applicant's arguments filed 12/03/2025 have been fully considered but they are not persuasive.
With respect to arguments under 35 USC 101, the arguments have been fully considered, however, the examiner respectfully disagrees.
Streamlined Eligibility Analysis
Applicant asserts that independent Claims 1, 11, and 20 qualify for the streamlined eligibility analysis under MPEP § 2106.06(a). Examiner respectfully disagrees. The streamlined eligibility analysis is reserved for claims whose eligibility is self-evident when viewed as a whole. In the present case, the claims recite and focus on receiving payment value, determining whether a user input correlates with stored customer identifiers, issuing or crediting vouchers, and managing remaining balance value for future use. These features constitute transaction processing and credit management activities that are not self-evidently patent eligible and therefore require a full subject matter eligibility analysis under Step 2A and Step 2B. Accordingly, streamlined eligibility analysis is not appropriate.
Step 2A, Prong One
Applicant argues that the claims do not recite an abstract idea and are not directed to any recognized sub-grouping of methods of organizing human activity. Examiner respectfully disagrees. When the claims are considered as a whole, they are directed to managing a fueling transaction by receiving payment value, determining whether the payment is associated with a customer identifier, and issuing or crediting a voucher based on that determination. Such activities constitute commercial transaction management and payment processing, which fall within the category of certain methods of organizing human activity, including fundamental economic practices and commercial interactions, as recognized by USPTO guidance and relevant case law. The recitation of physical components such as a gasoline pumping assembly or voucher dispenser does not alter the abstract nature of the underlying concept. Therefore, the claims recite an abstract idea under Step 2A, Prong One.
Step 2A, Prong Two
Applicant contends that the claims integrate any alleged abstract idea into a practical application. Examiner respectfully disagrees.
Applicant asserts that the claimed arrangement of elements is not generic and is not disclosed by the cited references. However, eligibility under § 101 does not depend on whether the exact combination of elements is disclosed in the prior art. Rather, the inquiry is whether the additional elements integrate the abstract idea into a practical application. In the present claims, conventional components such as a database, user interface, processing circuit, coin receiver, and voucher dispenser are recited at a high-level of generality and are used to perform their ordinary functions to implement the abstract transaction-management concept. This does not constitute meaningful integration.
Applicant further asserts that the claims improve technology, specifically the field of fueling processes and operations. Examiner respectfully disagrees. The claims do not recite any improvement to the operation of a gasoline dispenser, fueling mechanism, or computer functionality itself. Instead, the alleged improvements relate to how payment overages are tracked and credited, which is an improvement to a commercial or business process rather than a technological improvement as contemplated by MPEP § 2106.05(a).
Applicant also argues that the abstract idea is integrated with a particular machine. Examiner respectfully disagrees. While the claims recite a gasoline pumping assembly and related hardware, the abstract idea is merely performed in the context of that environment. The machine itself is not improved nor does it impose a meaningful limitation on the abstract idea beyond serving as a field-of-use. Implementing an abstract idea on a particular machine, without more, does not integrate the idea into a practical application.
Applicant further contends that the claimed hopper allows safer and more efficient coin deposit from a vehicle, thereby improving safety. Examiner respectfully notes that such statements describe intended results or benefits rather than specific technical features recited in the claims. The claims do not recite any non-conventional safety mechanism or technical modification that effects such improvements. Intended benefits alone do not constitute integration into a practical application.
Applicant additionally argues that the claims solve operational problems such as coin overpayment by issuing vouchers tied to customer identifiers. Examiner respectfully finds that this solution merely reflects an abstract accounting or credit-tracking concept implemented using conventional computing components. Such implementation does not integrate the abstract idea into a practical application under Step 2A, Prong Two.
Accordingly, the claims do not integrate the abstract idea into a practical application.
Step 2B
Applicant asserts that the claims amount to significantly more than any alleged abstract idea. Examiner respectfully disagrees.
The additional elements recited in the claims, including operating a voucher assembly, receiving coins, determining whether user input correlates with stored identifiers, and issuing or crediting vouchers, are routine and conventional activities when viewed individually and in combination. These elements merely automate or computerize a commercial transaction using generic computing components and standard payment hardware. Distinguishing between steps of “determining” and “providing” does not add an inventive concept, as these steps collectively describe the abstract process itself rather than a technological improvement.
Applicant further contends that the combination of elements is unconventional and not well-understood, routine, or conventional. However, the claims rely on generic processors, databases, user interfaces, and transaction hardware performing their ordinary functions. Assertions that the cited references do not disclose the same combination are more appropriately directed to novelty or obviousness under §§ 102 and 103 and do not establish an inventive concept for purposes of § 101.
Therefore, the claims do not recite additional elements sufficient to amount to significantly more than the abstract idea.
Conclusion
For the foregoing reasons, independent Claims 1, 11, and 20 are directed to an abstract idea and do not integrate that idea into a practical application under Step 2A, nor do they recite significantly more under Step 2B. Claims 2, 4-10, 12-13, and 15-19 depend therefrom and fall with their respective independent claims. Accordingly, the rejection of Claims 1-2, 5-13 and 16-20 under 35 U.S.C. § 101 is maintained.
With respect to arguments under 35 U.S.C.
§
103, the arguments have been fully considered, however, the examiner respectfully disagrees.
Applicant argues neither Bruskotter or Clithero disclose:
a database communicably coupled to the user interface, the database comprising a plurality of customer identifiers;
a processing circuit communicably coupled to the database and the user interface, the processing circuit comprising one or more processors configured to determine if the user input correlates with at least one of the plurality of customer identifiers, wherein if the user input does not correlate with the at least one of the plurality of customer identifiers, the voucher dispenser provides to the user the remaining balance via a voucher by generating a new voucher with a new customer identifier; and
wherein if the user input does correlate with the at least one of the plurality of customer identifiers the voucher dispenser provides to the user the remaining balance via a voucher by applying the remaining balance to a pre-existing voucher already associated with the at least one of the plurality of customer identifiers.
However, Bruskotter ¶¶ [10, 26, 36, 38 & 47] disclose:
“The balance code can be, for example, embedded in a machine readable ticket, displayed to the customer on a monitor, or printed on a receipt. The change dispenser includes a code processor and a customer input device such as a ticket slot, keyboard or the like. The code processor receives a code from the customer via the customer input device, and the dispenser dispenses change to the customer based on the code and coded balance information stored in a database. This coded control of the change dispenser allows customers to choose between cashing in any balance due or saving the balance for application towards a subsequent fueling transaction, and also provides improved filling station configuration and servicing options… if a balance is due, the control system generates (88) a code and associates the code with the balance due. The code can be generated by any suitable software such as random or modified random number generator (excluding previously used codes), or custom software for selecting predetermined codes from a code database. The control system relates the code to the corresponding balance and stores the code and balance in a coded balance data base that is indexed by code. In this manner, the coded balance information can be transmitted (92) to the change machine in response to a code input by the user… Once the customer has received the code, the customer may either retain the code and receive credit for the balance due in a subsequent fueling transaction at a site within the automated filling station network, or the customer may proceed with the code to the change dispenser system to receive change in the form of currency. FIG. 4 illustrates the change dispenser system related process. The process can be implemented by the customer in response to instructions and/or prompts displayed on the change dispenser system monitor. Upon approaching the change dispenser system, the customer initiates the change dispenser system process by entering the code supplied by the pump system e.g., by entering the code manually or, where available, by inserting a machine-readable voucher. The code is transmitted to the control system by the change dispenser system. The control system receives (94) the customer code input and retrieves (96) the coded balance information which has been stored (98) by the control system in computer memory. More particularly, the coded balance information is retrieved by searching (100) through the code indexed balance information data base based on the received code. If the code is found (102) and has not expired (104), then the change dispenser system dispenses (108) change in the form of currency in the amount indicated by the coded balance information. In this regard, it will be appreciated that network operators may desire to attach expiration dates to particular codes (e.g., 90 days after traction date) for bookkeeping purposes. If the code is not found, or is expired, an error message is displayed (106) to the customer and the process may be restarted… The remote computer center 212 may respond by transmitting a new balance or refund code to the customer for immediate or later use. As can be appreciated, the appropriateness of a refund may be verified by cross-checking the customer's original balance code (e.g., has it been previously dispensed) and/or the customer's fuel authorization code. With a refund code in hand, the customer may operate the change dispenser to obtain currency. If a continuing malfunction is experienced, the remote computer center 212 can relay this information to the service administrator 219 for correction of the problem.”
The above language read on a database communicably coupled to the user interface, the database comprising a plurality of customer identifiers.
Bruskotter ¶¶ [29, 37 & 38] disclose:
“… The code can then be used for fuel or, at a later date or separate machine, to obtain change. This may be accomplished in response to a malfunction signal generated by the quarter dispenser. Alternatively, one of the other coin dispensers, e.g., the nickel dispenser, may be used to dispense the appropriate amount of change to the customer. If a difference still remains between the dispensed amount and the amount owed, the customer will receive new code information that allows the change to be received at a later date… The code can be provided (90) to the customer in any suitable form. For example, the code can be printed on the transaction receipt that is reported to the customer. Alternatively, a code such as a password or character string can be displayed to the customer on the pump system monitor. As a further alternative, it is anticipated that the pump system may be provided with the capability to issue a ticket or voucher to the customer that includes optically or magnetically encoded information corresponding to a numeric or alphanumeric code… Once the customer has received the code, the customer may either retain the code and receive credit for the balance due in a subsequent fueling transaction at a site within the automated filling station network, or the customer may proceed with the code to the change dispenser system to receive change in the form of currency. FIG. 4 illustrates the change dispenser system related process. The process can be implemented by the customer in response to instructions and/or prompts displayed on the change dispenser system monitor. Upon approaching the change dispenser system, the customer initiates the change dispenser system process by entering the code supplied by the pump system e.g., by entering the code manually or, where available, by inserting a machine-readable voucher. The code is transmitted to the control system by the change dispenser system. The control system receives (94) the customer code input and retrieves (96) the coded balance information which has been stored (98) by the control system in computer memory. More particularly, the coded balance information is retrieved by searching (100) through the code indexed balance information data base based on the received code. If the code is found (102) and has not expired (104), then the change dispenser system dispenses (108) change in the form of currency in the amount indicated by the coded balance information. In this regard, it will be appreciated that network operators may desire to attach expiration dates to particular codes (e.g., 90 days after traction date) for bookkeeping purposes. If the code is not found, or is expired, an error message is displayed (106) to the customer and the process may be restarted”
The above language read on a processing circuit communicably coupled to the database and the user interface, the processing circuit comprising one or more processors configured to determine if the user input correlates with at least one of the plurality of customer identifiers, wherein if the user input does not correlate with the at least one of the plurality of customer identifiers, the voucher dispenser provides to the user the remaining balance via a voucher by generating a new voucher with a new customer identifier. The balance code in Bruskotter functions as a customer identifier because it uniquely associates a particular customer with a stored balance and enables subsequent retrieval and application of that balance for the same customer. Searching the code-indexed database based on the user’s entered code and determining whether a matching stored code exists constitutes determining whether the user input correlates with at least one of the plurality of customer identifiers. When the entered code is not found, Bruskotter generates a new balance or refund code, which corresponds to generating a new voucher with a new customer identifier. When the entered code is found and not expired, Bruskotter retrieves the coded balance and dispenses change or applies the balance, which corresponds to applying the remaining balance to a pre-existing voucher already associated with the customer identifier.
Bruskotter ¶¶ [10, 36, 38, 45 & 47] disclose:
“The balance code can be, for example, embedded in a machine readable ticket, displayed to the customer on a monitor, or printed on a receipt. The change dispenser includes a code processor and a customer input device such as a ticket slot, keyboard or the like. The code processor receives a code from the customer via the customer input device, and the dispenser dispenses change to the customer based on the code and coded balance information stored in a database. This coded control of the change dispenser allows customers to choose between cashing in any balance due or saving the balance for application towards a subsequent fueling transaction, and also provides improved filling station configuration and servicing options… Upon detecting the fueling complete signal, the control system communicates with the pump system to determine the transaction amount and compares (82) the payment amount to the transaction amount to determine whether a balance is due (84). If no balance is due, the control system will only generate a receipt (86) if requested by a customer, and the pump system related process is complete. On the other hand, if a balance is due, the control system generates (88) a code and associates the code with the balance due. The code can be generated by any suitable software such as random or modified random number generator (excluding previously used codes), or custom software for selecting predetermined codes from a code database. The control system relates the code to the corresponding balance and stores the code and balance in a coded balance data base that is indexed by code. In this manner, the coded balance information can be transmitted (92) to the change machine in response to a code input by the user… Once the customer has received the code, the customer may either retain the code and receive credit for the balance due in a subsequent fueling transaction at a site within the automated filling station network, or the customer may proceed with the code to the change dispenser system to receive change in the form of currency. FIG. 4 illustrates the change dispenser system related process. The process can be implemented by the customer in response to instructions and/or prompts displayed on the change dispenser system monitor. Upon approaching the change dispenser system, the customer initiates the change dispenser system process by entering the code supplied by the pump system e.g., by entering the code manually or, where available, by inserting a machine-readable voucher. The code is transmitted to the control system by the change dispenser system. The control system receives (94) the customer code input and retrieves (96) the coded balance information which has been stored (98) by the control system in computer memory. More particularly, the coded balance information is retrieved by searching (100) through the code indexed balance information data base based on the received code. If the code is found (102) and has not expired (104), then the change dispenser system dispenses (108) change in the form of currency in the amount indicated by the coded balance information. In this regard, it will be appreciated that network operators may desire to attach expiration dates to particular codes (e.g., 90 days after traction date) for bookkeeping purposes. If the code is not found, or is expired, an error message is displayed (106) to the customer and the process may be restarted… Referring to FIG. 6, the network 210 includes a number of communication links to facilitate interaction of the various components of the network 210. During operation, a customer initiates a transaction by inserting a payment amount in the form of a card, cash, or a credit voucher at pump system 222. Pump system 222 communicates with site controller 226 which authorizes fueling, calculates a balance code at the end of fueling, and transmits the code to pump system 222 for display and/or dispensing to the customer. The customer may then enter the balance code at the change dispenser 224 which communicates with the site controller 226 and which then dispenses change to the customer based on this communication. Information or data regarding the amount of fuel pumped, the currency received at each pump system 222, and the currency dispensed by the change dispenser 224 may be stored by the site controller 226… The remote computer center 212 may respond by transmitting a new balance or refund code to the customer for immediate or later use. As can be appreciated, the appropriateness of a refund may be verified by cross-checking the customer's original balance code (e.g., has it been previously dispensed) and/or the customer's fuel authorization code. With a refund code in hand, the customer may operate the change dispenser to obtain currency. If a continuing malfunction is experienced, the remote computer center 212 can relay this information to the service administrator 219 for correction of the problem.
The above language read on wherein if the user input does correlate with the at least one of the plurality of customer identifiers the voucher dispenser provides to the user the remaining balance via a voucher by applying the remaining balance to a pre-existing voucher already associated with the at least one of the plurality of customer identifiers.
For the above reasoning, the 35 U.S.C. § 103 rejection of the claims is maintained.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claims do fall within at least one of the four categories of patent eligible subject matter because claims 1 & 20 are directed to a system and claim 11 a process; Step 1-yes.
Unser Step 2A, prong 1, representative claim 1 recites a series of steps to receive coin, perform a fueling process and determining a remaining balance, which is a sales activity or business process relating to commercial or legal interactions, thus grouped as a “Certain Methods of Organizing Human Activity”. The claim as a whole and the limitations in combination recite this abstract idea. Specifically, the limitations of representative claim 1, stripped of all additional elements, recite the abstract idea as follows:
A system comprising:
a gasoline pumping assembly comprising a gasoline dispenser configured to perform a fueling process for a fueling process cost;
a voucher assembly communicably coupled to the gasoline pumping assembly, the voucher assembly comprising;
a coin receiver comprising a hopper and configured to receive a plurality of coins of a total value from a user; and
a voucher dispenser configured to provide to the user a remaining balance via a voucher when the total value is greater than the fueling process cost, wherein the remaining balance is a difference between the total value and the fueling process cost;
wherein at least one of the voucher assembly or the gasoline pumping assembly further comprises a user interface configured to receive a user input;
a database communicably coupled to the user interface, the database comprising a plurality of customer identifiers;
a processing circuit communicably coupled to the database and the user interface, the processing circuit comprising one or more processors configured to determine if the user input correlates with at least one of the plurality of customer identifiers,
wherein if the user input does not correlate with the at least one of the plurality of customer identifiers, the voucher dispenser provides to the user the remaining balance via a voucher by generating a new voucher with a new customer identifier, and
wherein if the user input does correlate with the at least one of the plurality of customer identifiers the voucher dispenser provides to the user the remaining balance via a voucher by applying the remaining balance to a pre-existing voucher already associated with the at least one of the plurality of customer identifiers.
The claimed limitations, identified above, recite a system that, under broadest reasonable interpretation, covers performance of a commercial or legal interaction, but for the recitation of generic computer components. There is nothing in the claim element which takes the steps out of methods of organizing human activity abstract idea grouping. Thus, claims 1, 11 and 20 recite an abstract idea.
Under step 2A, prong 2, this judicial exception is not integrated into a practical application because the generically recited additional elements do not add a meaningful limitation to the abstract idea because they amount to simply implementing the abstract idea in a technological computer environment. The computer components are recited at a high-level of generality (i.e., as generic processors with memory suitably programmed communicating information over a generic network, see at least paragraphs [0016]-[0019], [0024] & [0045] of the specifications) such that it amounts no more than adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform the abstract idea, see MPEP 2106.05(f) and generally linking the use of the judicial exception to a particular technological environment or field of use, see MPEP 2106.05 (h), furthermore, Accordingly, the additional elements claimed do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Claims 1, 11 and 20 are directed to an abstract idea.
Under step 2B, the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because mere instructions to apply an exception on a generic computer component cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B.
The additional recited limitations in the dependent claims only refine the abstract idea without adding significantly more. Further refinement of an abstract idea does not convert an abstract idea into something concrete.
Accordingly, the examiner concludes that there are no meaningful limitations in the claims that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself or integrate the judicial exception into a practical application.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1, 7, 8, 10, 11, 16 & 20 are rejected under 35 U.S.C. 102 (a)(1) & (a)(2) as being anticipated by Thomas P. Bruskotter et al. (US 2004/0225516 A1, herein Bruskotter).
As per claim 1, Bruskotter teaches a system comprising:
a gasoline pumping assembly comprising a gasoline dispenser configured to perform a fueling process for a fueling process cost (see Bruskotter ¶¶ [26-27]);
a voucher assembly communicably coupled to the gasoline pumping assembly, the voucher assembly comprising (Bruskotter ¶¶ [27-28 & 45]);
a coin receiver comprising a hopper and configured to simultaneously receive a plurality of coins of a total value from a user (Bruskotter ¶ [27]); and
a voucher dispenser configured to provide to the user a remaining balance via a voucher when the total value is greater than the fueling process cost, wherein the remaining balance is a difference between the total value and the fueling process cost (Bruskotter ¶¶ [27, 30, 37-38 & 50]);
wherein at least one of the voucher assembly or the gasoline pumping assembly further comprises a user interface configured to receive a user input (Bruskotter ¶¶ [26 & 39-40]);
a database communicably coupled to the user interface, the database comprising a plurality of customer identifiers (Bruskotter ¶¶ [10, 26, 36, 38 & 47]);
a processing circuit communicably coupled to the database and the user interface, the processing circuit comprising one or more processors configured to determine if the user input correlates with at least one of the plurality of customer identifiers, wherein if the user input does not correlate with the at least one of the plurality of customer identifiers, the voucher dispenser provides to the user the remaining balance via a voucher by generating a new voucher with a new customer identifier (Bruskotter ¶¶ [29, 37 & 38]); and
wherein if the user input does correlate with the at least one of the plurality of customer identifiers the voucher dispenser provides to the user the remaining balance via a voucher by applying the remaining balance to a pre-existing voucher already associated with the at least one of the plurality of customer identifiers (Bruskotter ¶¶ [10, 36, 38, 45 & 47]).
As per claim 7, Bruskotter teaches the system of claim 6, Bruskotter further teaches:
wherein the payment receiver comprises a voucher receiver configured to receive a pre-existing voucher, and wherein the second payment is a pre-existing balance associated with the pre-existing voucher (Bruskotter ¶¶ [27-28, 38 & 47]).
As per claim 8, Bruskotter teaches the system of claim 7, Bruskotter further teaches:
wherein the payment receiver is configured to receive a third payment from the user via a credit or debit card, and wherein the gasoline pumping assembly initiates a third fueling process based on receipt of the third payment (Bruskotter ¶¶ [29, 33, 36, 38, 47 & 50]).
As per claim 10, Bruskotter teaches the system of claim 6, Bruskotter further teaches:
wherein the payment receiver is a credit card scanner (Bruskotter ¶¶ [26-27 & 33]).
As per claim 11, a method for pumping gasoline, the method comprising:
simultaneously receiving, via a coin receiver comprising a hopper, a plurality of coins from a user (Bruskotter ¶¶ [27-28]);
determining a total value for the plurality of coins (Bruskotter ¶ [33]);
initiating a fueling process from a pumping assembly (Bruskotter ¶¶ [35 & 38]);
terminating the fueling process (Bruskotter ¶¶ [36 & 40]);
determining whether a fueling process cost associated with the fueling process is less than the total value (Bruskotter ¶¶ [29-30, 36 & 38]);
in response to a determination that the total value is greater than the fueling process cost providing, via the pumping assembly, a remaining balance on a voucher to the user, wherein the remaining balance is a difference between the total value and the fueling process cost (Bruskotter ¶¶ [27, 30, 37-38 & 50]);
receiving, via a user interface, a user input comprising a customer identifier (Bruskotter ¶¶ [29, 37-38 & 50]);
determining whether the customer identifier corresponds to at least one of a plurality of customer identifiers in a database (Bruskotter ¶¶ [10, 26, 36, 38 & 47]);
in response to a determination that the customer identifier does not correspond to at least one of the plurality of customer identifiers, providing the remaining balance to the user via a new voucher associated with a new customer identifier (Bruskotter ¶¶ [27, 30, 37-38 & 50]);
in response to a determination that the customer identifier does correspond to at least one of the plurality of customer identifiers, providing the remaining balance to the user via a voucher by applying the remaining balance to a pre-existing voucher associated with the at least one of the plurality of customer identifiers (Bruskotter ¶¶ [10, 36, 38, 45 & 47]).
As per claim 16, Bruskotter teaches the method of claim 11, Bruskotter further teaches:
wherein the voucher is a digital voucher, the method further comprising receiving, on a user device, the digital voucher (Bruskotter ¶¶ [29-30, 36 & 38]).
As per claim 20, Bruskotter teaches an system comprising:
a gasoline dispenser configured to perform a fueling process for a fueling process cost (Bruskotter ¶¶ [26-27]);
a voucher assembly communicably coupled to the gasoline dispenser, the voucher assembly comprising (Bruskotter ¶¶ [27-27 & 45]);
a coin receiver comprising a hopper and configured to simultaneously receive a plurality of coins from a user (Bruskotter ¶¶ [27-29]);
a voucher dispenser configured to provide to the user a voucher (Bruskotter ¶¶ [27, 30, 37-38 & 50]); and
a voucher receiver configured to receive a pre-existing voucher from the user (Bruskotter ¶¶ [27-28, 38 & 47]);
a user interface configured to receive a user input comprising a customer identifier (Bruskotter ¶¶ [29, 37-38 & 50]);
a database communicably coupled to the voucher assembly comprising a plurality of customer identifiers (Bruskotter ¶¶ [10, 26, 36, 38 & 47]); and
a processing circuit communicably coupled to the voucher assembly and the gasoline dispenser, the processing circuit comprising one or more memory devices coupled to one or more processors, the one or more memory devices configured to store instructions thereon that, when executed by the one or more processors, cause the one or more processors to:
determine a total value for the plurality of coins (Bruskotter ¶¶ [27, 30, 33, 37-38 & 50]);
initiate a first fueling process for a first fueling process cost (Bruskotter ¶¶ [35 & 38]);
determine if the user input correlates with at least one of the plurality of customer identifiers (Bruskotter ¶¶ [29, 37-38 & 50]);
in response to a determination that if the user input does not correlate with the at least one of the plurality of customer identifiers and the first fueling process cost is less than the total value, provide a remaining balance to a user via a new voucher (Bruskotter ¶¶ [29, 37-38 & 50]); and
in response to a determination the user input does correlate with the at least one of the plurality of customer identifiers and the first fueling process cost is less than the total value, provide a remaining balance to a pre-existing voucher already associated with the at least one of the plurality of customer identifiers (Bruskotter ¶¶ [10, 36, 38, 45 & 47]); and
in response to receiving the pre-existing voucher via the voucher receiver from the user, and a determination that the first fueling process cost is greater than the total value, initiating a second fueling process using a balance associate with the pre-existing voucher (Bruskotter ¶¶ [27-28, 38 & 47]).
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 (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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 2, 5, 6, 12, 13 & 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over Bruskotter in view of Keith Clithero et al. (US 12,223,478 B1, herein Clithero).
As per claim 2, Bruskotter teaches the system of claim 1, Bruskotter further teaches:
further comprising:
a user device communicably coupled to the voucher assembly, the user device comprising a processing circuit configured to:
receive the voucher from the voucher dispenser (Bruskotter ¶¶ [29, 45 & 47]);
when the total value is less than the fueling process cost, provide the voucher to the voucher assembly (Bruskotter ¶¶ [29-30, 36 & 38]).
it can be argued Bruskotter does not explicitly teach; however, Clithero further teaches:
store the voucher in a wallet on the user device (Clithero column 7 lines 26-31); and
it can be argued Bruskotter does not explicitly teach; however, Clithero further teaches:
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify the automated filling station with change dispenser of Bruskotter with the systems and methods for automated teller machine replenishing and merchant operations of Clithero in order to store information regarding vouchers using mobile wallets (see Clithero column 14 lines 34-67 and column 15 lines 1-11)
As per claim 5, Bruskotter teaches the system of claim 1, it can be argued Bruskotter does not explicitly teach; however, Clithero further teaches:
wherein the voucher is a digital voucher to be received by a user device communicably coupled with the voucher dispenser (Clithero column 18 lines 4-35, column 19 lines 41-67 and column 20 lines 1-32).
The motivation to combine the references is the same as seen above in claim 2.
As per claim 6, Bruskotter teaches the system of claim 1, it can be argued Bruskotter does not explicitly teach; however, Clithero further teaches:
wherein the fueling process is a first fueling process and the fueling process cost is a first fueling process cost, wherein at least one of the voucher assembly or the gasoline pumping assembly comprise a payment receiver configured to receive a second payment from the user, and wherein when the total value is equal to the first fueling process cost, the gasoline pumping assembly initiates a second fueling process based on receipt of the second payment (Clithero column 26 lines 32-38 and column 30 lines 31-41).
The motivation to combine the references is the same as seen above in claim 2.
As per claim 9, Bruskotter teaches the system of claim 7, it can be argued the Bruskotter does not explicitly teach; however, Clithero further teaches:
wherein the pre-existing voucher is a digital voucher stored on a user device (Clithero column 19 lines 43-67).
The motivation to combine the references is the same as seen above in claim 2.
As per claim 12, Bruskotter teaches the method of claim 11, Bruskotter further teaches:
further comprising:
providing, in response to a determination that the fueling process cost will exceed the total value, the voucher to the pumping assembly (Bruskotter ¶¶ [27, 30, 37-38 & 50]); and
it can be argued the Bruskotter does not explicitly teach; however, Clithero further teaches:
receiving, via a user device communicably coupled to the pumping assembly, the voucher (Clithero column 6 lines 63-67, column 7 liens 1-31, column 8 lines 12-39 and column 9 lines 40-51);
storing, on the user device, the voucher (Clithero column 7 lines 26-31);
initiating a second fueling process based at least in part on the receipt of the voucher (Clithero column 26 lines 32-38 and column 30 lines 31-41).
The motivation to combine the references is the same as seen above in claim 2.
As per claim 13, the combination of Bruskotter and Clithero teach the method of claim 12, Clithero further teaches:
further comprising:
providing, from the user device, the voucher to a point of sale affiliated with an operator of the pumping assembly (Clithero column 18 lines 4-35).
The motivation to combine the references is the same as seen above in claim 2.
As per claim 17, Bruskotter teaches the method of claim 11,
it can be argued the Bruskotter does not explicitly teach; however, Clithero further teaches:
wherein the fueling process is a first fueling process, and wherein the first fueling process is terminated when the fueling process cost equals the total value, the method further comprising:
receiving a second payment (Clithero column 26 lines 32-38 and column 30 lines 31-41); and
initiating a second fueling process based on the second payment (Clithero column 26 lines 32-38 and column 30 lines 31-41).
As per claim 18, the combination of Bruskotter and Clithero teach the method of claim 17, Bruskotter further teaches:
wherein the second payment is a pre-existing voucher with a pre-existing balance (Bruskotter ¶¶ [27-28, 38 & 47]).
As per claim 19, the combination of Bruskotter and Clithero teach the method of claim 18, Bruskotter further teaches:
further comprising:
terminating the second fueling process with a second fueling process cost associated equals the pre-existing balance (Bruskotter ¶¶ [36 & 40]);
receiving a third payment via a credit or debit card (Bruskotter ¶¶ [29, 33, 36, 38, 47 & 50]); and
initiating a third fueling process based on the third payment (Bruskotter ¶¶ [29, 33, 36, 38, 47 & 50]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TONY P KANAAN whose telephone number is (571)272-2481. The examiner can normally be reached Monday- Friday 7:30am - 3:30 pm EST.
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, Matthew Gart can be reached on 5712723955. 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.
/T.P.K./Examiner, Art Unit 3696
/MATTHEW S GART/Supervisory Patent Examiner, Art Unit 3696