Note: Descriptions are shown in the official language in which they were submitted.
SYSTEM AND METHOD TO PROCESS TRANSACTIONS AT RETAIL FUELING
FACILITIES
BACKGROUND
[0001] The subject matter disclosed herein relates to processing of
transactions and, in
certain embodiments, to transactions at retail fueling facilities that occur
via electronic
commerce and/or via electronic systems configured to settle transactions.
[0002] Fueling facilities offer various products to end users and complete
transactions at
automated or semi-automated fuel dispensers. Conventional fuel dispensers can
receive payment
information (e.g., a swiped debit card) and dispense fuel. These fuel
dispensers communicate
with a point-of-sale (POS) system to process credit-card transactions by
preauthorizing the card
before fueling and charging the appropriate amount to the card after fueling.
The fuel dispensers
can also prompt the user to purchase other products, e.g., a car wash. Any
additional purchases
or special offers are included in the final amount charged to the card. To
complete the
transaction, the payment terminal in the fuel dispenser can send this final
amount to the POS,
which communicates with a payment network to process and complete the
transaction.
[0003] An increasing number of payment options are available, such as
mobile-telephone
payment systems (sometimes called "electronic wallets"). Examples of such
systems are those
based on the EMV standard, e.g., PAYPASSED by MASTERCARD . However, these
systems
generally deal with purchase transactions for a fixed amount. Therefore, even
if a mobile device
is used for payment, the end user must still interact with the payment
terminal on the dispenser
for any function other than charging the final amount.
SUMMARY OF THE INVENTION
[0004] The discussion below describes embodiments of a component (also, "a
transaction
gateway" and "transaction gateway component") that integrates with a
transaction system to
facilitate transactions (e.g., purchases) that occur at retail fueling
facilities. These embodiments
address a gap that exists between the transaction system and electronic
commerce systems (often
recognized as "digital wallet" and "e-wallet" systems). This gap can prevent
use of electronic
commerce technology to complete transactions to purchase fuel, products, and
services during a
1
CA 2890321 2019-02-19
visit to the retail fueling facility. As set forth more below, embodiments of
the transaction
gateway provide the infrastructure necessary to allow the transaction system
and the e-commerce
system to exchange data. This exchange facilitates the financial transaction
that is necessary for
the end user to initiate and pay for products and services using the c-wallet
technology, often
through software (or ''application") for use on a mobile device.
[0005] Certain exemplary embodiments can provide a method for completing a
mobile payment
transaction for a purchase at a retail fueling facility, comprising: at a
transaction gateway
component remote from the retail fueling facility and having access to a
processor and a
memory: receiving, from a payment processing component remote from the retail
fueling
facility, a first input with data that relates to a fueling point identifier
that the payment processing
component received from a mobile device to initiate a mobile payment
transaction for fuel;
generating a first output with site data that identifies the retail fueling
facility in accordance with
the fueling point identifier; communicating the first output to the payment
processing
component; after communicating the first output to the payment processing
component,
receiving, from the payment processing component in response to the payment
processing
component's receipt of the first output, a second input with data to initiate
the transaction;
generating a second output in response to the second input, the second output
having data to
enable operation of a dispenser at the retail fueling facility; communicating
the second output to
a forecourt system that operates the fuel dispenser at the retail fueling
facility to enable the
dispenser to dispense fuel; receiving, from the forecourt system in response
to the forecourt
system's receipt of the second output and the dispensing of the fuel, a third
input with data to
complete the transaction; in response to the receipt of the third input,
generating a third output
with data that reflects the transaction complete; and communicating the third
output to the
payment processing component for transmission to the terminal to finalize the
mobile payment
transaction.
[0005a] Certain exemplary embodiments can provide a transaction gateway
component,
comprising: a processor; a memory coupled with the processor; and one or more
executable
instructions stored on the memory and configured to be executed by the
processor, the
executable instruction comprising instructions for: receiving, from a payment
processing
component remote from a retail fueling facility, a first input with data that
relates to a fueling
point identifier that the payment processing component received from a mobile
device to initiate
2
CA 2890321 2019-02-19
a mobile payment transaction for fuel; generating a first output with site
data that identifies the
retail fueling facility in accordance with the fueling point identifier;
communicating the first
output to the payment processing component; after communicating the first
output to the
payment processing component, receiving, from the payment processing component
in response
to the payment processing component's receipt of the first output, a second
input with data to
initiate the transaction; generating a second output with data to enable
operation of a dispenser at
the retail fueling facility; communicating the second output to a forecourt
system that operates
the fuel dispenser at the retail fueling facility to enable the dispenser to
dispense fuel; receiving,
from the forecourt system in response to the forecourt system's receipt of the
second output and
the dispensing of the fuel, a third input with data to complete the
transaction; in response to the
receipt of the third input, generating a third output with data that reflects
the transaction
complete; and communicating the third output to the payment processing
component for
transmission to the terminal to finalize the mobile payment transaction.
[0005b] Certain exemplary embodiments can provide a system for managing
transactions
at a retail fueling facility, comprising: a forecourt system comprising a
forecourt controller and a
fuel dispenser; and a remote system coupled with the forecourt system via a
network, the remote
system comprising a transaction gateway component coupled with and remote from
the forecourt
controller, the transaction gateway component accessing executable
instructions for: generating
first transaction data that instructs the forecourt controller to enable the
fuel dispenser to dispense
fuel; communicating the first transaction data to the forecourt controller;
after communicating
the first transaction data to the forecourt controller, receiving in response
to the forecourt
controller's receipt of the first transaction data second transaction data
from the forecourt
controller that defines parameters for a purchase of fuel from the dispenser;
in response to
receiving the second transaction data from the forecourt controller,
generating third transaction
data to instruct a payment processing component to complete a financial
transaction that settles
the purchase of the fuel dispensed from the fuel dispenser with the retail
fueling facility; and
communicating the third transaction data to the payment processing component
to the payment
processing component to finalize the transaction.
2a
CA 2890321 2019-02-19
BRIEF DESCRIPTION OF THE DRAWINGS
[0006] Reference is now made briefly to the accompanying figures, in which:
[0007] FIG. 1 depicts a schematic diagram of an exemplary embodiment of a
transaction
system for use to complete transactions at a retail fueling facilities;
[0008] FIG. 2 depicts one exemplary configuration of payment components for
the
transaction system of FIG. 1;
2b
CA 2890321 2019-02-19
CA 02890321 2015-01-14
WO 2014/015294
PCT/US2013/051363
[0009] FIG. 3
depicts a flow diagram of an exemplary embodiment of a method to
facilitate transaction using e-commerce systems and technology; and
[0010] FIG. 4
depicts a schematic diagram of an exemplary embodiment of a
transaction system for use to complete transactions at a retail fueling
facility.
[0011] Where applicable, like reference characters designate identical or
corresponding components and units throughout the several views, which are not
to scale
unless otherwise indicated.
DETAILED DISCUSSION
[0012] FIG. 1
illustrates a schematic diagram of an exemplary embodiment of a
transaction-processing system 100 (also "transaction system 100") that can
process
transactions, for example, that occur at retail fueling facilities. The system
100 has a
forecourt system 102 and a remote system 104 that communicate with one another
via a
network system 106. This discussion contemplates examples of the network
system 106
that use various communication protocols, e.g., wired and wireless protocols.
The
forecourt system 102 includes various components including, in one embodiment,
a
dispenser 108, a forecourt controller component 110, and a point-of-sale (POS)
component 112. Together, these components operate to allow an end user to
purchase
fuel from the dispenser 108, as well as other products and services,
(collectively,
"forecourt offerings"), via interaction with the dispenser 108 and/or a retail
element (e.g.,
a store, a kiosk, etc.) found at the retail fueling facility. In one
implementation, the end
user may utilize a terminal 114 that can execute a transaction application
116. Examples
of the terminal 114 can include a variety of portable computing devices (e.g.,
computers,
cellular phones, smartphones, tablets, personal digital assistants, laptops,
etc.). These
computing devices can execute programs for the transaction application 116
that offer the
end user options to complete transactions for the forecourt offerings via
alternative
payment processes (e.g., mobile and e-wallet applications; collectively "e-
payment
applications") that fall, for example, outside of the conventional POS
component 112.
3
CA 02890321 2015-01-14
WO 2014/015294
PCT/US2013/051363
[0013] The remote
system 104 provides the infrastructure necessary for the end user
to utilize the e-payment applications to complete transactions at the retail
fueling facility.
As shown in FIG. 1, the remote system 104 can include a payment processing
component
118 and one or more one or more remote servers (e.g., remote server 120). The
remote
system 104 also has a transaction gateway component 122 with access to a
memory 124
and a processor 126, both of which can perform functions useful for processing
transactions that occur at the retail fueling facility.
[0014] As
discussed more herein, use of the transaction gateway component 122
makes the e-payment applications available for the end user to pay for the
forecourt
offerings via the terminal 114. This feature allows an end user to complete
transactions
(e.g., to dispense fuel) at the retail fueling facility without the need to
utilize traditional
payment methodologies, e.g., credit cards. Use of the transaction gateway
component
122 can, in one example, complete the transaction without the need for the end
user to
interact with the dispenser 108, other than to dispense fuel. For retail
fueling facilities
that employ attends and/or other systems (e.g., robotic systems) to dispense
fuel, the
transaction gateway component 122 allows the end user to complete transaction
effectively without any interaction with the dispenser 108.
[0015] The
embodiments that this disclosure contemplates facilitate mobile
transactions via the terminal 114, which the end user is likely to have on
their person at
the retail fueling facility. More broadly, however, these embodiments can
leverage the
technology of terminal 114 to simplify the fueling transaction, as well as to
expand the
transaction to include a breadth of forecourt offerings that are available for
purchase to
the end user at the dispenser 108 and/or generally at the retail fueling
facility. As
contemplated herein, examples of the forecourt offerings can include fuel,
products (e.g.,
food products, drink products, and consumer goods like magazines, clothing,
and other
apparel), and services (e.g., car washes).
[0016] One or more
functions of the transaction gateway component 122 can
facilitate one or more of these benefits to streamline transactions across the
transaction
4
CA 02890321 2015-01-14
WO 2014/015294
PCT/US2013/051363
system 100. For example, the transaction gateway component 122 can operate as
a
liaison between the components at the retail fueling facility and the
infrastructure
necessary to provide the e-payment applications. This function can remove
and/or
circumvent the barriers (e.g., firewalls, networking protocols, data
protocols, etc.) that
often prevent appropriate communications between components of the forecourt
system
and the typically cloud-based e-payment applications. This communication can
be
essential to engage and/or to cause the dispenser 108 to operate to dispense
fuel, e.g., in
response to interaction by the end user with the transaction application 116.
Implementing the transaction gateway component 122, for example, can exchange
data
with the e-payment applications to instruct the forecourt controller component
110 to
activate the dispenser 108. The transaction gateway component 122 can also
communicate with the e-payment application to complete the transaction and,
thus, allow
the e-payment application to tender payment on behalf of the end user, e.g.,
for fuel the
end user dispenses at the dispenser 108.
[0017] FIG. 2
depicts one configuration of the payment processing component 118
with components that represent infrastructure for various e-payment
applications. The
transaction gateway component 122 can communicate with this infrastructure to
complete
a transaction. The payment processing component 118 has one or more payment
components (e.g., a first payment component 130, a second payment component
132, and
a third payment component 134). At a relatively high level, examples of the
payment
components 130, 132, 134 can include any one of the various systems and
networks that
relate to e-commerce transactions. For purposes of discussion, these systems
may, for
example, incorporate infrastructure that represent entities that provide
banking, merchant,
and digital wallet (also, "e-wallet") services. These types of entities may be
one in the
same, e.g., the banking and/or merchant may provide e-wallet services. In
other
implementations, the e-wallet services reflect stand-alone entities that can
tender and/or
cause the exchange of monetary consideration to the retail fueling facility on
behalf of the
end user.
CA 02890321 2015-01-14
WO 2014/015294
PCT/US2013/051363
[0018] FIGS. 3 and 4 are useful to describe the interactions that can occur
among the
a transaction gateway component and the components of a forecourt system and
the
remote system. These interactions complete the transaction at the retail
fueling facility
utilizing one or more of the e-payment applications. FIG. 3 depicts a flow
diagram of an
exemplary method 200 for integrating the processes of payment components and
the
processes of the forecourt components that can occur, e.g., to dispense fuel.
FIG. 4
provides a schematic diagram of an exemplary embodiment of a transaction
system 300.
[0019] In FIG. 3, the method 200 includes, at step 202, receiving a first
input with
data that relates to a fueling point identifier and, at step 204, generating a
first output with
data that relates to site information that identifies the retail fueling
facility in accordance
with the fueling point identifier. The method 200 also includes, at step 206,
receiving a
second input with data to initiate the transaction, at step 208, generating a
second output
with data to enable operation of a pump at the retail fueling facility and, at
step 210,
receiving a third input with data to complete the transaction. The method 200
further
include, at step 212, generating a third output with data that reflects the
transaction is
complete.
[0020] Collectively, one or more of the steps of the method 200 can be
coded as one
or more executable instructions (e.g., hardware, firmware, software, software
programs,
etc.). These executable instructions can be part of a computer-implemented
method
and/or program, which can be executed by a processor and/or processing device.
The
processor may be part of the transaction gateway component, which is adapted
to execute
these executable instructions, as well as to process inputs and to generate
outputs, as set
forth herein.
[0021] The diagram of FIG. 4 shows an exemplary configuration for
components of
the transaction system 300 to execute a transaction. These components may, for
example,
generate signals (e.g., digital signals and analog signals) that transit via a
network (e.g.,
network system 106 of FIG. 1). The signals can carry (and/or represent) data
in the form
of packets and similar configurations that allow for rapid exchange of
information
6
CA 02890321 2015-01-14
WO 2014/015294
PCT/US2013/051363
consistent with e-commerce applications and related technology. In FIG. 4, the
system
300 can exchange one or more inputs (e.g., a first input 336, a second input
338, and a
third input 340) and one or more outputs (e.g., a first output 342, a second
output 344,
and a third output 346).
[0022] The step of receiving the first input (e.g., at step 202) can
initiate the start of
the transaction. As shown in FIG. 4, the first input 336 may arise from one of
the
payment components 330, 332, 334 in response to an initiation signal 348 from
the
transaction application 316 on the terminal 314. As noted above, the payment
components 330, 332, 334 can include entities that provide e-wallet and
digital wallet
services. The end user may have an account with these entities. This account
may
include financial information from the end user that is sufficient to settle
financial
transactions. In context of retail fueling facilities, the end user may wish
to leverage this
account to make purchases at the retail fueling facility. Examples of the
initiation signal
348 may indicate that the end user is ready to purchase fuel (and/or other
forecourt
offerings) at the retail fueling facility. In one example, the initiation
signal 348
corresponds to entry of the fueling point identifier into the transaction
application 316,
e.g., by the end user using the terminal 314 to type in an alphanumeric code
and/or to
capture a bar code (and like symbol). The fueling point identifier can include
data and
information that identifies the retail fueling facility and, in one example,
distinguishes the
retail fueling facility of the present transaction from other retail fueling
facilities. In one
embodiment, the method 200 can include one or more steps that instruct the
transaction
gateway component 322 to poll the retail fueling facility, which in turn
allows the
transaction gateway component 322 to gather additional site specific data and
information about the retail fueling facility.
[0023] The step of generating the first output (e.g., at step 204) can
utilize the site
specific information to instruct the payment component 330, 332, 334 to
initiate the
transaction. This step can allow for the exchange of payment between the
payment
component 330, 332, 334 (and/or related infrastructure of the remote system
304) to
7
CA 02890321 2015-01-14
WO 2014/015294
PCT/US2013/051363
complete the purchase by the end user. In FIG. 4, the first output 342 can
provide site
data 350 to the payment component 330, 332, 334. Examples of site data 350 may
incorporate information about the geographic location of the retail fueling
facility, as well
as information about the products, services, and other aspects of the retail
fueling facility.
In one implementation, the payment component 330, 332, 334 can create a
transaction
request 352 with transaction data 354. Examples of transaction data 354 can
include
various pieces of general information 356 (including customer information 358,
location
information 360, attributes 362) and transaction specific information 364
(including
transaction start time 366, product selection 368, transaction total 370, and
transaction
end time 372).
[0024] Embodiments
of the system 300 may also tailor the information 356, 364 to
suit the needs, e.g., of the forecourt system 302 and/or remote system 304.
The method
200 may include, for example, one or more steps for conveying a pre-
authorization
amount that can be used to determine the extent of the purchase. These steps
may further
include information that includes price per gallon (PPG) of fuel dispensed, a
fueling point
number, various volume measurement for the fuel dispensed, error and failure
mode
indicators/strings, and like information that may be useful to complete the
transaction
and/or to collect for storage by one or more components of the transaction
system 300.
This additional information may include data about the transaction; this
information can
include the date/time of the purchase, type of fuel purchased (e.g., supreme,
unleaded,
etc.), and various totalizer data (e.g., total gallons purchased for a
specific date range,
total gallons purchased broken down by fuel type). For transactions that
include and/or
incorporate other forecourt offerings, the additional information can include
data (also
called "pass-through data") that defines the parameters of the forecourt
offerings, e.g., to
complete the transaction.
[0025] The steps
of receiving the second input (e.g., at step 206) and generating the
second output (e.g., at step 208) can enable operation of the dispenser 308
for use by the
end user. As shown in FIG. 4, the second input 338 can exchange the
transaction request
8
CA 02890321 2015-01-14
WO 2014/015294
PCT/US2013/051363
352 and/or the transaction data 354 between the payment component 330, 332,
334 and
the transaction gateway component 322. In response to the second input 338,
the
transaction component 322 can transmit the second output 344 to the forecourt
system
302. This second output 344 can include the transaction request 350 and/or the
transaction data 354, which the forecourt system 302 can use to enable the
dispenser 308
to dispense fuel and to monitor operation of the dispenser 308 to gather
information, e.g.,
to calculate the cost of the purchase by the end user.
[0026] The step of
receiving the third input (e.g., at step 210) can occur upon
completion of the purchase. In FIG. 4, the forecourt system 302 transmits the
third input
340 to the transaction gateway component 322. Examples of the third input 340
can
include the transaction request 352 and/or the transaction data 354. In one
example, the
forecourt system 302 can update the transaction data 354 to reflect changes,
e.g., in one
or more of the transaction start time 366, product selection 368, transaction
total 370, and
transaction end time 372. These changes can indicate the various details of
the purchase
to allow for appropriate charges and payment to be made to the retail fueling
facility.
[0027] The step of
generating the third output (e.g., at step 212) can finalize the
transaction. FIG. 4 shows that, in one example, the transaction gateway
component 322
exchanges the third output 346 with the payment component 330, 332, 334. This
exchange can transmit the updated transaction data 354, which the payment
component
330, 332, 334 can process to settle payment for the purchase on behalf of the
end user.
[0028] Embodiments
of methods (e.g., method 200) can further comprise other steps
that can bring the transaction to completion. In one example, these
embodiments may
include steps for generating transaction data that instructs the forecourt
controller to
enable the fuel dispenser, receiving transaction data from the forecourt
controller that
defines parameters for a purchase of fuel from the dispenser, and generating
transaction
data to instruct a payment processing component to complete a financial
transaction that
settles the purchase of fuel from the fuel dispenser with the retail fueling
facility.
9
CA 02890321 2015-01-14
WO 2014/015294
PCT/US2013/051363
[0029] Embodiments
of the transaction system 300 can also utilize the transaction
application 316 to interact with the end user during and after fueling. This
interaction
may be useful to encourage the customer to continue the buying experience,
e.g., inside
the retail element of the retail fueling facility. The transaction system 300
may, for
example, transmit coupon/discount offers to the terminal 314. These offers may
be
tailored to the end user, which could redeem the offers before, during, and/or
after the
fueling purchase.
[0030] The
transaction system 300 may utilize various hardware and software
configurations to further enhance interoperability of the forecourt system 302
and the
remote system 304. These configuration may utilize various client/server type
arrangements, e.g., an Enterprise Communication Client (ECC) and Enterprise
Communication Server (ECS). In one embodiment, the forecourt controller
component,
may be configured to register for appropriate router messages sent by the ECC,
to receive
router messages from the ECC to perform pump authorization, to interface with
a pump
controller Add-1n to perform pump control, to perform price rollbacks (fueling
point
discounts) sent down from the remote system 302, which may apply all fuel
products at a
given fueling point as well as to apply on a product-by-product basis, to
monitor for
fueling point timeouts and preset failures and send back appropriate router
message to
indicate "Zero Sale," and to monitor for sale completions and create
transaction response
router messages for processing by the ECC.
[0031] For
embodiments of the transaction system 300 for use at commercial
petroleum retail sites, security is of the utmost concern in line with
PCl/PADSS
compliance. These concerns often require the site to connect indirectly to the
remote
system 304 and adhere to strict connectivity standards. To achieve this goal,
the system
300 can utilize the ECS/ECC model to act as a broker agent to communicate
between the
forecourt system 302 at the retail fueling site and the remote system 304 and
on to EC S.
Often, the Point-of-Sale (POS) may not have knowledge concerning any payment
by e-
commerce application and like mobile payment transactions. Embodiments of the
system
CA 02890321 2015-01-14
WO 2014/015294
PCT/US2013/051363
300 can address this by implementing various configurations. In one
configuration, the
system 300 utilizes a new interface to send transaction data to the POS
system. In
another configuration, the system 300 may utilize a secondary POS control
model (also
"Dual-Auxiliary Controller"). These configurations can implement one or more
protocols to allow the a secondary POS system to perform pump control (e.g.
authorizing
a dispenser). In yet another configuration, the system 300 is configured to
work in
conjunction with the primary POS system. This configuration allows the
forecourt
system 302 to control the dispenser 308 as the primary POS system. In one
example, the
forecourt system 302 authorizes the dispenser 308 as if it were the primary
POS, but
provides data and information denotes a different AUTHORIZER field in the
transaction
DB to distinguish mobile payment transactions. The primary POS has visibility
to the
transaction in progress and receives real-time money updates while the
dispenser 308 is
fueling. In one example, the operator has the capability to perform various
dispenser
related functions (e.g., Pump Stop, Pump Restart, etc.) and, furthermore,
other
components of the forecourt system 302 (e.g., outdoor terminals such as CAT,
CRIND,
and DPT) are updated to reflect current fueling state (Remove Nozzle, Lift
Lever, etc.).
[0032] Examples of
the transaction gateway component 322 can provide a robust
interface for the exchange of data and information, e.g., with the payment
component
330, 332, 334. These interfaces can support, for example, push and pull
models. For
push models, the transaction gateway component 322 can pass data and
information in a
finalized form to the payment components 330, 332, 334. This finalized form
indicates
the transaction is complete from the perspective of the transaction gateway
component
322. In embodiments that implement pull models, the payment components 330,
332,
334 can initiate the exchange of data with the transaction gateway component
322. This
feature can, for example, utilize a request for data that defines a specific
transaction, as
well as a plurality of transactions (that may occur over the course of a
specified time
period (e.g., minutes, hours, days, weeks, months, etc.). In one
implementation of the
push model, the transaction gateway component 322 can obtain site information
from the
forecourt system 302. This site information may be determinative of the
fueling points
11
CA 02890321 2015-01-14
WO 2014/015294
PCT/US2013/051363
that are available for starting a transaction. The transaction gateway
component 322 can
also initiate a transaction for the specific fueling point and, then, finalize
the transaction
so as to pass the data in the finalized form, e.g., to the payment components
330, 332,
334.
[0033] Further, implementation of the methodologies (and systems and
components)
disclosed herein can utilize data objects to exchange, transmit, and/or define
data and
information. Examples of the data objects can include one or more of the
following:
[0034] TransactionInfo, comprising, attributes, available products (and
forecourt
offereings), begin time, currency, customer, error, finish time, ID, location,
pre-
authorization limit, products, provider id, state, and total;
[0035] ErrorInfo, comprising, code and description;
[0036] TransactionState, comprising, open, cancelled, failed, and closed;
[0037] ProductInfo, comprising, attributes, code, currency, description,
ID, quantity,
and UnitPrice;
[0038] StateInfo, comprising, attributes, available locations, available
products (and
forecourt offerings), and ID;
[0039] LocationInfo, comprising, attributes, fueling point, register, and
site ID;
[0040] CustomerInfo, comprising, attributes, ID, and provider ID; and
[0041] ProviderInfo, comprising, attributes, ID, and name.
[0042] Examples of attributes can define a listing of key and value pairs
that can
carry additional information. For example, the key and value pairs can carry
loyalty data,
extra product data, and like data that can be passed back to the creator of
the attribute.
The value portion can be user-defined, e.g., to have a vale that can represent
any type of
value to meet requirement of one or both the upstream and the downstream
system. For
12
CA 02890321 2015-01-14
WO 2014/015294
PCT/US2013/051363
example, the payment component 330, 332, 334 may utilize a loyalty program
that
triggers a fuel discount. Utilizing the attribute key to include, for example,
a loyalty
member identifier (the key) and a value associated with the loyalty member
identifier (the
value) can allow data to be passed among the components of the transaction
system 300.
This exchange can allow the system 300 to apply the discount associated with
the loyalty
program to the transaction. In another example, a store coupon might be
applied in the
forecourt system 302. Inserting an attribute key with a coupon identifier and
a coupon
valve would allow local data to be passed to the payment component 330, 332,
334 to
ensure that the value of coupon is applied to the transaction.
[0043] As set
forth herein, embodiments of the various transaction gateway
component (e.g., transaction gateway device 122, 322 of FIGS. 1, 2, and 4) can
comprise
computers and computing devices with processors and memory that can store and
execute
certain executable instructions, software programs, and the like. These
devices can reside
remote from the retail fueling facility as a standalone computing device,
network, and
like computing arrangement. The memory (e.g. memory 124 of FIG. 1) and the
processor (e.g., processor 126 of FIG. 1) can include hardware that
incorporates with
other hardware (e.g., circuitry) to form a unitary and/or monolithic unit
devised to
execute computer programs and/or executable instructions (e.g., in the form of
firmware
and software). In other examples, these devices integrate, in whole or in
part, with
components of the forecourt system, e.g., as part of the hardware and/or
software
configured on such hardware.
[0044] Devices for
use as the transaction gateway component may have constructive
components that can communicate amongst themselves and/or with other circuits
(and/or
devices), which execute high-level logic functions, algorithms, as well as
executable
instructions (e.g., firmware instructions, software instructions, software
programs, etc.).
Exemplary circuits of this type include discrete elements such as resistors,
transistors,
diodes, switches, and capacitors. Examples of a processor (e.g., processor 126
of FIG. 1)
include microprocessors and other logic devices such as field programmable
gate arrays
13
CA 02890321 2015-01-14
WO 2014/015294
PCT/US2013/051363
("FPGAs") and application specific integrated circuits ("ASICs"). Although all
of the
discrete elements, circuits, and devices function individually in a manner
that is generally
understood by those artisans that have ordinary skill in the electrical arts,
it is their
combination and integration into functional electrical groups and circuits
that generally
provide for the concepts that are disclosed and described herein.
[0045] The
structure of the transaction gateway device can permit certain
determinations as to selected configuration and desired operating
characteristics that an
end user might convey via the graphical user interface or that are retrieved
or need to be
retrieved by the device. For example, the electrical circuits of these control
devices can
physically manifest theoretical analysis and logical operations and/or can
replicate in
physical form an algorithm, a comparative analysis, and/or a decisional logic
tree, each of
which operates to assign the output and/or a value to the output that
correctly reflects one
or more of the nature, content, and origin of the changes the data that are
reflected by the
inputs and outputs the transaction gateway generates during operation of the
transaction
system
[0046] In one
embodiment, a processor (e.g., processor 126 of FIG. 1) can also
include state machine circuitry or other suitable components capable of
controlling
operation of the components as described herein. Memory (e.g., memory 124 of
FIG. 1)
includes volatile and non-volatile memory and can store executable
instructions in the
form of and/or including software (or firmware) instructions and configuration
settings.
Examples of these devices can mount to substrates such as printed-circuit
boards and
semiconductors, which can accommodate various components including a
processor,
memory, and other related circuitry to facilitate operation, e.g., of the
transaction gateway
component 122, 322 of FIGS. 1, 2, and 4.
[0047] However,
although processor, memory, and the components of control
circuitry might include discrete circuitry and combinations of discrete
components, this
need not be the case. For example, one or more of these components can
comprise a
single integrated circuit (IC) or other component. As another example, a
processor can
14
CA 02890321 2015-01-14
WO 2014/015294
PCT/US2013/051363
include internal program memory such as RAM and/or ROM. Similarly, any one or
more
of functions of these components can be distributed across additional
components (e.g.,
multiple processors or other components).
[0048] Moreover,
as will be appreciated by one skilled in the art, aspects of the
present invention may be embodied as a system, method or computer program
product.
Accordingly, aspects of the present invention may take the form of an entirely
hardware
embodiment, an entirely software embodiment (including firmware, resident
software,
micro-code, etc.) or an embodiment combining software and hardware aspects
that may
all generally be referred to herein as a "circuit," "module" or "system."
Furthermore,
aspects of the present invention may take the form of a computer program
product
embodied in one or more computer readable medium(s) having computer readable
program code embodied thereon.
[0049] Any
combination of one or more computer readable medium(s) may be
utilized. The computer readable medium may be a computer readable signal
medium or a
computer readable storage medium. Examples of a computer readable storage
medium
include an electronic, magnetic, electromagnetic, and/or semiconductor system,
apparatus, or device, or any suitable combination of the foregoing. More
specific
examples (a non-exhaustive list) of the computer readable storage medium would
include
the following: an electrical connection having one or more wires, a portable
computer
diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM),
an
erasable programmable read-only memory (EPROM or Flash memory), an optical
fiber, a
portable compact disc read-only memory (CD-ROM), an optical storage device, a
magnetic storage device, or any suitable combination of the foregoing. In the
context of
this document, a computer readable storage medium may be any tangible medium
that
can contain, or store a program for use by or in connection with an
instruction execution
system, apparatus, or device.
[0050] A non-
transitory computer readable signal medium may include a propagated
data signal with computer readable program code embodied therein, for example,
in
CA 02890321 2015-01-14
WO 2014/015294
PCT/US2013/051363
bascband or as part of a carrier wave. Such a propagated signal may take any
of a variety
of forms and any suitable combination thereof. A computer readable signal
medium may
be any computer readable medium that is not a computer readable storage medium
and
that can communicate, propagate, or transport a program for use by or in
connection with
an instruction execution system, apparatus, or device.
[0051] Program
code embodied on a computer readable medium may be transmitted
using any appropriate medium, including but not limited to wireless, wireline,
optical
fiber cable, RF, etc., or any suitable combination of the foregoing.
[0052] Computer
program code for carrying out operations for aspects of the present
invention may be written in any combination of one or more programming
languages,
including an object oriented programming language and conventional procedural
programming languages. The program code may execute entirely on the user's
computer,
partly on the user's computer, as a stand-alone software package, partly on
the user's
computer and partly on a remote computer or entirely on the remote computer or
server.
In the latter scenario, the remote computer may be connected to the user's
computer
through any type of network, including a local area network (LAN) or a wide
area
network (WAN), or the connection may be made to an external computer (for
example,
through the Internet using an Internet Service Provider).
[0053] Aspects of
the present invention are described herein with reference to
flowchart illustrations and/or block diagrams of methods, apparatus (systems)
and
computer program products according to embodiments of the invention. It will
be
understood that each block of the flowchart illustrations and/or block
diagrams, and
combinations of blocks in the flowchart illustrations and/or block diagrams,
can be
implemented by computer program instructions. These computer program
instructions
may be provided to a processor of a general purpose computer, special purpose
computer,
or other programmable data processing apparatus to produce a machine, such
that the
instructions, which execute via the processor of the computer or other
programmable data
16
CA 02890321 2015-01-14
WO 2014/015294
PCT/US2013/051363
processing apparatus, create means for implementing the functions/acts
specified in the
flowchart and/or block diagram block or blocks.
[0054] These
computer program instructions may also be stored in a computer
readable medium that can direct a computer, other programmable data processing
apparatus, or other devices to function in a particular manner, such that the
instructions
stored in the computer readable medium produce an article of manufacture
including
instructions which implement the function/act specified in the flowchart
and/or block
diagram block or blocks.
[0055] The
computer program instructions may also be loaded onto a computer, other
programmable data processing apparatus, or other devices to cause a series of
operational
steps to be performed on the computer, other programmable apparatus or other
devices to
produce a computer implemented process such that the instructions which
execute on the
computer or other programmable apparatus provide processes for implementing
the
functions/acts specified in the flowchart and/or block diagram block or
blocks.
[0056]
Accordingly, a technical effect of embodiments of the systems, methods, and
devices proposed herein is to facilitate transactions at retail fueling
facilities that may
occur, for example, across a variety of different processing and payment
systems.
[0057] As used
herein, an element or function recited in the singular and proceeded
with the word "a" or "an" should be understood as not excluding plural said
elements or
functions, unless such exclusion is explicitly recited. Furthermore,
references to "one
embodiment" of the claimed invention should not be interpreted as excluding
the
existence of additional embodiments that also incorporate the recited
features.
[0058] The
invention is inclusive of combinations of the aspects described herein.
References to "a particular aspect" and the like refer to features that are
present in at least
one aspect of the invention. Separate references to "an aspect" or "particular
aspects" or
the like do not necessarily refer to the same aspect or aspects; however, such
aspects are
not mutually exclusive, unless so indicated or as are readily apparent to one
of skill in the
17
CA 02890321 2015-01-14
WO 2014/015294
PCT/US2013/051363
art. The use of singular or plural in referring to "method" or "methods" and
the like is not
limiting. The word "or" is used in this disclosure in a non-exclusive sense,
unless
otherwise explicitly noted.
[0059] The
invention has been described in detail with particular reference to certain
preferred aspects thereof, but it will be understood that variations,
combinations, and
modifications can be effected by a person of ordinary skill in the art within
the spirit and
scope of the invention. Examples of variations, combinations, and
modifications that are
intended to be within the scope of the claims are those having structural
elements that do
not differ from the literal language of the claims and those including
equivalent structural
elements with insubstantial differences from the literal language of the
claims.
18
