Fuel dispenser management

Fuel dispenser management

[0001] Related applications

[0002] This application claims the rights of U.S. Provisional Patent Application No. 60/736,488 filed on November 14, 2005 and U.S. Patent Application No. 11/558,825 filed on November 10, 2006, these two applications The titles are all "Fuel Dispenser Management (Fuel Dispenser Management).

Technical field

[0003] The present disclosure relates to refueling, and in particular to a fuel dispenser of a refueling facility.

[0004] Background

[0005] The retail gasoline industry uses various fuel dispensers to refuel customers. Some form of remote fuel dispenser controller is usually used to control the fuel dispenser. The fuel dispenser controller is often located in the same plot as the fuel dispenser, and is coupled to the store interface unit so that the store clerk can monitor and control a specific fuel dispenser from a building (such as a store) in the location. The fuel dispenser controller sends data signals (such as commands) to the fuel dispenser. The data may include price, payment data for the fuel to be refilled, a preset amount of fuel to be refilled, and authorization for refueling. The fuel dispenser similarly sends data signals to the controller, including the pump number, pump status, and fuel volume, and price.

[0006] An example of a type of service that a fuel dispenser controller usually provides to a fuel dispenser is a point of sale (POS)_oPOS services may include cash registers, fuel dispenser control, credit cards, inventory management, processing, and scanning, for example. The POS service is usually implemented in the tanker controller using the open architecture hardware platform and programming to integrate the POS application software of these services.

[0007] Unfortunately, the communication system coupling the fuel dispenser controller and the fuel dispenser is not particularly fault-tolerant. As a result, the communication between the fuel dispenser controller and the fuel dispenser is often interrupted, resulting in the loss of the ability to provide services to the fuel dispenser (such as financial transactions and fuel pump functions). Fuel dispensers may not work for a long period of time, and fail to achieve their main function (namely, refueling). This is inconvenient for customers and a source of income for retail refueling facilities.

[0008] Summary

[0009] Fuel dispenser management can be implemented on fuel dispensers through various systems and technologies. These systems and technologies can improve the safety, reliability and/or efficiency of fuel dispensers.

[0010] In a general aspect, the process performed on the fuel dispenser may include receiving at least a portion of transaction data of a refueling session and determining whether at least a portion of the received transaction data requires security measures. The transaction data may include, for example, the customer's financial information. If at least a part of the received transaction data requires security measures, the process may require security measures to be applied to the at least part of the received transaction data. The process can be performed by a machine, a processor that executes instructions encoded on a machine-readable medium, or other suitable devices.

[0011] In some implementations, determining whether at least a portion of the received transaction data requires security measures may include determining whether at least a portion of the data is stored on a fuel dispenser for more than a short period of time. For example, if the fuel dispenser cannot communicate with the fueling facility computer, the data can be stored on the fuel dispenser for more than a short period of time. The security measures may include at least a part of the security measures required to encrypt the received transaction data. Encryption can use a symmetric key of 512 bits, for example.

[0012] In a particular implementation, determining whether at least a portion of the received transaction data requires security measures may include determining whether to transmit at least a portion of the data to a fueling facility computer. Security measures may include: preparation of received transactions

CN 101356552 Β

At least a part of the data that requires security measures for transportation on the wired communication link, and at least a part of the received transaction data that does not require security measures for transportation on the wireless communication link is prepared. The security measures may also include encrypting at least a part of the received transaction data that requires security measures before being transported via the communication link.

[0013] In another general aspect, the fuel dispenser may include a user input device and a processor. The user input device can be used to receive at least a portion of the transaction data of the refueling session. The processor may be used to determine whether at least a part of the received transaction data requires security measures, and if at least a part of the received transaction data requires security measures, apply security measures to at least a part of the received transaction data.

[0014] The fuel dispenser may include a memory. The memory may, for example, include a rule set, and the processor may be used to make judgments based on one or more rules in the rule set.

[0015] In a specific implementation, the processor can be used to determine whether at least a part of the received transaction data needs to be stored on the fuel dispenser for more than a short period of time, so as to determine whether at least a part of the data requires security measures. If, for example, the fuel dispenser cannot communicate with the fueling facility computer, the data can be stored on the fuel dispenser for more than a short period of time. The processor can be used to encrypt at least a part of the received transaction data that requires security measures to impose security measures.

[0016] In some implementations, the processor may be used to determine whether at least a portion of the received transaction data is to be transmitted to a fueling facility computer, thereby determining whether at least a portion of the data requires security measures. In order to impose security measures, the processor can be used to prepare at least a part of the received transaction data that requires security measures for transport on a wired communication link, and to prepare at least a part of the received transaction data that does not require security measures for wireless communication Ship on the link. The security measures may also include encrypting at least a part of the received transaction data that requires security measures before being transported via the communication link.

[0017] Various implementations may include one or more features. For example, by applying security measures to data stored on fuel dispensers, sensitive data can be protected. In addition, by selectively applying security measures to the stored data, processing power can be saved. As another example, by applying security measures to data to be sent from a fuel dispenser, sensitive data can be protected again. In addition, by selectively applying security measures, bandwidth resources on one or more communication networks can be saved and reliability can be improved.

[0018] One or more implementation details are set forth in the drawings and the following description. Other features will be apparent from the drawings and claims.

Description of the drawings

[0019] FIG. 1 is a block diagram showing one implementation of a system for fuel dispenser management.

[0020] FIG. 2 is a block diagram showing an implementation of a fuel dispenser for fuel dispenser management.

[0021] FIG. 3 is a flowchart showing an implementation of the fuel dispenser management process.

[0022] FIG. 4 is a block diagram showing another implementation of a fuel dispenser management system.

[0023] FIG. 5 is a block diagram showing a detailed implementation of the system of FIG. 4.

[0024] FIG. 6 is a block diagram showing a specific implementation of the fuel dispenser of the system of FIG. 4.

[0025] FIG. 7 is a block diagram showing another implementation of the fuel dispenser of the system of FIG. 4.

[0026] FIG. 8 is a block diagram showing another implementation of the fuel dispenser of the system of FIG. 4.

[0027] FIG. 9 is a flowchart showing an example of a fuel dispenser management process.

[0028] FIG. 10 is a block diagram showing one implementation of a retail refueling facility system with fuel dispenser management. [0029] FIG. 11 is a block diagram showing an example network system of a fuel dispenser.

CN 101356552 Β

[0030] FIG. 12 is a block diagram showing an example of a fuel dispenser for fuel dispenser management.

[0031] FIG. 13 is a flowchart showing an example of a process of coordinating fuel dispensers.

[0032] FIG. 14 is a flowchart showing another implementation of the process of managing a fuel dispenser.

[0033] FIG. 15 is a flowchart showing yet another example of a process for managing a fuel dispenser.

[0034] FIG. 16 is a block diagram showing a fuel dispenser trading system.

[0035] FIG. 17 is a block diagram showing an example of fuel dispenser trade system components.

[0036] FIG. 18 is a flowchart showing the process of fuel dispenser management.

[0037] The same reference numerals in the respective drawings denote the same elements.

[0038] Detailed description

[0039] The safety, reliability, and efficiency of fueling facilities can be improved through intelligent control of fuel dispensers. These benefits can be applied not only to the actual refueling at the fuel dispenser, but also to customers who are refueling. In certain implementations, the fueling facility process and/or system may include the ability to provide enhanced safety, reliability, and/or efficiency by providing enhanced management at one or more fuel dispensers. Enhanced management can, for example, provide point-of-sale functions, fuel dispenser coordination, fuel dispenser diagnostics, data security, and sales capabilities to remote merchants. Other implementations may include one or more of these and other features.

[0040] FIG. 1 shows an implementation of a system 100 for fuel dispenser management. As shown in the figure, the system 100 represents a retail refueling facility, and may represent an automobile gas station environment, a convenience store environment, or any other suitable type of retail refueling facility.

[0041] The system 100 includes a fuel dispenser 110, a facility controller 120, a communication network 130, and a store interface unit 140. The fuel dispenser 110 may be used to refuel customers (eg, gasoline, diesel, liquid propane, or ethanol) at the system 100, usually under at least partial control of the facility controller 120. The communication network 130 enables the facility controller 120 to communicate with the fuel dispenser 110. The communication network 130 also enables the fuel dispenser 110 and the facility controller 120 to communicate with the store interface unit 140. The store interface unit 140 can also be used to provide control functions to the fuel dispenser 110.

[0042] In more detail, the fuel dispenser 110 will be a fuel dispenser, a pump, or any other suitable refueling device. The fuel dispenser 110 may have a single or multiple hose configuration. Depending on its configuration, the fuel dispenser 110 may dispense one or more products (such as gasoline and diesel). The fuel dispenser 110 usually cooperates with the facility controller 120 and the shop interface unit 140 to refuel. In this way, the fuel dispenser can recognize when the customer appears (for example, by detecting the activation of the input device or the removal of the pump handle) and notify the facility controller 120, which can then obtain payment information from the customer, authenticate the customer, And allow the refueling to begin. The fuel dispenser can also transmit the fuel refueling amount to the facility controller, which can complete the sales transaction when the customer finishes refueling. However, the fuel dispenser can work independently of the facility controller and/or store interface unit for specific tasks and/or time periods, as described below.

[0043] The facility controller 120 may be a server, a personal computer, or any other suitable device for interacting with and controlling the fuel dispenser 110. The facility controller 120 generally includes a processor (for example, a microprocessor, a microcontroller, or any other suitable device for processing information in a logical manner), and a memory for storing instructions and/or data for the processor (for example, random Access memory (RAM), read only memory (ROM), compact disk read only memory (CD-ROM), programmable read only memory (PROM), hard drive, and/or any other suitable information storage device). These instructions may include, for example, operating systems (such as Linux, Unix, or Windows) and application programs (such as fuel dispenser control, accounting, and diagnosis). The facility controller 120 may, for example, provide authorization for the fuel dispenser 110, financial transactions, and fueling management. To this end, the facility controller 120 may provide one or more operation commands to the fuel dispenser. In a specific reality

CN 101356552 Β

Currently, the processor can be a single or dual 32-bit processor operating at 600MHz, and the memory can include 512MB of main memory and 4GB of storage. The facility controller may be located in the store of the refueling facility or outside the store.

[0044] The communication network 130 enables the fuel dispenser 110, the facility controller 120, and the store interface unit 140 to communicate with each other. The communication network 130 may operate according to any suitable communication technology including wired (for example, IEEE802.3 or RS-232), wireless (for example, IEEE802.1.CDMA2000 or GPRS), or optical (for example, FDDI or SONET). The communication network 130 may include one or more components to facilitate communication, such as hubs, routers, switches, bridges, repeaters, multiplexers, and transceivers. In certain implementations, the communication network 130 may work through a combined communication technology. [0045] The communication network 130 is coupled to the fuel dispenser 110, the facility controller 120, and the store interface unit 140 through the communication link 150. The communication link 150 may be wired (such as twisted pair or coaxial cable), wireless (such as radio frequency (RF) or infrared (IR)), optical (such as fiber optic cable), and/or any other suitable for transmitting information. path. In a particular implementation, the communication link 150 may include a combination of communication link types (eg, wired and wireless).

[0046] The store interface unit 140 may be a server, a personal computer, a data terminal, or any other suitable device for interacting with the fuel dispenser 110 and/or the facility controller 120. The store interface unit 140 may include a processor and a memory for storing instructions and/or data for the processor. The store interface unit 140 usually also includes a user input device (such as a keypad, a keyboard, a touch screen, and/or a pointing device) and a display device (such as a CRT or LCD monitor). The store interface unit 140 may, for example, allow a store clerk to provide authorization of the fuel dispenser 110 and financial transaction services. To this end, the store interface unit can provide operation commands to the fuel dispenser (such as refueling, pre-determining a specific amount, or printing a receipt). The store interface unit 140 may work in cooperation with the facility controller 120 to provide these services.

[0047] In a working mode, when one of the fuel dispensers 110 detects the presence of a facility customer (for example, by detecting the removal of the pump handle, the activation of a user input device, the insertion of a payment card, or the appearance of a customer identifier) When the time, the fuel dispenser sends a notification to the facility controller 120. The facility controller 120 may then determine the customer plans to rely on its technology to pay for the fuel to be refilled (eg, pay at a fuel dispenser or pay in a store). If the customer indicates that she wants to point out at the fuel dispenser, the facility controller may require the customer to present a customer identifier (for example, a payment card or RFID tag) before allowing the customer to refuel. If the customer indicates that she wants to pay in the store, the facility controller may notify the clerk and allow the clerk to make a decision as to whether or not to refuel.

[0048] When the customer indicates that she wants to pay at the fuel dispenser, the facility controller may prompt the fuel dispenser to request the presentation of the customer identifier. The fuel dispenser can then wait for the presentation of the customer identifier (for example, the insertion of a payment card) and read the information contained therein.

[0049] Generally speaking, at least some customer identification data is sent from the fuel dispenser to the facility controller 120. The facility controller can then determine the validity of the customer identifier. Determining the validity of the customer identifier may include performing a checksum of the data received from it or contacting the issuer of the customer identifier to determine whether the customer identifier is valid. In addition, the facility controller can verify the authorization of the customer identifier. For example, the facility controller may contact the payment card issuer to determine the credit limit of the payment card.

[0050] If the facility controller determines that the customer identifier is valid and/or authorized, the facility controller can activate a fuel dispenser, which can then refuel the customer. When refueling, the fuel dispenser can provide data about refueling to the facility controller (for example, the type of refueling, and the amount of refueling). When the customer finishes refueling (indicated by returning the pump handle), the facility controller can determine the total price of fuel refueled and seek approval for the total price. Once approved, the facility controller can print a receipt to the customer.

[0051] However, in a specific operating mode, one or more fuel dispensers 110 may be able to work independently of the facility controller 120 for at least a specific function and/or time period. In the facility controller 120, the communication network 130, and/or

CN 101356552 Β

This may be particularly advantageous in situations where the communication link is prone to failure (and often so).

[0052] As an example of independent operation, the fuel dispenser 110 may include the ability to provide point-of-sale (POS) operation. That is, the customer can purchase fuel from the fuel dispenser without having to contact the facility controller or the store interface unit. Therefore, if the facility controller 120, the communication network 130, and the store interface unit 140 cannot work, the fuel dispenser can continue to refuel. In order to achieve this, the fuel dispenser may, for example, be able to provide appropriate interaction with the customer (such as requesting a customer identifier) and perform an authentication operation (such as a checksum) of the customer identification data. For example, in some implementations, not all PIN authentication operations can be performed. The fuel dispenser may also be able to record the refueling and financial aspects of the refueling session and provide appropriate commands to the components of the fuel dispenser. The recorded fueling and financial data can be provided to the facility controller for operational management and account checking when communication is reestablished.

[0053] As another example of independent operation, a fuel dispenser can determine how to process data (for example, based on a customer identifier). For example, if part of the data is to be sent to the facility controller and the fuel dispenser can communicate with the facility controller through more than one type of communication link (such as wired and wireless), the fuel dispenser can determine which communication link to use To transfer the data part. For example, some wireless technologies (such as IEEE802.11) can be faster than some wired technologies (such as RS-422), and do not require the same type of semi-permanent infrastructure (such as wiring buried under concrete), but wired links can provide higher Security (for example, by making it difficult for eavesdroppers to enter). The fuel dispenser can thus determine the communication link based on the sensitivity of the pre-specifiable data type. For example, in a specific implementation, a fuel dispenser can send sensitive types of data on a wired link, and send insensitive types of data on a wireless link. It can also make a decision on whether to encrypt the data before sending it. As another example, if part of the data is to be stored on a fuel dispenser (perhaps because communication with the facility controller is not available), the fuel dispenser can determine whether the data should be encrypted. The fuel dispenser can make a determination, for example, based on the sensitivity of the data type. The encrypted data part can be implemented by any appropriate type of encryption scheme (such as a public key or a private key).

[0054] Although FIG. 1 shows a fuel filler for a mechanism to achieve the management system, but other implementations may have fewer, additional, and / or a different arrangement of components. For example, the system may not have a store interface unit. As yet another example, the facility controller may be co-located with or part of the store interface unit 140. As yet another example, the facility controller may be coupled with one or more off-site computer systems (such as payment card issuers or fuel supply systems). The various components and technologies discussed with reference to this implementation can also find use in a variety of other types of systems.

[0055] FIG. 2 shows an implementation of a fuel dispenser 200 for fuel dispenser management. The fuel dispenser 200 includes a fuel dispenser manager 210, a fuel controller 220, a user input device 230, a display 240, a communication interface 250, and a management module 260. The fuel dispenser 200 may be an example of the fuel dispenser 110 of the system 100.

[0056] The fuel dispenser manager 210 is responsible for managing the operation of the fuel dispenser 200. To achieve this, the fuel dispenser manager can control the electronic functions of the fuel dispenser 200. The fuel dispenser manager can also collect and maintain status information about fuel dispensers, and report the status information to the facility controller. The fuel dispenser manager 210 can be implemented by software, hardware, or a combination thereof. As part of its function, the dispenser manager 210 can drive content to be presented on the display 240.

[0057] The fuel controller 220 controls the refueling of the fuel from the fuel dispenser 200. In order to achieve this, the fuel controller 220 may control the hydraulic components of the fuel dispenser required to realize the fuel refueling operation. For example, the fuel controller 220 can control the submersible pump and fuel control valve of the oil storage tank, and monitor the fuel flow information through the metering and reporting subsystem. The fuel controller 220 can also track the amount of fuel added in stages, drive the sales progress display on the sales/volume display, and monitor errors. The fuel controller 220 can be implemented by software, hardware, or a combination thereof.

[0058] The user input device 230 is coupled with the fuel dispenser manager 210, and enables customers of the fueling facility to refuel with fuel

CN 101356552 Β

Machine interaction. The user input device 230 may be a keypad, a keyboard, a touch pad, a touch screen, a card reader, or any other suitable device that enables the user to provide instructions to the fuel dispenser. If the user input device 230 has multiple parts, each part may have a static and/or rearrangeable (for example, software programmable) function.

[0059] The display 240 is also coupled with the fuel dispenser manager 210, and enables customers of the fueling facility to receive data from the fuel dispenser. The display 240 may be a cathode ray tube (CRT) monitor, a liquid crystal display (LCD) monitor, a gas plasma monitor, or any other suitable device for visually presenting information. The content of the display 240 may be provided by the facility controller and/or the management module 260. If the display 240 has multiple parts, these parts may have static and/or reconfigurable functions (eg, software programmable functions). In some implementations, the user input device and the display can work in coordination with each other (for example, the display can present instructions or data from the user input device, and/or input from the user input device can be related to data presented on the display).

[0060] The communication interface 250 is also coupled with the fuel dispenser manager 250, and enables the fuel dispenser to communicate with other components at the fueling facility. The communication interface 250 may be a modem, an RS-232 transceiver, a wireless transceiver, or any other suitable device for sending and/or receiving information.

[0061] The management module 260 provides the fuel dispenser 200 with the ability to operate independently of the facility controller at least for a specific operation and/or time period. These operations may, for example, enable the fuel dispenser to continue to sell fuel when the communication interface 250 cannot send and/or receive data.

[0062] The management module 260 has access to the memory 270, which may be RAM, ROM, CD-ROM, and/or any other suitable information storage device. The memory 270 includes instructions 272, content 274, and logs 276. The instruction 272 specifies at least a part of the operation of the management module 260. The content 274 may be text, graphics, images, and/or video presented on the display 240. The content 274 can be presented in accordance with the instruction 272. The log 276 may contain data about transactions (eg, refueling sessions, financial payments, etc.) and errors. By analyzing the log 276, transactions can be created and analyzed, and errors can be identified and evaluated.

[0063] The management module 260 may be implemented as a rule engine, for example. In such an implementation, the instruction 272 may be a rule (for example, a customer interaction rule and a transaction processing rule), the content 274 may store data used to implement the rule result, and the log 276 may store data used to process the rule. A rule engine usually has a set of conditions that are a precursor to the result being achieved. These conditions can also be prerequisites for other conditions. The rule engine technology that can be used for the management module 260 includes JRules from ILOG Corporation in Mountain View, California, Jess from Sandia National Laboratory in Livermore, California, or any other appropriate rule engine scheme. Engine technology. The management module 260 may be implemented using one or more programming or messaging technologies including HTTP, TCP/IP, XML, SOAP, Universal Description, Discovery and Integration (UDDI), Microsoft. NET, or JavaTM. The various parts of the module can be written, for example, in C++ combined with other programming technologies (such as .NET) or any other appropriate technology.

[0064] In one mode of operation, the tanker manager 210 operates under the control of the facility controller, and at the same time the tanker manager can communicate with the facility controller. The management module 260 can stand by in a passive mode at this time. The facility controller may provide content to be displayed on the display 240, process point-of-sale transactions (such as verifying and charging a credit card), and provide any other appropriate services to the fuel dispenser.

[0065] However, when the dispenser manager cannot communicate with the facility controller, the management module 260 may assume one or more responsibilities of the facility controller. For example, the management module 260 may provide content 274 to the display 240. The content may, for example, enable the user to interact with the fuel dispenser 200 to initiate and complete a refueling session (for example, by providing customer instructions), enable the refueling facility to provide advertisements at the fuel dispenser 200, or allow any other appropriate operations. This content can be provided in accordance with instruction 272. For example, the content of initiating a refueling transaction may be provided when an indication that the customer has interacted with the fuel dispenser is detected.

CN 101356552 Β

[0066] As another example, the management module 260 may provide processing of financial transactions (such as POS transactions) required for a refueling session, so as to enable the fuel dispenser to refuel even when the facility controller or the communication network is not working. POS services may include cash registers, fuel dispenser control, transaction card processing, and/or barcode scanning.

[0067] For example, the management module may determine whether to initiate a refueling session, and if it is to initiate a refueling session, record the relevant parts of the transaction (eg, time of day, credit card number, current price, purchase amount, and purchase Amount). The relevant part of the transaction may be recorded in the log 276. When determining whether to initiate a refueling session, the management module 260 may verify the customer identification information (for example, by performing a checksum), and may determine whether the fuel dispenser is still allowed to refuel. For example, a fuel dispenser may be allowed to independently refuel for a specific amount of time (for example, 6 hours), a specific number of transactions (for example, 25) for a specific amount of fuel (for example, 25 gallons), and/or a specific purchase amount (for example, one thousand dollars) ). For a specific transaction, the fuel dispenser can determine whether the customer identification data is valid and/or limit the transaction to a specific amount (for example, $50). The determination can be made according to instruction 272.

[0068] The management module may also generate a representation of an appropriate fuel dispenser control signal for the fuel dispenser manager 210. For example, an alternative to the customer activated terminal (CAT) and pump commands normally issued from the facility controller can be provided.

[0069] When the tanker manager 210 can communicate with the facility controller again, the management module 260 may download transaction data from the log 260. The facility controller can then process the financial data and send that data to the appropriate entity (such as a payment card issuer or an electronic settlement center (ECH)) to complete the financial transaction. The facility controller can also update its information about the refueling facility (such as the amount of remaining fuel).

[0070] In a specific operating mode, the management module may also be active when the fuel dispenser communicates with the facility controller. The types of services that the management module can provide include POS, fuel dispenser coordination, fuel dispenser diagnosis, data security, and sales capabilities to remote merchants. The POS function as described above may be provided at the fuel dispenser on an all-weather or nearly all-weather basis, for example.

[0071] For fuel dispenser coordination, the management module may generate messages from other fuel dispensers at the refueling facility to help in the operation of the fuel dispenser. For example, the management module may request another fuel dispenser to image the area near the fuel dispenser of the management module. The image can then be sent to the requesting management module for storage and later destruction, analysis, and/or transmission. As yet another example, the management module may request another fuel dispenser to perform a customer interaction function for the fuel dispenser of the management module. For example, the management module may request another fuel dispenser to receive data (such as a customer payment card) or output data (such as a printed receipt) for the fuel dispenser. If the P0S service is not available at the central component (such as the facility controller), the fuel dispenser can coordinate its operation to an appropriate level (such as adding no more than 500 gallons of fuel or $1,000). The ability to coordinate fuel dispensers will be discussed further below.

[0072] As an example of fuel dispenser diagnosis, the management module may determine whether the detected condition requires a response, and facilitate the response. Conditions that can make a response necessary include environmental, mechanical, electrical, and/or logical command conditions, such as temperature, pressure, humidity, fuel leaks, opening panels, fuel dispensers, power abnormalities, watchdog timer expiration, or software abnormalities . Facilitating the response may include restarting the fuel dispenser, shutting down the fuel dispenser, downloading instructions for the fuel dispenser, and/or generating notifications to other components at the fueling facility. The ability to perform fuel dispenser diagnostics will be discussed further below.

[0073] For data security, the management module can determine what data (if any) security measures (such as encryption or routing) should be applied to. Customer's financial data (such as credit card number, PIN, etc.) is an example of data that may require security measures. Security measures can safely store data at the fuel dispenser and/or transmit it to another facility component (such as facility controller). The ability to provide data security is discussed further below.

[0074] As an example of providing sales capabilities for remote merchants, the management module can enable the fuel dispenser to enable remote

CN 101356552 Β

The goods and/or services of a remote merchant are listed and sold, and the remote merchant can be coupled to a fuel dispenser through a communication network. The remote merchant may be any suitable seller of goods and/or services.

[0075] In order to provide sales capabilities, remote merchants can send data before (at one or more times of the day) and/or during the customer's interaction with the fuel dispenser (for example, when the customer indicates interest in a product or service) Download to the fuel dispenser. The data may include information about the merchant's products and/or services, ordering information, and/or delivery information. Fuel dispensers can be responsible for handling interactions with customers (for example, providing merchant data, obtaining order and payment information, and verifying payment data), or merchant computers (such as web servers) can help fuel dispensers to perform one or more of these operations (For example, obtaining payment information and verifying payment data). The ability to provide sales capabilities to remote merchants will be discussed further below.

[0076] In a specific implementation, the management module 260 may be responsible for providing messages (for example, commands and/or data) to the fuel dispenser manager 210 to complete the operation of the module. For example, the management module can forward or replace messages (whether in the form of structured messages, unstructured messages, or signals) from remote computers (such as facility controllers). The management module may, for example, receive a command message from a remote computer and determine that the message should be provided to the dispenser manager 210 in an unaltered state. This can be done, for example, when the fuel dispenser is operating in normal mode, and the message relates to normal operation. The management module 260 may thus pass the message to the dispenser manager. As another example, the management module 260 may have one or more specific technologies for communicating with the dispenser manager, and thus replace the message from the remote computer with a message that accomplishes the same function. As another example, the management module 260 may determine that it needs the fuel dispenser to perform a function, and send a message to the fuel dispenser manager 210 under the impetus to perform the function. For example, an alternative to the customer activated terminal (CAT) and pump messages that are usually sent from the facility controller can be provided.

[0077] Although FIG. 2 shows one implementation of a fuel dispenser, other fuel dispenser implementations may include fewer, additional, and/or different component configurations. For example, a fuel dispenser may not include content because the content may not be needed for customer operations of the fuel dispenser. As another example, a fuel dispenser may include multiple displays and user input devices, especially when the fuel dispenser has multiple refueling sides. As yet another example, the memory of the management module may be shared with the memory of the tanker manager. In addition, the memory of the management module may have various forms and/or configurations.

[0078] FIG. 3 shows an implementation of a process 300 for fuel dispenser management. The process 300 may, for example, exemplify a mode of operation for one of the fuel dispensers 110 in the system 100.

[0079] The process 300 waits until the customer wants to initiate a refueling session before starting (operation 304). Determining whether the customer wants to initiate a refueling session can be done, for example, by detecting the removal of the pump handle, the activation of a keypad, or the insertion of a payment card.

[0080] When the customer wants to initiate a refueling session, the process 300 requires determining whether communication with the facility controller is available (operation 308). Determining whether communication with the facility controller is available can be achieved, for example, by determining whether the facility controller responds to a status request. If communication with the facility controller is available, the process 300 continues to place the module responsible for determining whether to refuel (operation 312) into a passive state (operation 312), and generates a signal related to initiating a refueling session (operation 316). The module may be, for example, a point of sale module, and the signal may indicate to the facility controller that the customer wants a refueling session.

[0081] The process 300 continues to receive command signals related to fueling (operation 320). These signals may include, for example, information about obtaining payment data from customers and refueling authorizations. The process 300 also requires refueling (operation 324) and generates a signal about the refueling session (operation 328). The signal may, for example, indicate the status of the fuel dispenser (eg pumping) and the status of the session (amount of fuel added). The process 300 also includes determining whether the refueling session is complete (operation 332). Determining whether the refueling session is complete can be, for example, by detecting that the pump handle has been replaced, the activation of the keypad, or any other appropriate session completion indication

CN 101356552 Β

To be done.

[0082] If the fueling session is completed, the process requires returning to wait until a customer wants to initiate a fueling session (operation 304). However, if the refueling session is not completed, the process requires refueling to continue (operation 324).

[0083] If a customer wants to initiate a refueling session and the communication with the facility controller is not available, the process 300 requires that the module responsible for determining whether to refuel is placed in the active state (operation 336), and it is determined whether to refuel the customer (Operation 340). Determining whether to refuel can be done, for example, by requesting customer identification data from the customer and analyzing the data to determine whether it is acceptable. For example, an error check (such as a checksum) can be performed on customer identification data. As another example, a fuel dispenser can determine whether it is still operating within one or more pre-established criteria (for example, no more than 500 gallons of fuel can be added when the module is active).

[0084] If the customer should not be refueled, the process 300 requires returning and waiting until a customer wants to initiate a refueling session (operation 304). However, if the customer should be fueled, the process 300 requires fueling (operation 344). Refueling may, for example, include generating an activation signal to the fuel controller. The process 300 also requires storing data about the fueling session (operation 348). The data may be stored in a transaction log, for example, and may include time, date, customer identification data, amount of fuel added, and total price.

[0085] The process 300 continues to determine whether the fueling session is complete (operation 352). If the refueling session is not completed, the process requires refueling to continue (operation 344). However, if the refueling session is completed, the process requires returning to wait until a customer requests to initiate a refueling session (operation 304).

[0086] Although FIG. 3 illustrates one implementation of a fuel dispenser management process, other fuel dispenser management processes may include fewer, additional, and/or different operating configurations. For example, the fuel dispenser management process may include determining whether communication with the facility controller is available before determining that a customer wants to initiate a fueling session. As another example, the management process may place the module responsible for determining whether to refuel or not before determining whether communication with the facility controller is available. Thus, the activation or deactivation of the module may not depend on the communication status of the facility controller. As yet another example, the management process may generate and receive signals related to the refueling session multiple times before, during, and/or after the refueling session. As an additional example, the management process may send data stored when communication with the facility controller is not available when communication with the facility controller is available.

[0087] FIG. 4 shows another implementation of a system 400 for fuel dispenser management. The system 400 includes a store controller 410, an external point of sale (POS) device 420, a fuel dispenser 430, and a POS link 444. The system 400 may also include additional fuel dispensers, but one fuel dispenser is sufficient for understanding the system 400. The store controller 410 and the external point of sale (POS) device 420 are interconnected with the fuel dispenser 430 to control at least a part of its operation.

[0088] Generally, fuel dispensers in existing refueling facilities rely on data transmitted to it from the external POS device 420 via the POS link 144 to initiate a refueling session. The external POS device may be part of the facility controller, for example. The transmitted POS data enables the POS device 420 to control financial transactions and pump functions. However, in the system 400, the fuel dispenser 430 has the ability to perform at least some POS functions by itself. For example, the fuel dispenser 430 may determine whether to accept a payment card, refuel when the payment card is acceptable, and record data during a refueling session for billing purposes. Therefore, the fuel dispenser 430 can operate in an autonomous mode from the external POS device 420 at least during busy hours (for example, several hours), which provides the system 400 with robustness and increases opportunities for customers to refuel transactions.

[0089] FIG. 5 shows a detailed view of one implementation of the system 400. In this implementation, the fuel dispenser 430 includes a POS module 431 in the fuel dispenser, which enables the fuel dispenser to perform a refueling session in a stand-alone mode when the POS device 420 or the POS link 444 becomes inoperable. For example, the POS module 431 may provide POS functions, which may include cash registers, fuel dispenser control, transaction card processing, and/or barcode scanning.

CN 101356552 Β

[0090] The store controller 410, the POS device 420, and the fuel dispenser 430 are coupled together via a communication network 440. In this implementation, the communication network 440 includes a hub 442 for distributing communications between components. The POS device 420 generates a customer activation terminal (CAT) and pump commands that are transmitted to the fuel dispenser 430 via the link 444 via the hub 422. These commands can be represented by signals, structured messages, or other appropriate technologies through which information is conveyed. The store controller 410 is linked with the hub 442 via the communication link 446. The system 400 also includes a diagnostic and asset management system 480, as shown here, which may be located in a store or elsewhere in a fueling facility. The diagnostic and asset management system 480 is also coupled to the hub 442 via a communication link 446.

[0091] The fuel dispenser 430 includes a dispenser manager 432, a pair of VGA displays 433 including soft keys, and a controller 434 for managing peripheral components or a bezel. The fuel dispenser manager 432 or the POS module 431 drives the content associated with the VGA display 433 to provide interaction with customers. The dashboard controller 434 provides and controls user input to the fuel dispenser 430.

[0092] The fuel dispenser 430 also includes a fuel dispenser computer 436. The fuel dispenser computer 436 controls the fuel flow aspect of the fuel dispenser 430. For example, the fuel dispenser computer 436 can control the submersible pump and the fuel control valve of the oil storage tank, and monitor the fuel flow information, grading total, errors, etc. through the metering and reporting subsystem. The tanker manager 431 interoperates with the tanker computer 436 to deliver commands and receive transaction data and status. For example, the fuel dispenser manager 432 may issue commands to the fuel dispenser computer 436 via the internal communication link 437 (eg, a bus) of the fuel dispenser 430. Control, status, real-time diagnostics, errors, and data can also be exchanged via the communication link 437. In addition to controlling the fuel flow necessary for the fuel dispenser to perform the fueling function, the fuel dispenser computer 436 can also drive the sales progress display on the sales/volume display of the fuel dispenser 430. The fuel dispenser manager 432 also collects and maintains the status of the fuel dispenser 430, and reports the status information to the store controller 410 and/or the POS device 420.

[0093] The POS module 431 is associated with the fuel dispenser manager 432 in the fuel dispenser 430 and provides a fault-tolerant architecture to ensure that the POS device 420, HUB 442, or link 444 crashes, goes offline, or becomes unavailable in other ways Time-use fuel dispenser function. To this end, the POS module 431 can be used to perform related POS functions for operating the fuel dispenser 430 in an autonomous mode during at least part of the busy hours (for example, two hours). These functions include, but are not limited to, store/forward, transaction records, and URL and payment card processing. These functions may be a subset of the functions necessary to operate the fuel dispenser on a long-term basis, and the subset may reside in the POS device 420.

[0094] To facilitate its operation, the POS module 431 accesses multiple databases 439 stored in the memory 438 of the fuel dispenser 430. The database 439 includes data for operating the POS module 431 in a stand-alone mode. The data may include, but is not limited to, URL439a or include customer instruction prompts, refueling status information, advertisements, various business rules 439b for the operation of the POS module (including oil prices, tender media authorization information, oil pump operation rules, etc.) Display content, completed transactions and error log 439co

[0095] The system 400 provides various features. For example, due to the networking and POS functions available in the fuel dispenser, the system can be implemented with standardized networking technology. Therefore, the distribution box, the third-party interface box, and the third-party POS intermediary can be eliminated. In addition, it provides the basis for the order number in the dispenser.

[0096] Although FIG. 5 shows one implementation of the system 400, other implementations of the system 400 may include fewer, additional, and/or different component configurations. For example, the system may not include a store controller. As another example, the POS device may be co-located with, and/or part of the store controller. As yet another example, fuel dispensers can have various configurations, as shown in Figures 6-8.

[0097] FIG. 6 shows a specific implementation of the fuel dispenser of the system 400. The fuel dispenser in this implementation includes associated

CN 101356552 Β

The POS module in the fuel dispenser and the fuel dispenser manager 432. The fuel dispenser manager and the POS module in the fuel dispenser can be associated with different sides of the fuel dispenser, for example. The fuel dispenser manager 432 provides visual data to the corresponding display 433 and receives user input instructions from the corresponding controller 434. The fuel dispenser manager 432 may communicate with the fuel dispenser computer 436 through the communication link 437 to request fuel and receive fuel-related data.

[0098] FIG. 7 shows another implementation of the fuel dispenser of the system 400. The fuel dispenser in this implementation includes a dashboard controller and interface 435 for receiving input to the fuel dispenser. The dashboard controller and interface provide data to the tanker manager 432, which can provide appropriate data to the POS module 431 in the tanker. The tanker manager 432 may communicate with the tanker computer 436 through the dashboard controller and interface 435.

[0099] FIG. 8 shows another implementation of the fuel dispenser of the system 400. The fuel dispenser in this implementation includes an associated POS module 431 and a dispenser manager 432 in the fuel dispenser. The fuel dispenser manager and the POS module in the fuel dispenser can be associated with different sides of the fuel dispenser, for example. The fuel dispenser manager 432 receives user input instructions from the corresponding controller 434. The fuel dispenser manager 432 may communicate with the fuel dispenser computer 436 through the communication link 437 to request fuel and receive fuel-related data.

[0100] FIG. 9 shows an example of a process 900 for fuel dispenser management. Specifically, the process 900 is an example of a process for running a POS module such as the POS module 431. In the process 900, the POS module 431 maintains a passive state when the external POS device is operating in the normal application mode (operation 904). However, once it is determined that the link with the external POS device is not available (operation 908), the POS module starts to operate in a stand-alone state (operation 912) until it is determined that the link with the external POS device has been reestablished (operation 916). After the link is reestablished, the POS module returns to the passive state (operation 904).

[0101] Although FIG. 9 shows an implementation of a process for running a POS module, other processes for running a POS module may include fewer, additional, and/or different operating configurations. For example, the POS module can run on a full-time basis. This can provide a scaled-down version of the facility controller described with reference to Figure 1, since most POS functions can be handled by the fuel dispenser. As another example, the POS module may be ordered to run when the external POS device becomes offline for repair or replacement. Therefore, the pos module can actively support the operation of the refueling facility.

[0102] FIG. 10 shows an implementation of a retail refueling facility system 1000 with fuel dispenser management. The system 1000 includes a retail fueling facility 1010, which includes two island regions each containing six fuel dispensers 1022. The fuel dispenser 1022 can be used to refill the fuel received from the fuel storage tank 1040 via the fuel pipe 1030. The oil storage tank 1040 includes storage tanks 1042a, 1042b, and 1042c that can store different types or grades of fuel oil. Although the foregoing components provide an infrastructure for refueling customers of retail refueling facilities, in various implementations, the number and configuration details of the island area 1020, fuel dispenser 1022, oil storage tank 1040, and storage tank 1042 can be modified, for example, Change or adjust in other ways for specific implementations.

[0103] The fuel dispenser 1022 provides a man-machine interface that facilitates a refueling session. The fuel dispenser 1022 is described in more detail with reference to Figs. 11-12. The fuel dispenser 1022 of the island area 1020± is coupled to communication information via the communication link 1024 local to the island area. In various implementations, the communication link 1024 may be implemented using any suitable combination of physical or non-physical links that provide a path to convey information. For example, the communication link can be wired (such as unshielded twisted pair (UTP), coaxial cable, or fiber optic cable) and/or wireless (such as RF or IR) link layer and can use any appropriate standard or proprietary Communication protocols and interfaces (such as HTTP, TCP/IP, Bluetooth, wireless local area network (WLAN), controller area network (CAN), RS-485, RS-232, universal serial bus (USB) or Ethernet). The communication link 1024 may include any suitable collection of devices for carrying data (eg, leads, cables, hubs, transceivers, routers, repeaters), and in some examples may be a communication network. In some implementations, the communication link 1024 can be used to transmit between the fuel dispensers 1022 in the island area 1020 ±

CN 101356552 Β

For information purposes. In various implementations, one or more of the fuel dispensers 1022 may be configured to generate messages that, when received by one or more other fuel dispensers 1022 via the communication link 1024, cause the receiving fuel dispenser to communicate with One or more fuel dispensers essentially cooperate to perform operations.

[0104] Each island area 1020 also includes an island area auxiliary device 1026 that generally provides functions dedicated to each island area 1020 and supplements the basic refueling function of the island area. The island zone auxiliary device 1026 can optionally be controlled by commands, such as commands generated by one of the fuel dispensers in the same island zone. Examples of auxiliary devices that can be configured to be at least dedicated to the operation of a particular island area 1020 include communication devices (such as intercom systems), audio and/or video recording or playback systems, diagnostic devices such as fuel spill detectors, and emergency fuel cutoffs. Controls, anti-theft systems, surveillance devices, lighting, and proximity detection devices that detect the presence and/or location of vehicles approaching the island area. Other devices at least dedicated to the operation of the island area 1020 may also be included in the auxiliary device 1026 of the specific island area 1020.

[0105] In this implementation, the island area 1020 may coordinate its operation by communicating via the communication link 1054. The communication link 1054 may be configured to convey a message sent by a fuel dispenser 1022 in one of the islands 1020 to a device such as one or more of the fuel dispensers 1022 in another island 1020. In various implementations, the communication link 1054 can be implemented using any suitable wired and/or wireless link layer, and can use any suitable standard or dedicated communication protocol and interface. The communication link 1054 may include any suitable collection of devices for carrying data (eg, leads, cables, hubs, transceivers, routers, repeaters), and in some examples may be a communication network. In some implementations, communication link 1054 may be part of a communication network that includes communication link 1024, or may be integrated with it in other ways.

[0106] The communication link 1024 and the communication link 1054 may respectively provide links for transmitting messages between the fuel dispensers 1022 in the island area 1020 or between the island areas 1020. For example, the fuel dispenser 1022 may communicate with one or more fuel dispensers 1022 in the same island area 1020 or with one or more specific fuel dispensers in another island area 1020 related to its operation. These messages may include a request for the receiving fuel dispenser 1022 to perform a certain service or operation. In this way, the fuel dispenser 1022 in one island 1020 can communicate a message to coordinate its operation with the fuel dispenser 1022 in the same island area and/or another island area.

[0107] Fuel dispensers 1022 may communicate with each other to facilitate various operations in a coordinated manner. For example, if the fuel dispenser 1022 detects a fault condition (such as an oil leak or fluid in thepan), the fuel dispenser 1022 may coordinate with one or more other fuel dispensers 1022 to respond appropriately. Other conditions that can trigger the need for coordination include: receipt of a message from a remote device (for example, to perform a diagnostic function), loss of communication with the central computer, detection of a possible departure situation, and failure of the user interface device.

[0108] Examples of operations that the coordinated fuel dispenser 1022 can perform include the use of image capture devices controlled by the fuel dispenser, such as when a possible departure (without payment) is detected or a fuel leak is detected. Advantages of capturing image data; providing user interface functions for fuel dispenser failures; activating the shutdown state such as refueling pause when a possible fuel leak or overflow is detected; such as restarting the controller in the fuel dispenser when a processing failure occurs ; And redundantly store data in multiple fuel dispensers to allow information recovery when data is lost. Coordinated operations can be used to provide any of a variety of services to a fuel dispenser as a single entity or as a group of two or more fuel dispensers.

[0109] One example of coordinated operation involves alternate user interface services. For example, when the printer in the fuel dispenser (for example, due to lack of paper or printer failure) or the card reader cannot be used, the fuel dispenser may require backup user interface services. In a situation where, for example, a fuel dispenser has a malfunctioning printer, the fuel dispenser may complete the refueling session by sending a request to print out a transaction receipt to an alternative neighboring fuel dispenser. This is just one way to clarify how fuel dispenser coordination can improve the available "uptime" of fuel dispensers, reduce costs, and improve the quality of service customers receive.

CN 101356552 Β

Examples.

[0110] Appropriate fuel dispensers for coordinated operation can be pre-designated. For example, if a fuel dispenser determines that it needs to capture images of a vehicle that is refueling, it may already have the identity of one or more fuel dispensers capable of capturing these images. As another example, if the user interface (such as a printer) of a fuel dispenser is not working, the fuel dispenser may enable its user interaction (such as receipt printing) to be performed by a neighboring fuel dispenser.

[0111] Yet another example of coordinated operation involves interactive availability status monitoring and diagnostic testing between fuel dispensers. In some implementations, an idle fuel dispenser can initiate a communication session to monitor the availability of one or more other fuel dispensers by using the communication interface, using processing functions, and verifying the integrity of the stored information. For example, the initiating fuel dispenser can perform various predetermined availability checks on the second idle fuel dispenser. The initiating fuel dispenser may further receive and record the results and the response from the second fuel dispenser.

[0112] As an illustrative example, the fuel dispenser that initiated the diagnostic test may verify whether the recorded amount of fuel added by the second fuel dispenser falls within a desired range. The desired range can be based on the recorded transaction information and the time since the last diagnostic check. If the recorded value of the refueled fuel falls outside the desired range, the initiating fuel dispenser may indicate, for example, that a device or operational failure has occurred (eg, a fuel leak, a memory error, or a gauge failure). This diagnostic availability check can be performed at regular intervals, during idle time (such as when not participating in a refueling transaction), or in response to a command entered by the user. Therefore, some implementations can provide coordinated operation of fuel dispensers in order to quickly detect and accurately identify fuel dispenser problems at an early stage.

[0113] When the diagnosis result deviates from the expected result or exceeds the allowable tolerance, the initiating fuel dispenser may be configured to initiate corrective action. Examples of possible corrective actions include: restarting the controller on the second fuel dispenser; sending instructs the second fuel dispenser to display a message on its user interface indicating that the function is currently restricted or modified (for example, "This printer is currently Cant work. Your receipt will be printed in fuel dispenser #4." or "Credit card reader is currently not working. Please swipe your card at fuel dispenser #8 or go to the cashier.") command; and generate a repair request message To trigger the maintenance of the first fuel dispenser.

[0114] Certain implementations may require fuel dispensers to authenticate each other before they can perform coordinated operations. Authentication can be done by any appropriate technology. For example, the fuel dispenser that generated the message may include the identifier and password in the message sent to the service provider fuel dispenser. Authentication can be performed on a message-by-message, transaction-by-transaction, or session-by-session basis.

[0115] In other implementations, the fuel dispensers 1022 may not be arranged in groups of islands 1022. Thus, the exemplified implementation has been used in a non-limiting manner to describe coordination between multiple fuel dispensers located in and around a retail fueling facility by communicating messages on a communication link to transfer messages between fuel dispensers .

[0116] In addition to transmitting messages between fuel dispensers in different island areas 1020, the communication link 1054 implemented in this example is also coupled to a communication network 1050 including a network hub 1052, and a facility auxiliary device 1060. The network hub 1052 may provide a message distribution service for messages sent in packets or frames via the communication link 1054, for example. In alternative implementations, the islands 1020 and/or fuel dispensers 1022 may be arranged in a hub-and-spoke structure around the hub 1052, or they may be arranged in a ring, layered, or daisy chain network configuration, for example. For example, in some implementations, the message may have to pass through one or more intermediate fuel dispensers to reach its destination. The communication link 1054 also transmits messages such as commands, data, or control signals between the hub 1052 or island area 1020 and the facility auxiliary device 1060.

[0117] The facility auxiliary device 1060 generally provides a function that is not unique to the specific island area 1020 but supports the function of the retail fueling facility 1010. The facility auxiliary device 1060 may be controlled by a command such as a command generated by one of the fuel dispensers 1022. Examples of facility assistance devices 1060 include: communication devices (such as internal communication systems), audio, and/or

CN 101356552 Β

Video recording or playback systems, diagnostic devices such as fuel spill detectors, emergency fuel cut-off controls, anti-theft systems, surveillance devices, lighting, and proximity detection devices that detect the presence and/or location of vehicles near islands.

[0118] The network hub 1052 is also configured to send messages from the facility controller 1070. The facility controller 1070 may include a computing system, such as a client connected to a remote server (not shown) through a communication link 1080 coupled to a communication network 1090 external to the retail fueling facility 1010. In some implementations, the communication link 1080 may transmit information packets in a digital format via a wired, fiber optic cable, or wireless channel (including, for example, UTP, telephone line, T1, ISDN, etc.). The network 1090 may be implemented in a network system such as VPN (Virtual Personal Network), WAN (Wide Area Network), WLAN (Wireless Local Area Network), IEEE 802.16 Wireless MAN (Wireless Metropolitan Area Network), or the Internet. In other implementations, the facility controller 1070 may include a stand-alone computing system, such as a PLC (programmable logic controller), laptop, desktop, or handheld computer, that may or may not be connected to an external network such as the network 1090. In other implementations, the fuel dispenser 1022 may communicate with a computer remote from the system 1000 through the facility controller 1070 or through another route (perhaps through communication with a communication network outside of the facility 1010).

[0119] Via the network hub 1052, the facility controller 1070 may send messages related to coordinated operations to one or more of the fuel dispensers 1022. These messages may include program instructions or information such as control signals or data. The program instructions may, for example, be stored in part or all of the fuel dispenser 1022 to configure the fuel dispenser to operate in a coordinated manner. Some implementations enable the fuel dispenser to execute program instructions and perform coordinated operations without or substantially without additional information from the facility controller. The facility controller 1070 may also receive messages from the fuel dispenser 1022 via the hub 1052. The message from the fuel dispenser may include, for example, status data, repair requests, and data such as the amount of fuel refilled and recorded transaction information. These messages may further include data from the auxiliary device 1026 or 1060, such as image and/or audio information. When the fuel dispenser is in use (ie online) or not in use (ie offline), some data may be transferred between the facility controller 1070 and the fuel dispenser 1022. When the fuel dispenser is online, some data (such as data on security or theft) can be exchanged with the facility controller 1070 in real time, and other data (such as updated program instructions, diagnosis results, etc.) can be exchanged at intervals.

[0120] Although an exemplary retail refueling facility 1010 that can retail gasoline and diesel for general-purpose vehicles (such as automobiles and/or trucks) has been described with reference to FIG. 10, other refueling applications such as commercial, wholesale, or private refueling equipment may be used. Use other implementations. The added oil can be used, for example, in automobiles, airplanes and/or ships.

[0121] FIG. 11 shows an implementation of a network system 1100 for a fuel dispenser. Using the network system 1100, each fuel dispenser 1110 can communicate messages to coordinate its operations. As shown in the figure, the network system 1100 includes three fuel dispensers 1110 that can communicate with each other to perform operations in a coordinated manner.

[0122] Each fuel dispenser 1110 includes a controller 1112 having a network interface 1113. The controllers 1112 are each coupled to a user interface (UD 1114, fuel controller 1116, and auxiliary device 1118. Various aspects of the exemplary fuel dispenser will be described in more detail below with reference to FIG. 12.

[0123] In this implementation, fuel dispensers 1110 can communicate with each other via a communication link 1120, which is coupled to a network interface 1113 (for example, a network interface card) of each fuel dispenser. The communication link 1120 can be connected to a fuel dispenser 1110 in a network such as a LAN. Also in this example, the communication link 1120 is coupled to a hub 1130, which can provide message distribution services and an interface to another communication link 1140 . The hub 1130 may distribute messages between fuel dispensers and/or between the fuel dispenser 1110 and the communication link 1140, and the communication link 1140 may convey the messages to the facility controller and/or other fuel dispensers.

[0124] In addition, or as an alternative, the communication link 1120 and the fuel dispenser 1110 may pass through the communication link 1150

CN 101356552 Β

Communicate with each other. In this implementation, the communication link 1150 is coupled to each fuel dispenser 1110 via a communication interface (eg, RS-232) associated with the auxiliary device 1118. The communication link 1150 may include wired and/or wireless links. The communication link 1150 may provide a channel dedicated to conveying information between the fuel dispenser 1110, because it may not be possible to directly transmit messages between the network hub 1130 and the fuel dispenser 1110.

[0125] In an illustrative example, the controller 1112 in the fuel dispenser 1110b may generate a service request message to be sent to the fuel dispenser 1110a.1110c via the communication link 1120 and the corresponding network interface 1113. The receiving fuel dispenser 1110a, 1110c may respond to the service request message by performing one or more operations. Receiving fuel dispenser 1110a.ll10c can simply listen to messages from fuel dispenser 110b, or they can communicate with fuel dispenser 1110b interactively. If configured to listen to messages, the corresponding controller 1112 can, for example, when computing bandwidth and resources become available (for example, low-priority interrupts), immediately after receiving (for example, non-maskable interrupts), at a predetermined time of the day , Respond to predetermined inputs, or perform operations during regularly scheduled times for servicing these requests. If configured to interactively listen to and respond to messages from the fuel dispenser 1110b, the fuel dispensers 1110a, 1110c can perform operations in a predetermined sequence, for example, where the fuel dispenser can wait to perform certain operations until it receives an instruction A message that an operation has been executed by another fuel dispenser.

[0126] FIG. 12 shows an implementation of a fuel dispenser 1200 for fuel dispenser management. The fuel dispenser 1200 may be an example of the fuel dispenser 1110. The components of the fuel dispenser 1200 may participate in the transmission of network messages and/or the execution of refueling operations. The fuel dispenser 1200 includes a controller 1210 having a network interface 1224, a user interface (UD 1230, a fuel controller 1240, and an auxiliary device 1250). The controller 1210 may be a dedicated or general-purpose computer, for example.

[0127] The controller 1210 provides local intelligence for the communication and operation of the fuel dispenser 1200, including operations that can be coordinated with one or more other fuel dispensers. The controller 1210 includes a processor 1212, such as a microprocessor, a microcontroller, a programmable logic device, or other suitable devices for processing information in a logical manner. The processor 1212 is coupled to a bus 1226, which enables the processor 1212 to communicate with each other including NVM (non-volatile memory) 1214, RAM (random access memory) 1216, DSP (digital signal processor) 1218, and HW (hardware ) The controller 1222, I/O (input/output) controller 1220 and the peripheral or supporting device of the network interface 1224 exchange information. NVM 1214 provides non-volatile data storage, It may also include a computer program product containing stored instructions that, when executed by the processor 1212, cause the processor to perform operations in a coordinated manner with two or more other fuel dispensers (as described in this document). The computer program product may be, for example, a module that is associated with the tanker manager that may be part of the controller 1210 or operated therein. The fuel dispenser manager may be, for example, a computer program product also in the NVM 1214, and/or various components of the controller 1210 (such as the processor 1212, the HW controller 1222, the I/O controller 1220, and/or the network interface 1124) combination. RAM 1216 can provide volatile data storage that the processor can use, for example, as a scratchpad. The DSP 1218 enables the fuel dispenser 1110 to perform computationally intensive operations, such as video or audio recognition or synthesis, in a coordinated manner.

[0128] In an example, the DSP 1218 can process a large data set including video image data, and can be used to detect when the vehicle is close to the fuel dispenser 1200. If, for example, the DSP 1218 determines that the vehicle has left the fuel dispenser, and the processor 1212 determines If payment for the fuel has not been received, multiple steps can be taken to record possible unpaid departures. A fuel dispenser that detects a possible unpaid departure condition can, for example, send a message to other fuel dispensers while controlling an imaging device that attempts to capture an image of the event. The request may specify a time delay for a specific camera to record images at a specific angle, thereby increasing the possibility of capturing information identifying the driver and vehicle, for example.

[0129] The user interface 1230 is coupled to the controller 1210 through the I/O controller 1220. In this example, the UI 1230 includes a display device 1232, an input device with an audio system 1234, and a card reader that reads debit and credit cards

CN 101356552 Β

1236. The UI 1230 may also include a printer (not shown) that provides a transaction receipt to customers who want to use, for example, a payment card to pay for the transaction.

[0130] The fuel controller 1240 is coupled to the controller 1210 through the HW controller 1222. The fuel controller 1240 includes a gauge 1242 and a pump 1244. The gauge measures, for example, the amount of fuel added, and the controller 1210 can be used to determine, for example, the amount of fuel added in a particular transaction. The oil pump 1244 pumps the oil to be added from the oil pipe.

[0131] The auxiliary device 1250 is also coupled to the controller 1210. In this implementation, the auxiliary device 1250 includes a communication port (COM) 1252 that can use, for example, a serial port. The COM port 1252 may be coupled to a serial bus, such as the communication link 1150 in FIG. 11. The auxiliary device 1250 also includes an imaging system 1254 and a set of sensors 1256. The imaging system 1254 can control one or more cameras associated with the fuel dispenser, and these cameras can be used in a coordinated manner to detect and identify possible unpaid departures as described above. The imaging system 1254 can capture still or moving images. The sensor 1256 includes a tamper sensor 1258, a vehicle proximity sensor 1260, and a diagnosis device 1262.

[0132] The imaging system 1254 can also be used to capture data before an unpaid departure event occurs. For example, depending on conditions (eg, after ten o'clock in the evening and/or no customer identification before refueling), the imaging system may obtain images of the customer and/or vehicle during the refueling session. Using a motion determination device (such as DSP 1218), it is also possible to start imaging before the start of the refueling session, which can increase the chance of capturing identification data (such as the license plate of a vehicle). If the customer later pays for the fuel added, the fuel dispenser can erase the image from its memory. However, if the customer does not pay for fuel within a predefined period of time (for example, ten minutes), the fuel dispenser can transmit the image to a remote computer to generate a report to the authority or just a report.

[0133] Fuel dispensers may also coordinate with other fuel dispensers to capture images before, during, or after a refueling session. This image data can increase the possibility of capturing the identification data. The image data can be sent to the requesting fuel dispenser, where the image data can be stored and erased or transmitted later. The data can also be temporarily stored on the imaging tanker until the fuel tanker in use determines whether the image data is useful. The fuel dispenser in use can then notify the auxiliary fuel dispenser whether to erase or transmit image data.

[0134] The imaging system 1254 can also capture images of the physical conditions around the fuel dispenser. For example, the image of the ground is useful for determining whether there is a fuel leak, and the image of the fuel dispenser itself can be useful for determining whether the fuel dispenser has been improperly connected (such as opening the access panel). The imaging of the physical conditions around the fuel dispenser can also be completed by imaging systems of other fuel dispensers to provide additional image data of the fuel dispenser and its environment. The fuel dispenser can coordinate this imaging. The image data can be stored locally on the fuel dispenser and/or sent to a remote point, such as a service provider's computer.

[0135] The imaging system 1254 may be additionally used to provide customer service. For example, the imaging system can image the area near the fuel dispenser so that shop assistants or others who understand the functions of the fuel dispenser can help customers.

[0136] The diagnostic sensor 1262 can also be used in a coordinated manner. For example, if a fuel dispenser detects a problem with itself or its environment, it can contact other fuel dispensers to determine whether they are detecting similar problems. If, for example, only the initiating fuel dispenser encounters the problem, appropriate measures can be taken to alleviate the problem (for example, restarting, redistributing one or more of its operations, or shutting down). However, if all fuel dispensers encounter the same problem, they all need to be reset and/or shut down.

[0137] FIG. 13 illustrates a process 1300 for managing a fuel dispenser. The process 1300 generally illustrates a process for coordinating operations between fuel dispensers, and may illustrate the operation of one or more of the fuel dispensers described above. In particular, this process can be implemented by the management module of the fuel dispenser.

CN 101356552 Β

[0138] The process 1300 starts with the fuel dispenser (FD#1) identifying at least one operation to be performed (operation 1305). This operation may be in response to, for example, the occurrence of a condition, such as the appearance of an input signal (ie, a user command), the appearance of a sensor input (for example, detection of a possible unpaid departure), or a message from another fuel dispenser (ie, the message Contains the receipt of FD#1 request to perform an operation) and is identified. FD#1 then estimates whether the identified operation involves coordination with at least one other fuel dispenser (operation 1310). If it is not involved, FD#1 performs the identified operation (operation 1315), and the process ends (operation 1320). However, if the identified operation does involve the coordination, FD#1 identifies which fuel dispensers are to perform the coordination operation (operation 1325).

[0139] Next, the process is divided into two parallel branches. On one branch, FD#1 performs any identified operations in coordination with operations being performed by other fuel dispensers at the appropriate time (operation 1330). In some examples, FD#1 may not have any operations to perform, in which case this part of the process ends (operation 1320).

[0140] On the other branch, FD#1 estimates whether the message containing the coordination request will be broadcast to all other fuel dispensers (operation 1335). For example, if the identified operation is to be performed by all available fuel dispensers, a message is broadcast. If a message is to be broadcast, FD#1 assembles a network message containing the identified operation (operation 1340) and sends the network message to all active fuel dispenser network addresses (operation 1345). If the message will not be broadcast, FD#1 selects the first one of the identified fuel dispensers (operation 1350), determines the operation to be performed by the selected FD (operation 1355), And determine the instructions to be executed by the selected fuel dispenser (operation 1360). The determined instruction may include one or more commands that prompt the selected fuel dispenser to perform the determined operation when the instruction is received. The instructions may also include data for use in performing operations on the selected fuel dispenser. FD#1 then identifies the network address of the selected FD (operation 1365) and assembles a network message containing the identified network address and the determined instruction (operation 1370). FD#1 sends the assembled network message on the network (operation 1375). If the operation length determined for the selected fuel dispenser is long or includes multiple commands, more than one network message can be sent. In coordination with the operation performed by the selected fuel dispenser, FD#1 may continue to perform the operation (if any) at an appropriate time (operation 1330).

[0141] After sending the network message, FD#1 determines whether a network message has not been sent to any of the identified fuel dispensers (operation 1380). If there are still identified fuel dispensers, FD#1 selects another A fuel dispenser (operation 1385), and the process of forming and sending a fuel dispenser message (1355-1375) begins again. However, if there are no other fuel dispensers that have been identified, the process ends (operation 1320).

[0142] The exemplary process of FIG. 13 includes identifying fuel dispensers to perform coordinated operations. Fuel dispenser #1, as the fuel dispenser that generates the message, can use various techniques to identify the fuel dispenser. For example, the operation to be performed may be linked to a group of fuel dispensers that have been identified as fuel dispensers to perform coordinated operations. The link can be defined in a database, table or list. In some implementations, the identified group of fuel dispensers may be fixed, such as information downloaded at system configuration time. In other implementations, the group of fuel dispensers associated with the identified operation may be dynamically determined. For example, the identified group of fuel dispensers may be calculated based on the current status of the fuel dispensers. In some cases, some fuel dispensers may have sufficient unused bandwidth to efficiently handle additional computing tasks and/or message traffic that may need to perform operations within the required time frame. For example, currently idle fuel dispensers are generally more likely to be identified, assuming they are otherwise suitable for performing coordinated operations. However, idle fuel dispensers with unavailable cameras will not be eligible to be identified to perform image capture operations for possible unpaid departure events. Optimization algorithms using techniques such as minimum variance and/or regression processes can be developed for specific implementations to optimize the identification of fuel dispensers to perform coordinated operations.

[0143] Although one implementation for fuel dispenser management has been described, other implementations may perform operations in a different sequence or modified configuration to achieve the same main function, that is, to coordinate operations performed by two or more fuel dispensers .

CN 101356552 Β

[0144] In various implementations, the fuel dispenser may use appropriate communication methods, devices, and technologies to communicate. For example, the fuel dispenser 1022 (Figure 10) can communicate from the source fuel dispenser to the target fuel dispenser using point-to-point communication. In the point-to-point communication, messages are sent from a dedicated physical link (such as optical fiber link, point-to-point wiring, daisy chain). The source is transmitted directly to the receiver. Other implementations can transmit messages by broadcasting to all or almost all fuel dispensers coupled together by a communication network (for example, by using omnidirectional radio frequency (RF) signals), while other implementations can transmit messages characterized by high directivity, Such as RF signals transmitted using directional (eg narrow beam) antennas or infrared signals optionally using focusing optics. Use RS-232, RS-422, RS-485, 802.11a/b/g, Wi-Fi, Ethernet, IrDA, FDDI (Fiber Distributed Data Interface), Token Ring network as an example but not intended to be limiting , Or based on frequency division, time division or code division multiplexing technology and other appropriate interfaces and protocols are also possible. Some implementations may optionally incorporate features such as error checking and correction (ECC) for data integrity, or security measures such as encryption (eg, WEP) and password protection.

[0145] In some implementations, each fuel dispenser can be programmed with the same data and initialized with substantially the same data stored in non-volatile memory. In other implementations, one or more fuel dispensers in an installation can be custom configured to perform specific functions. For example, a fuel dispenser may be configured to perform a routing function by routing messages between fuel dispensers in an island or between fuel dispensers in different islands.

[0146] In order to establish communication, individual fuel dispensers can identify themselves on the network by sending a unique identifier. In other implementations, for example, routers, switches, or bridges can handle message traffic flow so that messages can be routed to specific destination fuel dispensers based on network addresses. The network message may for example be structured into groups of components, which include a network address that identifies the target fuel dispenser and/or a header that identifies the target device as a specific type of fuel dispenser.

[0147] In addition, some implementations may allow communication in a broadcast mode, where the fuel dispenser that generates the message may send messages to be received by all other fuel dispensers in the same retail fueling facility or coupled to the same communication link or network. Various network arbitration methods such as passing tokens can be used to handle or avoid conflicts when more than one fuel dispenser tries to send messages at the same time.

[0148] Configuring the fuel dispenser to have the ability to coordinate its operation may provide one or more beneficial features. For example, allowing coordination between fuel dispensers may allow operations to continue when communication between the fuel dispensers and the central controller is missing or interrupted. Therefore, refueling operations and other transactions on the fuel dispenser can continue during the interruption of the communication link with the central controller (for example, during maintenance periods, re-booting, or low bandwidth of the central controller). In addition, coordination between fuel dispensers can provide extended functions, such as coordinating between multiple fuel dispensers to operate the camera to capture images of unpaid customers (ie, unpaid driving away) from multiple vantage points. In addition, customer service can also be enhanced by providing redundant equipment when there is a problem with the equipment. For example, if a receipt cannot be printed on a fuel dispenser due to lack of paper, the receipt can be printed on a nearby available fuel dispenser. In addition, fuel dispenser coordination can provide improved diagnostic capabilities to detect and accurately identify fuel dispenser problems at an early stage. Therefore, fuel refueling coordination can promote profit growth and reduce losses by improving the availability of fuel dispenser functions (ie, uptime), expanding functional capabilities, promoting safety, and improving customer experience.

[0149] FIG. 14 shows an example of a process 1400 for managing a fuel dispenser. Process 1400 generally involves providing diagnostic services at the fuel dispenser. The process 1400 may be implemented by one or more of the aforementioned fuel dispensers, for example.

[0150] The process 1400 begins by determining whether a condition has been detected at the fuel dispenser (operation 1404). Determining whether a condition has been detected at the fuel dispenser can be achieved, for example, by determining whether one or more sensors have already read, or whether one or more processors have made a condition determination. Detectable conditions include environmental, mechanical, electrical, and/or logical command conditions, such as temperature, pressure, humidity, oil leakage, panel opening, refueling machine in, power abnormality, watchdog timer expired, or software abnormality. Condition judgments can be made on a time-driven or event-driven basis.

CN 101356552 Β

[0151] If a condition has not been detected, the process 1400 requires determining whether a revised diagnostic instruction is available (operation 1406). Determining whether a revised diagnostic instruction is available can be achieved, for example, by determining whether a message indicating that the revised diagnostic instruction is available has been received, or by generating a message asking whether the revised diagnostic instruction is available. These instructions can be obtained from a remote server, for example. If revised diagnostic instructions are available, process 1400 requires downloading the revised diagnostic instructions (operation 1408). The fuel dispenser can, for example, enter a client-server relationship to download these instructions. Once the revised instruction is downloaded, the process 1400 requires that it has been determined again whether a condition has been detected at the fuel dispenser (operation 1404).

[0152] However, if no revised instructions are available, the process 1400 requires determining whether a diagnosis request has been received (operation 1410). The diagnosis request may, for example, request information related to fuel dispenser components (eg, dispenser manager, fuel controller, etc.). , Or other appropriate fuel dispenser components) diagnostic command data or specify the diagnostic command for fuel dispenser components. The diagnostic command may, for example, specify a soft reset, revised operating instructions (such as software), or any other appropriate command that affects the operation of the pump assembly. The query command may include, for example, an identifier request, a status request, or any other appropriate request for information about fuel dispenser components. The diagnosis request may be received from a fueling facility computer (such as a facility controller) or any other appropriate device located far from the fuel dispenser.

[0153] If the diagnosis request has been received, the process 1400 requires that the diagnosis request be fulfilled (operation 1412). Fulfilling the diagnostic query request may, for example, include retrieving status data from the fuel dispenser component and providing the data to the requesting device. Fulfilling the diagnostic command request may, for example, include issuing a command to the fuel dispenser assembly. Once the diagnosis request is fulfilled, or if the diagnosis request is not received, the process 1400 again requires determining whether a condition has been detected at the fuel dispenser (operation 1404).

[0154] If a condition has been detected at the fuel dispenser, the process 1400 requires determining whether the condition warrants a response (operation 1416). Whether the condition guarantees a response may depend on whether the condition exists, the degree of the condition, and/or one or more other conditions. For example, the presence of certain conditions (such as panel opening, improper incorporation, or oil leakage) can guarantee a response. As another example, some conditions (such as temperature or jitter pulses) may have an acceptable range where the condition does not guarantee response (for example, 0-140°F or jitter pulses less than once a week, respectively). Whether the condition guarantees that the response can be expressed as one or more logical conditions in a set of logical instructions. If the condition does not guarantee a response, the process 1400 calls for determining whether another condition has been detected at the fuel dispenser (operation 1404). Data about the detected conditions can be discarded or saved for later analysis or reporting.

[0155] However, if the conditions do not guarantee a response, the process 140 requires determining whether the fuel dispenser should be restarted (operation 1420). For example, if a power abnormality has been detected, if a software abnormality occurs, if the dongle timer expires, if communication within the tanker fails, or if communication with the facility controller fails, the fuel dispenser may need to be restarted. An example of the last if includes determining that the reader is not receiving a polling message. Another example of the last if includes determining when a fuel dispenser is not in idle mode and it is captured (eg waiting for a pre-authorized response). If the fuel dispenser needs to be restarted, the process 1400 continues to restart the fuel dispenser (operation 1424), which may include resetting specific components (such as rebooting processor-based components or resetting communication lines to the facility controller), shutting down specific components Components, or shut down the entire fuel dispenser. Once the fuel dispenser has restarted (a process that can take between about a few seconds to a few minutes), the process 1400 requires a determination as to whether another condition has been detected at the fuel dispenser (operation 1404).

[0156] If the fuel dispenser does not need to be restarted, the process 1400 requires determining whether the fuel dispenser should be shut down (operation 1428). For example, if an oil leak, lack of electricity, fire, liquid (such as water) in the soil, improper steam recovery, or unauthorized access is detected, the fuel dispenser may need to be shut down. These conditions can be detected by any suitable sensor. Such as

CN 101356552 Β

If the fuel dispenser needs to be turned off, the process 1400 continues to turn off the fuel dispenser (operation 1432). Turning off the fuel dispenser may include placing mechanical components in a safe position, turning off processor-based components, and de-energizing electrical components. Once the fuel dispenser has been shut down, process 1400 ends.

[0157] However, if the fuel dispenser does not need to be shut down, the process 1400 requires determining whether the fuel dispenser should download instructions (operation 1436). For example, if repeated error conditions occur (such as one or more dongle timers continue to expire, one or more software exceptions continue to occur, customer card reading continues to fail, or the fuel dispenser has restarted itself within a given period of time A certain number of times (for example, restarting three times in a three-hour period), the fuel dispenser needs to download instructions. If it is detected that the fuel dispenser is not operating in an effective manner, the fuel dispenser also needs to download instructions. For example, a fuel dispenser can monitor the flow rate of fuel. If the flow rate deviates from the specified range (for example, 8-10 gallons/minute), the fuel dispenser can adjust each valve to adjust the flow rate. Adjusting these valves may require downloading appropriate instructions. Other operations of the fuel dispenser can be similarly adjusted.

[0158] If instructions need to be downloaded, the process 1400 continues to determine whether there are appropriate instructions to download (operation 1440). Determining whether there are appropriate instructions to download may, for example, include generating a query to a remote computer (eg, a server) or polling the remote computer. If there are appropriate instructions to download, the process 1400 requires downloading these instructions (operation 1444). These instructions can be in the form of a rule set, a part of a rule set, a software application, a patch, or any other appropriate logical instruction set. These instructions can be in the form of software or firmware updates. Once the instructions have been downloaded, or if there are no appropriate instructions to download, the process 1400 calls for determining whether another condition has been detected at the fuel dispenser (operation 1404). [0159] However, if the fuel dispenser does not need to download instructions, the process 1400 requires a determination as to whether notification is required (operation 1448). For example, if the facility controller, other fuel dispensers at the refueling facility, or other components at the refueling facility need to be notified of the relevant conditions, the notification may be required. For example, if a leak is detected in the main trunk (a type of fluid pipeline), all fuel dispensers at the refueling facility may need to be notified that they need to be shut down. As another example, if the parameter is outside tolerance (such as power level, flow rate, number of transactions per hour, or sales), then It may be necessary to notify remote and/or refueling facility equipment or personnel. If a notification is required, the process 1400 continues to generate a notification (operation 1452). The notification may be, for example, a message directed to one or more other components at the fueling facility. In addition, the message can be directed away from the computer at the fueling facility. For example, messages (such as email, SMS, or instant messages) can be sent to service providers and/or fuel dispenser manufacturers, where the messages can be analyzed by personnel or computers (such as PCs, servers, workstations, or PDAs) . The analysis may include condition analysis, diagnosis, and trend analysis. The message may or may not be sent through another fueling facility component. Once the notification has been generated, or if the notification is not required, the process 1400 calls for determining whether another condition has been detected at the fuel dispenser (operation 1404).

[0160] The diagnostic service illustrated by the process 1400 has several characteristics. For example, by being able to shut down only one fuel dispenser, the refueling facility may be able to continue operation when a problem limited to one fuel dispenser is detected. As another example, by being able to try to repair it yourself, a fuel dispenser may be able to resume operation without having to be serviced, which can increase its ability to refuel. As another example, by being able to process diagnostic queries and command requests, a fuel dispenser may be able to provide relevant diagnostic data about its operation and/or control for diagnostic purposes. This can provide insight into the state of the fuel dispenser that is failing and provide techniques to correct these problems.

[0161] The diagnostic service operation of the process 1400 may be implemented by any of various hardware and/or software combinations. For example, the operation may be performed by a management module associated with the tanker manager, as shown, for example, in FIG. 2. In this implementation, diagnostic operations can be expressed as instructions, and diagnostic data can be stored in a log, especially when the attempted correction does not repair a condition. This management module can provide diagnostics exclusively with or without other management modules that provide other services

CN 101356552 Β

Services, or provide other services (such as POS, fuel dispenser coordination, and/or data security).

[0162] In a specific implementation, the fueling facility may include a gateway (for example, a server) that provides various services based on the fuel dispenser diagnosis. For example, the gateway can provide local reporting, alarms, and routing. The alert may be sent, for example, to: 1) a service center used by a service provider for reporting, alerting, or routing; and 2) a fuel dispenser manufacturer for reporting or alerting. As part of its operation, the gateway can discard the data from the fuel dispenser because it is irrelevant, forward the data to other components for processing or storage, store the data in a local database for later reporting or analysis, and generate alarms For mobile devices to respond. The gateway can also be used as an application and configuration (such as plug and play) server for fuel dispensers. The gateway may or may not be part of the facility controller.

[0163] The diagnostic manager may include the ability to issue diagnostic operation commands and/or query commands to one or more fuel dispenser components. The diagnostic manager may be, for example, a software component that resides on a fuel dispenser and/or a remote fueling facility computer (such as a facility controller or gateway). To facilitate communication with the fuel dispenser, the diagnostic manager may send out XML messages via TCP/IP, for example. Fuel dispenser components (such as dispenser manager and management module) can also communicate using XML messages. Other appropriate messaging technologies, whether static, dynamic, or other methods, as well as local, regional, or global communication protocol schemes, can also be used. One or more of the components of the fuel dispenser may have to be modified to have the ability to accept diagnostic operation commands and/or query commands. For example, a component may have to be modified to respond to diagnostic queries (for example, for identifiers or status) and diagnostic commands (for example to implement a software reset or revised operating instructions). Modifications can include the ability to receive, recognize, and respond to diagnostic requests.

[0164] Although FIG. 14 shows an example of a process for fuel dispenser management in which the fuel dispenser provides diagnostic services, other processes for fuel dispenser management in which the fuel dispenser provides diagnostic services may include more Fewer, additional, and/or different operating configurations. For example, the review of revised operating instructions can be performed on a periodic basis (for example, once a day). As another example, when the condition guarantees that there is a response, the process can implement the response without determining whether the response should be implemented. As yet another example, more than one response may be implemented in response to a condition. For example, if a fuel dispenser detects an internal fuel leak, the fuel dispenser itself should shut down and notify other fuel dispensers that it is shutting down, or if the fuel dispenser detects a mainline leak, the fuel dispenser can be shut down And inform other fuel dispensers that they should also be shut down. By being able to notify other fueling facility components of local conditions, fuel dispensers may be able to increase the safety of the entire fueling facility. As another example, one or more of the responses (for example, restarting the fuel dispenser or shutting down the fuel dispenser) may not be implemented. As an additional example, the response may be based on a previous response. For example, if a given number of restarts have occurred in a period of time (for example, three times a day), the fuel dispenser may try to download instructions before restarting again when the condition indicating the restart is detected next time. Similarly, if the new instruction cannot Alleviate the excessive restart sequence, and the fuel dispenser can be restored to its previous configuration. In addition, if resetting the communication line does not solve the problem, you can then reset the communication board of the line. As an additional example, the process may require one or more operations to be executed concurrently (for example in an interleaved manner) or simultaneously (for example in a parallel manner).

[0165] In certain implementations, a fuel dispenser may be able to initiate a coordinated operation with another fuel dispenser as a response or part of a response. The ability of the fuel dispenser to coordinate operations is described above with reference to process 1300. For example, if the first fuel dispenser detects leakage (such as oil), it may request another fuel dispenser to take an image of the first fuel dispenser. The image can be stored by one of the fuel dispensers or sent to a remote device for storage. The first fuel dispenser may also request to record status data about other fuel dispensers. Therefore, if the service technician must participate, she can have more information about the condition of the fuel dispenser. Coordinated operations can also be used in conjunction with other responses. For example, a fuel dispenser that detects a leak may request imaging and/or status data from another fuel dispenser and then shut itself down.

CN 101356552 Β

[0166] FIG. 15 shows another implementation of a process 1500 for managing a fuel dispenser. Process 1500 generally involves providing data security at the fuel dispenser of the fueling facility. The process 1500 may be an example of a process performed at the fuel dispenser of the fueling facility system 100.

[0167] The process 1500 starts by waiting for the refueling session to be initiated at the fuel dispenser (operation 1504). Determining whether a refueling session has been initiated at the fuel dispenser can, for example, detect the presence of a customer identifier (such as the insertion of an electromagnetic payment card (such as a credit card) or the presence of a wireless payment authorizer (such as an RFID tag)), the user and the fuel dispenser The interaction of the input device (such as the keypad), the removal of the pump handle of the fuel dispenser, or any other appropriate indicator of the interaction between the customer and the fuel dispenser is achieved.

[0168] Once the fueling session has been initiated at the fuel dispenser, the process 1500 requires waiting for a portion of the transaction data of the fueling session to be received at the fuel dispenser (operation 1508). The transaction data part may include, for example, the customer's account number, identification code, authorization code (such as a PIN number), and/or purchase information. This data part can be obtained at the beginning, middle, or end of the refueling session.

[0169] Once a portion of the transaction data has been received, the process 1500 requires determining whether the data portion is to be stored at the fuel dispenser (operation 1512). If the data portion needs to be saved to a certain time or event before being sent to the remote device, or if the communication link is not available, the data portion may be stored, for example, at a fuel dispenser. In some implementations, the data portion may be stored at the fuel dispenser for a short period of time (for example, a few nanoseconds or a few seconds), and is not considered to be stored at the fuel dispenser.

[0170] If the data portion is to be stored at the fuel dispenser, the process 1500 requires determining whether the data portion requires security measures (operation 1516). If the type of the data part has been designated as sensitive information (such as a customer account number), the data part may require security measures, for example. If the data portion requires security measures, the process 1500 continues to encrypt the data portion (operation 1520). Encryption can be achieved by any suitable scheme (for example, public key or private key scheme). Once the data portion has been encrypted, or if the data portion does not require security measures, the process 1500 requires that the data portion be stored in the fuel dispenser (operation 1524). The data portion can be stored in the transaction log, for example, along with other transaction data In, or stored in a separate part of the memory.

[0171] Once the data portion has been stored, the process 1500 calls for determining whether the fueling session is complete (operation 1528). If the refueling session is completed, the process ends. For example, if the customer has stopped pumping fuel and completed their purchase, the refueling session can be completed. However, if the fueling session is not completed, the process 1500 requires a determination whether another portion of the transaction data has been received at the fuel dispenser (operation 1508). Part of the stored data can eventually be transported to a remote facility computer (such as a facility computer). The data part can be transported in encrypted or unencrypted format.

[0172] Referring again to operation 1512, if it is determined that the data part is not to be stored at the fuel dispenser, the process 1500 requires determining whether the data part is to be delivered to the fueling facility computer (operation 1532). If, for example, the data helps complete a refueling session transaction (such as payment card data) or helps monitor the status of a fuel dispenser, the data may need to be delivered to a refueling facility computer. The transportation to the fueling facility computer may be, for example, a pilot operation to the computer that is far from the fueling facility. The fueling facility computer may be, for example, a personal computer, a workstation, a server, or a router. If the data portion is not to be shipped to the fueling facility computer, the process 1500 requires determining whether the fueling session has been completed (operation 1528).

[0173] However, if the data portion is to be shipped to a fueling facility computer, the process 1500 requires determining whether the data portion requires security measures (operation 1536). If the type of the data part has been designated as sensitive information (such as a customer account number), the data part may require security measures, for example. If the data portion requires security measures, the process 1500 requires that the data portion be prepared for transportation on the wired link (operation 1540). Prepare the data part for transport on the wired link

CN 101356552 Β

This may include, for example, specifying the data portion to be communicated via the wired link, scheduling the data portion to be communicated via the wired link, formatting the data portion in the communication protocol of the wired link (for example, by encapsulation or encoding), and/or via the wired link The data part of the way is sent. But if the data portion does not require security measures, the process 1500 requires that the data portion be prepared for transport on the wireless link (operation 1544). Preparing the data portion for transportation on a wireless link may be similar to preparing the data portion for transportation on a wired link. After preparing the data portion for shipping, the process 1500 requires determining whether the refueling session has been completed (operation 1528).

[0174] Although FIG. 15 shows an implementation of a process for managing fuel dispensers to provide fueling facility data security, other processes for managing fuel dispensers to provide fueling facility data security may include fewer, additional, And/or different operating configurations. For example, the process may not include determining whether the portion of the data to be stored on the fuel dispenser requires security measures. As another example, the process may include transferring portions of the data stored on the fuel dispenser to the fueling facility computer. In addition, before transmitting the stored data portion, a determination can be made as to whether the data portion requires security measures and implement the security measures when needed. As yet another example, the process may include encrypting the data portion before transmitting the data portion via a wired link or a wireless link. Encryption may be, for example, an additional or alternative security measure when sending data via a wired or wireless link. The destination of the encrypted data can be a remote facility computer or a computer outside the remote facility (for example, a remote merchant computer or an automatic settlement center). As an additional example, the process may not require determining whether the portion of the data to be delivered to the fueling facility computer requires security measures. As another example, the process may require determining whether the data portion is to be delivered to the fueling facility computer before determining whether the data portion is to be stored on the fuel dispenser. As yet another example, the process may require prior to determining whether the data portion is to be delivered to the fueling facility computer or before determining whether the data portion is Whether to store it on the fuel dispenser, determine whether the data part requires safety measures. As an additional example, a process may require one or more operations to be executed concurrently (for example in an interleaved manner) or simultaneously (for example in a parallel manner).

[0175] The data security operation of the process 1500 may be completed by any combination of various hardware and/or software. For example, the operation may be performed by a management module associated with the tanker manager, as shown, for example, in FIG. 2. In these implementations, operations can be expressed as instructions, and transaction data can be stored in a log. This management module can provide data security exclusively with or without other management modules that provide other services, or also provide other services (such as POS, fuel dispenser coordination, and/or fuel dispenser diagnosis).

[0176] FIG. 16 shows an implementation of a system 1600 for fuel dispenser business. Generally speaking, the system 1600 enables the fuel dispensers at the retail fueling facility 1600 to promote and sell the goods and/or services of the remote merchant 1620.

[0177] The retail fueling facility 1610 includes a fuel dispenser 1612, a communication network 1614, and a network interface 1616. The fuel dispenser 1612 may, for example, be similar to the fuel dispenser 200 in FIG. 2. The communication network 1614 is coupled with the fuel dispenser 1612 and enables the fuel dispenser to communicate with the network interface 1616, and the network interface 1616 is also coupled with the communication network 1614. The network interface 1616 may be any suitable device for allowing communication between various devices at the retail fueling facility 1610 and a remote device such as a computer at a remote merchant 1620. For example, the network interface 1616 may be a gateway, a wide area network router, or a facility controller.

[0178] In order to allow communication between the fuel dispenser 1612 and the remote merchant 1620, the system 1600 further includes a communication network 1630. The communication network 1630 may be any suitable system for allowing the exchange of information, such as the Internet, WAN, or PST.

[0179] The remote merchant 1620 may be any suitable seller of goods and/or services. For example, merchants may sell durable goods (for example, car parts or toys), perishable goods (for example, food), intangible goods (for example, software or digital media), or services (for example, oil changes). The remote merchant 1620 may include any suitable computer system (such as servers and data

CN 101356552 Β

Library) to allow them to send data about their goods and/or services to the fuel dispenser 1612 via the communication network 1630. The remote merchant 1620 may proactively, interactively and/or passively operate with the fuel dispenser 1612 to promote and/or sell its goods and/or services. For example, the remote merchant can download the sales content (advertising and pricing data) to the fuel dispenser at a specified time or event, or the remote merchant can download the sales content to the fuel dispenser based on a request. In a specific implementation, a remote merchant can maintain a web portal through which content can be downloaded from its fuel dispenser. It should be noted that remote merchants 1620 are remote in the sense that they are not located at the retail fueling facility 1610. Thus, remote merchants may be located in the neighborhood of retail fueling facilities. Of course, one or more merchants may be located far away from retail fueling facilities (for example, across states or countries).

[0180] In one mode of operation, the remote merchant 1620 downloads data about its goods and/or services to the fuel dispenser 1612 before the data is needed on the fuel dispenser. This data can be downloaded at a specific time (for example, at night), when a specific event occurs (for example, when new data is available), or based on a request from a fuel dispenser (for example, if the data is corrupted). The downloaded data may include a list of goods and/or services, as well as description and pricing information. The downloaded data may also include text, graphics, audio, and/or video for presentation on the fuel dispenser. The data can be in any suitable format. Open standard formats (such as ASCII for text, JPEG for bitmaps, GIF or Macromedia for animation, or MPEG or AVI for video) can be particularly useful. The downloaded data can be stored as content on the fuel dispenser.

[0181] The fuel dispenser 1612 may then determine when to present the merchant data. For example, a fuel dispenser may present data at specific points in a refueling session (for example, while refueling or after refueling is complete). The fuel dispenser can then determine whether the customer has expressed interest in the merchant data (for example, by detecting the user's input on it). If the fuel dispenser detects that the user is interested in the merchant data, the fuel dispenser may present additional information about the goods and/or services, and determine whether the customer wants to order the goods and/or services. The additional information about the goods and/or services may include text descriptions, images, first videos, and/or videos.

[0182] If the customer wants to order goods and/or services, the fuel dispenser may obtain order data (for example, quantity, price, and delivery information). Fuel dispensers can also obtain payment data. For example, a fuel dispenser may request the customer to show a customer identifier (such as a payment card) and enter a PIN. The fuel dispenser can then determine whether the payment data is acceptable. For example, a fuel dispenser can use business rules to determine whether the customer identifier is valid (for example, by performing a checksum) and determine whether the order amount is within a predetermined limit (for example, under $50), which can be based on the customer profile. The fuel dispenser can also estimate whether the payment data is sufficiently complete. If the payment data is acceptable, the fuel dispenser can then generate messages about ordering and payment information for the appropriate one of the remote merchants 1620, and generate a receipt for the customer. The appropriate merchant can then arrange for the delivery of the goods and/or services.

[0183] In another mode of operation, one or more of the remote merchants 1620 may provide a portal (eg, a web portal) that interacts with the fuel dispenser. The portal may be responsible for providing data to fuel dispensers for presentation, obtaining order data and/or obtaining payment data. This data can be downloaded before and/or when needed. Of course, fuel dispensers also involve presenting merchant data, obtaining order data, and obtaining payment data. For example, a fuel dispenser essentially presents advertising data, order data, and payment data. Fuel dispensers also detect order data (such as the user's choice of products and/or services) and payment data (such as the user's choice of payment type). These choices can be shipped to the portal for processing and/or processed locally. Fuel dispensers and remote merchant portals can communicate via TCP/IP network using standard Web portal calls.

[0184] An example of a service that can be ordered from a fuel dispenser is pizza. A fuel dispenser customer can, for example, order pizza when refueling a car. The customer may then pick up the pizza on the way to his destination (for example, home), or have the pizza delivered to his destination (for example, his place of work). Other examples include listing merchants (e.g., Land, s End

CN 101356552 Β

Or Eddie Bauer), Internet retailers (such as Amazon, com) or traditional retailers (such as Wal-Mart^Target or Barnes&Noble) to order goods. In fact, any company with online functions can use this system.

[0185] To facilitate customer interaction in a specific implementation, the fuel dispenser may be able to retrieve customer-related data. This customer-related data may be associated with a customer identifier (such as a credit card number, personal identification number (PIN), phone number, radio frequency identifier (RFID) number, or club number), for example. The customer identifier can be used for complete retrieval of customer-related data. Customer-related data can be information about fueling sessions (such as fuel type, display language of fuel dispenser displays, audio settings of fuel dispensers, or payment preferences (such as Exxon or Visa)), data about services at fueling facilities ( Data such as washing a car, pumping up gas or adding water), data about the customer (for example, address and preferred payment type). In certain implementations, customer-related data can also be used to identify other information that may be of interest to customers. For example, specific types of merchandise (for example, drinks, newspapers, or food) or offers (for example, discount coupons or advertisements) may be presented to customers. The presentation may be based, for example, on the customer's buying habits in a gas facility store. Customer-related data can be obtained based on the customer's interaction with the fuel dispenser or other components on the fueling facility, or based on customer-specified standards entered at the fuel dispenser, local fueling facility computer, or remote computer (for example, through a Web interface). Customer-related data may be stored locally at the fueling facility (for example, at the facility controller) and/or remotely (for example, at a remote server). In a specific implementation, the hash function Numbers (such as MD5, or Secure Hash Algorithm (SHA)) can be applied to the customer identifier before attempting to retrieve customer-related data. This can help keep the customer's identifier secret.

[0186] Regarding commerce at a fuel dispenser for remote merchants, the ability to retrieve customer-related data can provide many features. For example, a fuel dispenser can use retrieved customer data (such as purchasing preferences or history) to determine what type of merchant data to present to the customer. If the customer has expressed interest in a specific type of product (for example, through a pre-specified preference or purchase history), the fuel dispenser can, for example, provide content about a specific merchant. Fuel dispensers may also be able to expedite transactions by being able to present payment options to customers. For example, customer-related data may contain information about payment methods commonly used by customers (for example, credit cards, debit cards, etc.). If this information is available, the fuel dispenser may be able to present the user with one or more options (such as a gas card, credit card, or debit card) to pay for goods and/or services. The user can then select the appropriate data by using a touch screen, stylus, keypad, or other appropriate device. The user will therefore not have to swipe (or even have) the preferred customer identifier. Of course, fuel dispensers can collect identifiers (such as PINs or passwords) when security measures are required. As another example, a fuel dispenser may be able to facilitate the delivery of products and/or services purchased from a remote merchant. The fuel dispenser may, for example, be able to present one or more addresses (such as home or office) associated with the user, and/or ask the customer if he wants goods and/or services to be delivered to a specific address. Select the address The selection can be made, for example, by presenting a fuel dispenser to the user with text or graphic symbols representing the address. The user can then select the appropriate data by using a touch screen, stylus, keypad, or other appropriate device.

[0187] In certain implementations, remote merchant data can be linked to a digital sales framework. The framework allows retailers to control what is displayed on the fuel dispenser. The retailer may, for example, choose between content from one or more remote merchants and local content that may be the retailer's creation. The framework actually enables retailers to create content for fuel dispensers. For example, the framework may provide a website that retailers can log in to create content. Local content may, for example, provide the retailer's products and/or services (eg coffee, oil, car wash, etc.). The remote merchant data and the data created by the retailer can be stored on the gateway (eg, PC) at the fueling facility. The retailer can then choose what to display by the fuel dispenser. The selection can be fine-tuned according to the time and temperature of the day. The selected content can be downloaded from the gateway to the fuel dispenser for presentation at an appropriate time.

[0188] The system 1600 has various features. For example, customers can use their non-working hours to order goods when refueling the car

CN 101356552 Β

And/or services. This is quite convenient for busy customers. In addition, ordering goods and/or services and paying for them can even be done when part of some fueling facility components are temporarily unavailable. As another example, a retail fueling facility is provided with another profit stream, such as through advertising and sales revenue dividends from remote merchants. In addition, providing these capabilities to fuel dispensers allows additional capabilities (part of which have been discussed earlier) to be realized.

[0189] Although system 1600 shows one implementation of a system for fuel dispenser business, other systems for fuel dispenser business may have fewer, additional, and/or different component configurations. For example, a fuel dispenser may not communicate with a remote merchant through the communication facility of a retail fueling facility. The fuel dispenser may, for example, have a coupling with a distributed communication network (such as the Internet), or may be able to communicate data wirelessly (by using GPRS or IEEE 802.11) to a wireless network (such as a cellular telephone network) or a wired network (Such as the Internet) communication network. Note that a wireless network or a wired network can use a combination of wired and wireless technologies to carry data internally. In these situations, the retail fueling facility 1610 may or may not have a network interface. As another example, a retail fueling facility may include additional components, such as a store interface unit or facility controller. As yet another example, remote merchants may be located in various geographic locations (eg, in the vicinity of a retail fueling facility, and/or across the country from a retail fueling facility).

[0190] Various implementations for fuel dispenser business can operate in one or more modes. For example, a fuel dispenser may download data about one or more goods or services from a remote merchant. This helps alleviate storage limitations at the fuel dispenser. As another example, determining the validity of payment data may include requesting assistance from an external source, such as a remote merchant or an automated settlement center.

[0191] FIG. 17 shows an example of a merchant 1700 for fuel dispenser business. The merchant 1700 may be an example of a remote merchant 1620 of the system 1600. The merchant 1700 includes a computer system 1710. The computer system 1710 may be, for example, a personal computer or a server, and has the ability to provide data about merchants to fuel dispensers such as the fuel dispenser 1610 of the system 1600. The merchant 1700 may also include various other computer systems and/or components.

[0192] The computer system 1710 includes a processor 1720, a network interface 1730, and a memory 1740. The processor 1720 operates the corresponding instructions 1750, including an operating system 1752 (for example, Windows>Unix, or Linux) and application programs 1754 (for example, word processing, spreadsheet, inventory control, accounting, and sales). According to the application program 1754, the processor 1720 Process data 1760, including sales data 1762, inventory data 1764, and sales data 1766. The promotional data 1762 may include, for example, information describing (in written text or image format) the merchant's goods and/or services. Inventory data 1764 may, for example, include information about the current supply of goods and/or services of the merchant. The sales data 1766 may, for example, include information about the purchase of goods and/or services of the merchant. The processor 1720 may work in conjunction with the network interface 1730 to communicate data to a remote system (such as a fuel dispenser). The network interface 1730 may be, for example, a modem, a network interface card, or a wireless transceiver.

[0193] In one mode of operation, the processor 1720 may determine that the remote fuel dispenser should have data about the merchant's goods and/or services. This determination may be, for example, in response to a request from a remote fuel dispenser, or due to an update in the data. The processor 1720 may then retrieve the data (e.g., from sales data 1762) and generate an appropriate message for the fuel dispenser. The message can be sent through the network interface 1730.

[0194] The computer system 1710 may then wait to receive sales data from the fuel dispenser. The sales data may indicate the quantity of goods and/or services ordered, and the payment method. Using this information, the processor 1720 can update the inventory data 1764 and the sales data 1766. The computer system 1710 may also be responsible for submitting the payment to be collected (for example, to its bank or automatic settlement center).

[0195] Other operating modes may have fewer, additional, and/or different operating configurations. For example, in a fuel dispenser

CN 101356552 Β

When requesting information about goods and/or services, such as when a customer of a fuel dispenser expresses an interest in the goods and/or services, the remote fuel dispenser may communicate with the computer system 1710 for data about the goods and/or services. As another example, a remote fuel dispenser may communicate with the computer system 1710 when a customer of the fuel dispenser expresses a desire to purchase goods and/or services. The computer system can then determine the availability of data for goods and/or services and/or deliver that data and provide it to the fuel dispenser. As yet another example, a fuel dispenser may communicate with the computer system 1710 to assist in determining whether the payment data is acceptable. The computer system can, for example, determine whether the purchase is authorized (for example, by verifying a credit card issued by a merchant).

[0196] FIG. 18 shows an implementation of a process 1800 for fuel dispenser management. Process 1800 generally involves fuel dispenser operations for the fuel dispenser business. The process 1800 may be an example of a process implemented by the fuel dispenser 1612 of the system 1600.

[0197] The process 1800 begins by determining whether the merchant data should be presented at the fuel dispenser (operation 1804). The merchant data may be presented, for example, in response to a predetermined event during a refueling session (eg, refueling). If the merchant data should be presented, the process 1800 requires the generation of a user interface that includes the merchant data (operation 1808). Generating a user interface may, for example, include forming a user interface and presenting (eg, displaying) the user interface.

[0198] The process 1800 continues to determine whether user input regarding merchant data has been received (operation 1812). Determining whether user input related to merchant data has been received may, for example, include detecting activation of a user input device (such as a keypad or touch pad) related to the user interface. If no user input related to the merchant data is received, the process 1800 requires a determination as to whether to continue to present the user interface (operation 1816). If the refueling session has reached a certain stage (such as the end of refueling), the user interface may be removed, for example. If the user interface can continue to be presented, the process 1800 requires continuing to wait for user input regarding the merchant data (operation 1812). However, if the user interface may not continue to be presented, the process 1800 again requires determining whether the merchant data should be presented on the fuel dispenser (operation 1804).

[0199] If user input regarding merchant data has been received, which user input may indicate the customers interest in the merchants goods and/or services, the process 1800 continues to generate a user interface to obtain order data (operation 1820). The user interface This may for example include data on products and/or services, order quantities, and prices. The process 1800 also requires waiting to receive user input regarding the order data (operation 1824).

[0200] Once the user input regarding the order data is received, the process 1800 requires a determination as to whether the order is complete (operation 1828). If the order is incomplete, the process 1800 requires to continue to wait for order data (operation 1824).

[0201] Once the order is complete, the process 1800 requires the generation of a user interface to obtain payment data (operation 1832). The payment data interface may, for example, request the customer to present a customer identifier (such as a payment card) and/or enter specific information (such as a name, account number, and/or PIN). Process 1800 requires waiting for user input related to payment data to be detected (operation 1836) . [0202] Once the user input regarding the payment data is received, the process 1800 requires a determination of whether the payment data is complete (operation 1840). If the payment data is incomplete, the process 1800 requires to continue to wait for user input related to the payment data (operation 1836) ο

[0203] Once the payment data is complete, the process 1800 requires a determination whether the payment data is acceptable (operation 1844). Determining whether the payment data is acceptable may, for example, include determining whether the customer identifier is valid, whether the goods and/or services are acceptable to the customer, and/or whether the total price is acceptable. This determination can be made based on data stored on the fuel dispenser, or based on data retrieved from another component (such as a remote merchant or an automated settlement center). If the payment data is not acceptable, the process 1800 again requires the generation of a user interface in order to obtain the payment data (operation 1832). The user interface may, for example, contain previously entered payment data other than the payment data (such as a PIN) determined to be erroneous. Fields with error data can

CN 101356552 Β

Or it may not be specified. However, if the payment data is acceptable, a message about the order data (eg, product identifier, amount, and delivery instructions) is generated for the remote merchant (operation 1848). The remote merchant can use the data in the message to deliver the requested goods and/or services. The process 1800 continues to determine again whether the merchant data should be presented (operation 1804).

[0204] Although FIG. 18 shows a process for implementing a fuel dispenser business, other processes for a fuel dispenser business may include fewer, additional, and/or different operating configurations. For example, the process may require the continuous generation of multiple user interfaces for presenting merchant data (for example, one user interface for each merchant). As another example, the process may require the generation of data that includes relevant indications of goods and/or services of interest. This can be done before, during, or after obtaining the order data. As yet another example, the process may not include obtaining order data. This can happen, for example, if a pre-specified amount of cargo and delivery options exist. As an additional example, the process may enable customers to purchase goods and/or services from more than one merchant before deciding whether to present the merchant data again. As yet another example, the process may include generating a message about payment data and sending the message to a remote merchant. In some implementations, the payment data can be sent in the same message as the order data. However, the order data may be sent before the payment data. For example, the message can be sent even before the payment data is obtained.

[0205] A number of implementations have been described, and various other implementations have been proposed or proposed. In addition, for those skilled in the art, it will be easy to propose many additions, deletions, replacements and/or modifications, while still achieving fuel dispenser management. For at least these reasons, the protected subject matter is measured by the appended claims, which may cover one or more of the concepts in one or more of these implementations.

CN 101356552 Β