Method and apparatus for fuel payment processing

Abstract

The present disclosure provides "Methods and apparatus for fuel payment processing". A system includes a processor configured to receive, from a first digital entity, a vehicle identifier identifying a vehicle. The processor is further configured to, in response to receiving the identifier, digitally obtain a payment account associated with the identifier. The processor is further configured to verify, by input from a second entity, payment entitlement, confirming the entitlement to use the account to pay for charging the vehicle; and in response to successful verification, charge the payment account for vehicle charging after vehicle charging is complete.

Description

TECHNICAL FIELD

[0001] Illustrative embodiments relate generally to methods and apparatus for fuel payment processing. BACKGROUND

[0002] Public charging stations for plug-in electric vehicles can vary significantly in their operation, user interface, and payment methods. Charging stations can have different manufacturers and can be operated by different charging providers, each having unique procedures for plugging in the charging cord, establishing payment, initiating charging, and notifying the user of charging progress.

[0003] To initiate charging at a payment public charging station, some form of identification and payment is typically required. Often, payment and initiation is accomplished in one of four ways: tapping an RFID card linked to a credit card; activating the charge through a phone application (after selecting the appropriate charger on the application); directly inserting a credit card; or dialing a phone number listed on the charger. These methods vary from charger to charger and require the user to carry several different RFID cards and / or applications on their phone. All of this variability creates complexity and confusion for customers who are accustomed to the highly standardized and convenient refueling process that exists at gasoline / diesel stations. SUMMARY

[0004] In a first illustrative embodiment, a system includes a processor configured to receive, from a first digital entity, a vehicle identifier that identifies a vehicle. The processor is further configured to, in response to receiving the identifier, digitally obtain a payment account associated with the identifier. The processor is further configured to verify, through input from a second entity, payment entitlement, confirm the entitlement to use the account to pay for charging the vehicle; and in response to successful verification, charge the payment account for a vehicle charging fee after the vehicle charging is completed.

[0005] In a second illustrative embodiment, a computer-implemented method includes, in response to connecting a charging cable to a vehicle, receiving a vehicle identifier through a connection established by way of the charging cable. The method further includes requesting payment information from a cloud account, the information being associated with the vehicle identifier transmitted to the cloud account. The method further includes initiating charging of the vehicle in response to receiving the payment information, and using the payment information to pay for the charging fee after the charging is completed.

[0006] In a third illustrative embodiment, a computer-implemented method includes wirelessly receiving a vehicle identifier at a vehicle charger from a vehicle key fob. The method also includes digitally requesting payment information associated with the vehicle identifier, the request including the vehicle identifier. The method also includes verifying permission to use the payment information by querying an entity other than the vehicle key fob, where the entity verifies payment by responding with a predefined verification. Also, the method includes initiating charging of the vehicle in response to verifying the payment information, and paying for the charge using the payment information after the charge is complete. BRIEF DESCRIPTION OF DRAWINGS

[0007] Figure 1 An illustrative vehicle computing system is shown;

[0008] Figure 2 An illustrative process for payment detection and processing is shown;

[0009] Figure 3A And Figure 3B An illustrative process for VIN detection is shown;

[0010] Figure 4 An illustrative process for payment processing is shown; and

[0011] Figures 5A to 5C An illustrative process for charge initiation is shown. DETAILED DESCRIPTION

[0012] Detailed embodiments are disclosed herein; however, it is understood that the disclosed embodiments are merely illustrative and can be incorporated in various forms and alternative forms. The drawings are not necessarily to scale; some features can be exaggerated or minimized for the purpose of clarity. Therefore, the particular structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ the claimed subject matter.

[0013] Figure 1 An exemplary block topology of a vehicle-based computing system 1 (VCS) for a vehicle 31 is shown. An example of such a vehicle-based computing system 1 is the SYNC system manufactured by THE FORD MOTOR COMPANY. A vehicle enabled with a vehicle-based computing system can include a visual front end interface 4 located in the vehicle. If the interface is provided with, for example, a touch screen display, a user is also able to interact with the interface. In another illustrative embodiment, interaction is through button presses, a spoken dialogue system with automatic speech recognition, and speech synthesis.

[0014] In Figure 1In the illustrated embodiment 1, a processor 3 controls at least some portion of the operation of the vehicle-based computing system. The processor allows on-board processing of commands and routines to be provided within the vehicle. In addition, the processor is connected to non-persistent memory 5 and persistent memory 7. In this illustrative embodiment, the non-persistent memory is random access memory (RAM) and the persistent memory is a hard disk drive (HDD) or flash memory. In general, persistent (non-transitory) memory can include all forms of memory that maintain data when a computer or other device is powered off. These include, but are not limited to, HDDs, CDs, DVDs, magnetic tapes, solid state drives, portable USB drives, and any other suitable form of persistent memory.

[0015] The processor is also provided with a number of different inputs that allow a user to interact with the processor. In this illustrative embodiment, a microphone 29, auxiliary input 25 (for input 33), a USB input 23, a GPS input 24, a screen 4 (which can be a touch screen display), and a BLUETOOTH input 15 are provided. An input selector 51 is also provided to allow the user to switch between the various inputs. The inputs of the microphone and auxiliary connector are converted from analog to digital by a converter 27 before being passed to the processor. Although not shown, a number of vehicle components and auxiliary components that communicate with the VCS can use a vehicle network, such as but not limited to a CAN bus, to pass data back and forth to the VCS (or components thereof).

[0016] Outputs of the system can include, but are not limited to, the visual display 4 and the speaker 13 or stereo system output. The speaker is connected to an amplifier 11 and receives signals from the processor 3 through a digital to analog converter 9 to the amplifier 11. Outputs can also be transmitted to a remote BLUETOOTH device such as a PND 54 or a USB device such as a vehicle navigation device 60 along the bidirectional data streams shown at 19 and 21, respectively.

[0017] In one illustrative embodiment, the system 1 uses a BLUETOOTH transceiver 15 to communicate 17 with a user's nomadic device 53 (e.g., a cell phone, smart phone, PDA, or any other device having a wireless, long-range network connection). The nomadic device (hereinafter ND) 53 can then be used to communicate 59 with a network 61 outside of the vehicle 31 through, for example, a communication 55 with a cell tower 57. In some embodiments, the tower 57 can be a Wi-Fi access point.

[0018] Exemplary communication between the ND 53 and the BLUETOOTH transceiver 15 is represented by signal 14.

[0019] Pairing the ND 53 and the BLUETOOTH transceiver 15 can be commanded through a button 52 or similar input. Thus, the CPU is commanded to pair the on-board BLUETOOTH transceiver with the BLUETOOTH transceiver in the nomadic device.

[0020] Data can be communicated between CPU 3 and network 61 using, for example, a data plan, acoustic carrier data, or DTMF tones associated with ND 53. Alternatively, it can be desirable to include a vehicle-mounted modem 63 having an antenna 18 to communicate 16 data between CPU 3 and network 61 over the voice band. ND 53 can then be used to communicate 59 with network 61 external to vehicle 31 through a communication 55 with, for example, a cellular tower 57. In some embodiments, modem 63 can establish a communication 20 with tower 57 to communicate with network 61. As a non-limiting example, modem 63 can be a USB cellular modem and communication 20 can be a cellular communication.

[0021] In one illustrative embodiment, the processor is provided with an operating system that includes an API for communicating with modem application software. The modem application software can access an embedded module or firmware on the Bluetooth transceiver to accomplish wireless communication with a remote Bluetooth transceiver, such as the Bluetooth transceiver present in a roaming device. Bluetooth is a subset of the IEEE 802 PAN (Personal Area Network) protocol. The IEEE 802 LAN (Local Area Network) protocol includes Wi-Fi and has considerable overlap with the IEEE 802 PAN. Both are suitable for wireless communication within a vehicle. Another means of communication that can be used in this field is free space optical communication, such as IrDA, and non-standardized consumer IR protocols.

[0022] In another embodiment, ND 53 includes a modem for voice band or broadband data communication. In an acoustic carrier data embodiment, a technique known as frequency division multiplexing can be implemented when the owner of the roaming device is able to talk through the device while transmitting data. At other times, when the owner is not using the device, the data transfer can use the entire bandwidth (in one example, 300 Hz to 3.4 kHz). While frequency division multiplexing can be common for analog cellular communication between a vehicle and the Internet, and is still in use, it has largely been replaced by hybrid Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Space Division Multiple Access (SDMA) for digital cellular communication. If the user has a data plan associated with the mobile device, the data plan can allow broadband transmission, and it can be possible for the system to use a wider bandwidth (speed up data transfer). In yet another embodiment, ND 53 is replaced by a cellular communication device (not shown) mounted to vehicle 31. In yet another embodiment, ND 53 can be a wireless local area network (LAN) device capable of communicating over, for example, but not limited to, an 802.11g network (i.e., Wi-Fi) or a Wi-Max network.

[0023] In one embodiment, incoming data can be transmitted through the roaming device, through the vehicle's Bluetooth transceiver, and into the vehicle's internal processor 3 via acoustic data or data plans. For example, in the case of certain temporary data, the data can be stored on the HDD or other storage medium 7 until the data is no longer needed.

[0024] Additional sources that can interface with the vehicle include a personal navigation device 54 with, for example, a USB connection 56 and / or antenna 58, a vehicle navigation device 60 with a USB 62 or other connection, an on-board GPS device 24, or a remote navigation system (not shown) with a connection to a network 61. USB is one of a class of serial network protocols. IEEE 1394 (FireWire TM (Apple), i.LINK TM (Sony), and Lynx TM (Texas Instruments), EIA (Electronic Industries Association) serial protocols, IEEE 1284 (Centronics port), S / PDIF (Sony / Philips Digital Interconnect Format), and USB-IF (USB Developer Forum) form the backbone of serial standards between devices. Most protocols can be implemented for electrical or optical communication.

[0025] Additionally, the CPU can communicate with a variety of other auxiliary devices 65. These devices can be connected through a wireless 67 or wired 69 connection. Auxiliary devices 65 can include, but are not limited to, personal media players, wireless health devices, portable computers, and the like.

[0026] Additionally, or alternatively, the CPU can connect to a vehicle-based wireless router 73 using, for example, a Wi-Fi (IEEE 803.11) 71 transceiver. This can allow the CPU to connect to remote networks within range of the local router 73.

[0027] In addition to having the exemplary processes performed by a vehicle computing system located in the vehicle, in certain embodiments, the exemplary processes can also be performed by a computing system in communication with the vehicle computing system. Such systems can include, but are not limited to, a wireless device (such as, but not limited to, a mobile phone) or a remote computing system (such as, but not limited to, a server) connected through a wireless device. Such systems can be collectively referred to as a vehicle-associated computing system (VACS). In certain embodiments, particular components of the VACS can perform particular portions of the process depending on the particular implementation of the system. As an example and not a limitation, if a process has a step of sending or receiving information with a paired wireless device, it is likely that the wireless device is not performing that portion of the process as the wireless device does not "send and receive" information by itself. One of ordinary skill in the art will understand when it is inappropriate to apply a particular computing system to a given solution.

[0028] In each of the illustrative embodiments discussed herein, an example, non- limiting example of a process that can be performed by a computing system is shown. With respect to each process, for the limited purpose of performing the process, the computing system performing the process can be configured as a special purpose processor performing the process. All processes need not be performed, and are understood to be examples of the type of processes that can be performed to implement elements of the application. Additional steps can be added or removed from the illustrative processes as desired.

[0029] With respect to the illustrative embodiments described in the figures showing illustrative processes flows, it should be noted that for the purpose of performing some or all of the example methods shown in these figures, a general purpose processor can be temporarily enabled as a special purpose processor. When executing code providing instructions to perform some or all of the steps in the method, the processor can temporarily re-purpose itself as a special purpose processor until the method is complete. In another example, to the extent appropriate, firmware functioning the preconfigured processor can cause the processor to act as a special purpose processor provided for the purpose of performing the method or some reasonable variation thereof.

[0030] Due to user expectations and preferences for simplicity in user payment solutions, there is an opportunity to provide a standardized, simplified, user-friendly method for public charging.

[0035] Similar to the ease of keyless entry and button start bringing to the vehicle itself, illustrative embodiments provide ease of use of charging. Each proposed charging station can detect the vehicle VIN, link to the associated user payment information, authenticate, and then automatically start charging when the vehicle is plugged in. Detection of the VIN can be done via the vehicle can bus after plugging in the charging cord, by wirelessly interfacing with the vehicle key fob, or both (for additional security).

[0036] User payment information can be associated with the VIN, and can be stored in the cloud, or offline in the vehicle itself. For example, initiation of payment and start of charging can be done by a single button press on the charger, a button press on a smartphone app, a button press on the vehicle display, or can be completely automated based on prior authentication.

[0037] Such proposed charging processes can greatly minimize user interaction with the charging station, avoid swiping or scanning credit or RFID cards, and provide a standardized experience that can be implemented in any charger manufacturer or provider.

[0038]

[0039] An illustrative process for payment detection and processing is shown. In this example, the process is performed on a charger or a computer attached to a charger. All of the proposed solution can also be performed with respect to a traditional gas pump, assuming any detection and / or shut-off capabilities required for implementation are also provided as capabilities of the gas pump.

[0035] The process begins by detecting a VIN 201. The VIN can be stored on a key fob and detected by means of BLUETOOTH low energy, RFID, NFC, or other short-range communication. Short-range is preferred because it can help avoid confusion by detecting too many IDs. Of course, signal strength and other factors can be used with longer-range detection to narrow the selection, and / or a longer-range solution can be used if the customer must confirm a particular VIN or other vehicle identifier. Also, in many examples, the VIN will be verified by a second source, unlike the case where the VIN is received, so even if many VINs are initially detected, the correct VIN from the group should be identifiable using verification. In other modes, VIN detection is facilitated by communicating directly with the vehicle by means of a physical connection, which should remove any ambiguity in those cases.

[0036] Once the VIN has been detected, the process associates the VIN with a particular charger 203. If multiple VINs are detected by some detection process, a verification step can occur before association to ensure the correct VIN is associated with the correct charger. Once the VIN has been associated, the process can request payment information stored with respect to the VIN 205. The payment information can be stored on the cloud, or the payment information can be stored in a retrievable manner in the vehicle or key fob memory.

[0037] If the VIN needs to be verified (which can depend on the method by which the VIN was obtained) and if the VIN has not yet been verified 207, the process can request verification of the VIN 209. This can include, for example, comparing the VIN to a second proximate device (e.g., the key fob or the vehicle, whichever did not initially retrieve the VIN) and / or the user entering a ZIP code, PIN, or other code into the charger. Other suitable verification methods are also contemplated.

[0038] Once the VIN has been verified, the process (now with payment information and VIN verification) can begin charging 211. Once charging is complete 213, the process can submit a payment request to the identified payment account 215. The process can also send a receipt to the vehicle, to the mobile device, or to another source 217.

[0039] The above examples would work as follows: a user in a vehicle pulls the vehicle into a charging point, and engages the charging point in some manner (proximity, activation, etc.). Additionally or alternatively, the charging point can sense the proximity. The charging point can then receive a wireless communication, for example from a key fob or the vehicle that identifies the VIN. In another example, the VIN can not be identified until the charging cable is actually connected.

[0040] Once the VIN is obtained, the process can verify the VIN (if there is some ambiguity or otherwise needs to be verified) or use the VIN to request payment information. If the VIN is verified, the charger can request a user PIN or ZIP code. If the VIN is verified without direct user interaction, the process can scan a second source that can verify the VIN - for example, if the VIN is from a key fob, the charger can communicate with the vehicle to ensure that the vehicle with the same VIN is also present. Of course, if both the key fob VIN transmission and the vehicle scan are done wirelessly, this can result in nearby key fobs and vehicles being assigned to the wrong charger, so it can be useful to turn off the secondary verification function through a direct (wired) connection (e.g. plugged into the charger) or very close range and / or directional wireless signal.

[0041] The charger can also use the VIN (either before or after verification) to obtain payment information. In one example, the payment information can be cloud-based, and the charger can submit the VIN to the cloud to access a payment account. This can require some form of on-site identification, depending on how the VIN was obtained. In another example, the payment information can be stored on the vehicle or key fob, and the charger can transmit the detected VIN to a second entity (not the vehicle or key fob that provided the initial identification) along with a verification request and a payment information request. This allows the verification entity to also responsively provide the payment information, and has further security that both the key fob and the vehicle need to be present in order to process the payment.

[0042] In the above system, the type of process used to obtain the VIN can depend on the subsequent verification method. For example, if the user will enter a PIN or zip code, and / or if the VIN will be verified by a directional connection to the vehicle with the VIN, a longer range wireless signal detection can be used to initially obtain the VIN of any vehicles in the area around the charger. The charger can even receive a list of VINs, and since only one VIN will be verified by the connection or user code, the remaining VINs can then be discarded. If the VIN is verified by other methods that can have less assurance against false positives, the VIN obtaining can be done by shorter range signals to have fewer opportunities for confusion.

[0043] Figure 3A and Figure 3B An illustrative process for VIN detection is shown. InFigure 3A In the illustrated example, the charger obtains the VIN through a direct connection. When the charger detects 301 that the charging cable has been connected to the vehicle, the charger requests 303 the VIN from the vehicle network from the physical connection. Another option is to include a short-range transceiver on the charging cable, for example, that can read NFC or RFID signals, for example, from a transponder located in proximity to the charging point. In some reasonable manner, the process receives the VIN 305 in response to the cable being in proximity to or connected to the vehicle.

[0044] In Figure 3B The illustrated process detects the presence of a vehicle key fob 311 that stores the VIN in a retrievable manner. The process retrieves the VIN from the key fob 313 and, in this example, uses a direct connection to the vehicle to verify the VIN. If the charging cable is not connected 315, the process instructs the user to connect the cable 317. Once the cable is connected, the process can use the localized direct or wireless connection to verify the VIN 319. Although this appears similar to the process of 3A by detecting the VIN from the key fob before connection, the process can be able to retrieve preliminary payment information and other relevant data from the user account before the user even leaves the vehicle and engages the charger. This can speed up the customer experience because, as soon as the direct connection verifies the VIN, the process can begin charging immediately upon connection without having to go through the steps of obtaining and verifying any payment information that can be pre-obtained based on the VIN.

[0045] In a final verification process (not shown), the process can obtain the VIN from either the vehicle or the key fob and then use wireless communication with the other of the vehicle or the key fob to verify the obtained VIN. If the charger can distinguish the source of the VIN, the process can use directional signals, very short range signals, or signal strength (e.g., RSSI) to determine the second verification source in the appropriate location for verification purposes. That is, the secondary source can be detected as being in proximity or suitably close by various methods or can have to be located within a zone to be detected by directional signals.

[0046] Figure 4 An illustrative process for payment processing is shown. In this example, the process will use a variant of the secondary verification depending on the manner in which the VIN is initially obtained. At any given charger, the situation can be that only one of the aspects of this solution is implemented (or sometimes similar to one of the aspects), but the illustrative process shows a solution that can be executed to address VINs obtained in multiple ways from multiple sources.

[0047] In this process, the process determines whether the VIN came from the key fob 401. If the VIN did not come from the key fob, then the VIN came from the vehicle (in this example), and so the process uses the key fob for verification, and so the process scans for key fob wireless signals 403. If no key fob is found 405, then the process can ask the user to enter a PIN or zip code (or similar information) for verification 419. The process then connects to the cloud 421, and uses the PIN plus the VIN to obtain payment information 423. The cloud validates the PIN, zip, etc. 425, and if correct 427, then the process allows the payment to be processed 431. If the code is incorrect, then the payment request is denied 429.

[0048] If the process successfully detects the key fob, then the process also requests the VIN from the key fob 407 (for verifying that the VIN originally came from another source). If the key fob VIN matches the vehicle VIN 409, then the process determines whether the key fob also includes payment information stored thereon 411. If so, then the process obtains the payment information from the key fob with the VIN corresponding to the VIN previously received 413, and processes the payment 415. If the key fob does not have payment information, but is used to verify the VIN, then the process can append 417 or transmit a validation code retrieved from the key fob, or generated based on the key fob confirming the VIN, that can be used when the charger connects to the cloud to obtain payment information. Since the VIN is already verified by the presence of the key fob, this code essentially acts as a proxy for a user entered code.

[0049] If the VIN originally came from the key fob, then the process determines whether the charger has managed to verify the VIN (e.g., from user verification, a second source, etc.) 433. If the charger has not verified the VIN, then the process determines whether a local vehicle based payment retrieval is required 437. If so, then the process can request payment information from the vehicle 439, and send the unverified VIN 441. Since the vehicle is assumed to know its own VIN, the vehicle can now verify the VIN transmitted from the charger with the payment request 443. If the verification fails, then the charger denies the request 445. Otherwise, the charger obtains the payment 447 and can process the payment 449. In this case, the vehicle returns the payment information in response to the correct VIN transmitted with the request.

[0050] If the charger verifies the VIN (from the key card) using another method (such as a user-entered code or other verification), then the process determines whether a local payment solution 435 is required. If local payment is required, then the process (with the VIN verified by the user) can request payment information directly from the key card or vehicle (perhaps using a verification code, or in another example, if the VIN is pre-verified, then only payment is requested). If cloud-based payment (remote payment) is required, then the process can attach a verification code as before and send the payment request to the cloud for processing.

[0051] Figures 5A to 5C An illustrative process for initial charging is shown. Figure 5A In the example shown, the process obtains payment method 501 through one of the embodiments described herein. If payment is successfully verified 503 through one of the verification processes described herein, then the process presents an option to start charging 505. If the user selects option 507, then the process starts charging 509.

[0052] In this example, the process begins with manual user interaction. Alternatively, the charging station interacts with the vehicle, and the user can select a button to begin charging at the vehicle's interface. Interaction with the vehicle can be done wirelessly or via a physical connection established with a plug-in charging cable.

[0053] In the second example, such as Figure 5B As shown, the process is performed on a user's smartphone or vehicle. In this example, when charger 513 is connected, the process receives a wireless signal 511 from the charging station, which could be a smartphone process or an in-vehicle process. Alternatively, when charger 513 is connected, the process performed on the vehicle may receive a direct signal 511, or when charging cable 513 is connected, the process performed on the smartphone may receive a wireless signal 511 from the vehicle. The interface (the interface of the device on which the process is performed) may present selectable options 515 in response to receiving a signal indicating connection. When the user presses or selects option 517, the process may command charging to begin 519. This may involve sending a signal from the device performing the process to the vehicle, charger, or both.

[0054] exist Figure 5C In the example shown, the process is configured for automatic charging. In this initial mode, the process obtains payment information 501 (which can be any of the examples in the illustrative example, etc.). If the payment is verified 503, then the process determines whether automatic charging is selected 504. If automatic charging is enabled, which is a feature that can be enabled by the user when configuring charging options or at any other time, then the process can automatically determine that a charger is connected 506 and responsively begin charging 508.

[0055] By using the illustrative embodiments, a user can conveniently configure and store charging payment options in a manner that can be used with a variety of charging configurations. Then, depending on the mode implemented, the user can have obtained and verified payment information and easily initiate and pay for charging fees when approaching a variety of charging points without having to determine the specific solution enabled for a given charging point.

[0056] While the foregoing describes exemplary embodiments, these described embodiments are not meant to describe all possible forms of the application. Rather, the words used in this specification are words of description, not limitation, and it is understood that various changes can be made without departing from the spirit and scope of the application. Additionally, features of various implementing embodiments can be combined to produce a suitable variant of the embodiments described herein as appropriate, and such variants are intended to fall within the scope of the present application.

[0057] According to one embodiment, the payment account is obtained from a cloud-based server.

[0058] According to one embodiment, the verification includes querying the vehicle and wherein the verification is successful when the vehicle responds to the query by providing the vehicle identifier.

[0059] According to the present application, a computer-implemented method includes, in response to connecting a charging cable to a vehicle, receiving a vehicle identifier over a connection established by means of the charging cable; requesting payment information from a cloud account, the information being associated with the vehicle identifier transmitted to the cloud account; initiating charging of the vehicle in response to receiving the payment information; and after charging is complete, paying for the charging using the payment information.

[0060] According to the present application, a computer-implemented method includes, at a vehicle charger, wirelessly receiving a vehicle identifier from a vehicle key fob; digitally requesting payment information associated with the vehicle identifier, the request including the vehicle identifier; verifying permission to use the payment information by querying an entity other than the vehicle key fob, wherein the entity verifies the payment by responding with a predefined verification; initiating charging of the vehicle in response to verifying the payment information; and after charging is complete, paying for the charging using the payment information.

[0061] According to one embodiment, the verification includes querying a customer for a predefined verification code by the charging station.

Claims

1. A system for fuel payment processing, comprising: Processor, the processor being configured to: Detect vehicles and key cards capable of communication; In response to the detection that a charging cable is connected to the vehicle, a vehicle identification number for identifying the vehicle is requested from either the vehicle or the key card. Receive the vehicle identifier from a first connection that indicates one of the vehicle and the key card; In response to receiving the vehicle identifier, the payment account associated with the vehicle identifier is digitally obtained; Determine which of the vehicle identifier and the key card the vehicle identifier was obtained from; In response to determining that the vehicle identifier is obtained from one of the vehicle and the key card, it is connected to the other of the vehicle and the key card; Verifying payment rights via input from a second connection indicated to the other, confirming the right to pay for charging the vehicle using the account, the verification including at least verifying that another vehicle identifier received via the second connection matches the vehicle identifier received from the first connection; and Upon successful verification, the vehicle charging fee is charged to the payment account after the vehicle charging is completed.

2. The system as claimed in claim 1, wherein, The entity indicated by the first connection is a vehicle.

3. The system as described in claim 2, wherein, The vehicle identifier is received wirelessly from the vehicle.

4. The system as described in claim 3, wherein, The payment account is obtained from the vehicle's storage.

5. The system as described in claim 4, wherein, The verification also includes querying the vehicle key card, and wherein verification is successful when the key card responds to the query by providing the vehicle identifier.

6. The system of claim 3, wherein, The payment account is obtained from a cloud-based server.

7. The system of claim 6, wherein, The verification also includes querying a vehicle key card, and wherein the verification is successful when the key card responds to the query by providing the vehicle identifier.

8. The system as claimed in claim 2, wherein, The vehicle identifier is received via a connection established when the charger is plugged into the vehicle.

9. The system of claim 8, wherein, The payment account is obtained from the vehicle's storage.

10. The system of claim 9, wherein, The verification also includes querying a vehicle key card, and wherein the verification is successful when the key card responds to the query by providing the vehicle identifier.

11. The system of claim 8, wherein, The payment account is obtained from a cloud-based server.

12. The system of claim 11, wherein, The verification also includes querying a vehicle key card, and wherein the verification is successful when the key card responds to the query by providing the vehicle identifier.

13. The system of claim 1, wherein, The entity indicated by the first connection is a key card.

14. The system of claim 13, wherein, The payment account is obtained from the vehicle's storage.

15. The system of claim 14, wherein, The verification also includes querying the vehicle, and wherein the verification is successful when the vehicle responds to the query by providing the vehicle identifier.

16. A method for processing fuel payments, comprising: The vehicle identifier is wirelessly received from the vehicle key card or the vehicle at the vehicle charger used to provide charging to the vehicle at the vehicle charging station. Digitally request payment information associated with the vehicle identifier, the request including the vehicle identifier; Determine which of the vehicle identifier and the key card the vehicle identifier was obtained from; In response to determining that the vehicle identifier is obtained from one of the vehicle and the key card, it is connected to the other of the vehicle and the key card; Permission to use payment information is verified by querying the other party, wherein the vehicle verifies the payment by responding with a predefined verification, the predefined verification including confirming that another vehicle identifier received by the other party matches the vehicle identifier; In response to verified payment information, the vehicle charging begins; and After charging is complete, use the payment information to pay for the charging fee.

Images