PROCEDURES FOR IDENTIFICATION VERIFICATION AND PURCHASE VALIDATION

Abstract

Computer-implemented method, including: Receiving a validation request in a vehicle data processing system (VCS) from a paired wireless device; Receiving facility identification information from the wireless facility; Validating the identity of the wireless device; and Sending vehicle identification information and payment-related information to the wireless device in response to validation of the wireless device's identity.

Description

TECHNICAL AREA

[0001] The exemplary embodiments generally relate to a method for identification validation and purchase verification. STATE OF THE ART

[0002] Wireless technology, vehicle-based data processing systems, portable phones and computers, biometric IDs, RFID chips that store "cash"—modern technology, among other things, revolves around portability and convenience. The internet can be accessed almost anywhere in seconds at the touch of a button. Purchases can be made online, by swiping a card, and sometimes using a chip in a portable device. While all these innovations certainly make our lives easier, the degree of access to an individual's entire life that can be gained by stealing one or more of these convenient devices is sometimes a cause for concern. Fortunately, this risk is not unknown, and providers of technological convenience are constantly striving to provide enhanced security alongside modern systems.

[0003] Mobile phones can store increasingly complex personal and financial data. Applications allow access to bank accounts, credit card accounts, and some phones even have chips that can store cash amounts for purchases. Because most phones are used so frequently, they are unfortunately very susceptible to loss if a user misplaces or forgets a phone where it's used. Similarly, phones are popular targets for theft because they are small and portable and potentially provide extensive access to a person's personal information.

[0004] Methods and systems for secure authentication for accessing protected resources are known from the prior art, for example from US 2012 / 0144202A1 or US 2011 / 0053575A1. The integration of a vehicle into a payment system is also known from the prior art, in particular from US 2009 / 0024525A1. SUMMARY

[0005] To solve the aforementioned problem, the invention proposes a method according to claim 1, wherein preferred embodiments of the invention are the subject of the dependent claims. In a first exemplary embodiment, a computer-implemented method comprises receiving a request for payment-related information in a wireless device. The method further comprises communication between the wireless device and a paired vehicle data processing system (VCS) to verify the presence of a known vehicle. The method further comprises sending requested payment-related information in response to the verification of the presence of the known vehicle. In a second exemplary embodiment, a computer-implemented method comprises receiving a validation request in a vehicle data processing system (VCS) from a paired wireless device.The procedure also includes receiving device identification information from the wireless device. Furthermore, the procedure includes validating the identity of the wireless device. The procedure also includes sending vehicle identification information to the wireless device in response to the validation of the wireless device's identity.

[0006] In a third exemplary embodiment, a computer-readable storage medium stores instructions which, when executed by a processor, cause the processor to perform a procedure that includes receiving a request for payment-related information in a wireless device. The procedure also includes communication between the wireless device and a paired vehicle data processing system (VCS) to verify the presence of a known vehicle. Furthermore, the procedure includes sending the requested payment-related information in response to the verification of the known vehicle's presence. DETAILED DESCRIPTION OF THE DRAWINGS Fig. Figure 1 shows an example of a vehicle data processing system; Fig. Figure 2A shows an illustrative example of a verification frontend process; Fig. Figure 2B shows an illustrative example of a second verification process; Fig. Figure 3A shows an illustrative example of a different verification process; Fig. Figure 3B shows an illustrative example of a further verification process; Fig. Figure 4A shows an illustrative example of a verification configuration process; and Fig. Figure 4B shows an illustrative example of a second verification configuration process. DETAILED DESCRIPTION

[0007] As required, detailed embodiments of the present invention are disclosed herein; however, it is understood that the disclosed embodiments are merely exemplary of the invention, which can be realized in various and alternative forms. The figures are not necessarily to scale; certain features may be exaggerated or minimized to show details of specific components. The specific structural and functional details disclosed herein are therefore not to be considered a limitation, but merely a representative basis for teaching those skilled in the art how to use the present invention in various ways.

[0008] Fig. Figure 1 shows an exemplary block topology for a vehicle-based data processing system 1 (VCS) for a vehicle 31. An example of such a vehicle-based data processing system 1 is the SYNC system manufactured by THE FORD MOTOR COMPANY. A vehicle equipped with a vehicle-based data processing system may include an in-vehicle visual front-end interface 4. The user may also be able to interact with the interface if, for example, it is equipped with a touch-sensitive screen. In another exemplary embodiment, interaction is achieved through button presses, automatic speech recognition, and speech synthesis.

[0009] At the in Fig. In the exemplary embodiment shown in Figure 1, a processor 3 controls at least part of the operation of the vehicle-based data processing system. The processor is located in the vehicle and allows onboard processing of instructions and routines. Furthermore, the processor can be connected to non-persistent memory 5 and persistent memory 7. In this exemplary embodiment, the non-persistent memory is random access memory (RAM) and the persistent memory is a hard disk drive (HDD) or flash memory.

[0010] The processor is also equipped with a number of different inputs that allow the user to connect to the processor. In this exemplary embodiment, a microphone 29, an auxiliary input 25 (for input 33), a USB input 23, a GPS input 24, and a BLUETOOTH input 15 are provided. An input selector 51 is also provided to allow the user to switch between different inputs. Inputs to both the microphone and auxiliary inputs are converted from analog to digital by a converter 27 before being routed to the processor. Although not shown, numerous vehicle components and auxiliary components can use a vehicle network (such as, but not limited to, a CAN bus) to communicate with the VCS and transmit data to and from the VCS (or components thereof).

[0011] Outputs from the system can include, but are not limited to, a visual display 4 and a speaker 13 or stereo output. The speaker is connected to an amplifier 11 and receives its signal from the processor 3 via a digital-to-analog converter 9. Outputs can also be made to a remote BLUETOOTH device, such as the PND 54, or a USB device, such as the vehicle navigation device 60, along the bidirectional data streams shown at 19 and 21, respectively. Additionally, WiFi devices can be used, e.g., via a local Ethernet connection.

[0012] In one exemplary embodiment, the system 1 uses the BLUETOOTH transmitter / receiver 15 to communicate 17 with a user's nomadic device 53 (e.g., mobile phone, smartphone, PDA, or any other device with connectivity to a remote wireless network). The nomadic device can then be used, for example, to communicate 59 with a network 61 outside the vehicle 31 by communicating 55 with a cell tower 57. In certain embodiments, the tower 57 can be a WiFi access point.

[0013] Exemplary communication between the nomadic facility and the BLUETOOTH transmitter / receiver is represented by signal 14.

[0014] Pairing a nomadic setup 53 and the BLUETOOTH transmitter / receiver 15 can be commanded by pressing a key 52 or similar input. Accordingly, the CPU is informed that the onboard BLUETOOTH transmitter / receiver is to be paired with a BLUETOOTH transmitter / receiver in a nomadic setup.

[0015] Data can be transmitted between the CPU 3 and the network 61, for example, using a data plan, data-over-voice, or DTMF tones associated with the nomadic device 53. Alternatively, it may be desirable to provide an onboard modem 63 with an antenna 18 to transmit data between the CPU 3 and the network 61 over the voice band 16. The nomadic device 53 can then be used, for example, to communicate with a network 61 outside the vehicle 31 by means of communication 55 with a cellular mast 57 59. In certain embodiments, the modem 63 can establish communication 20 with the mast 57 for communication with the network 61. As a non-limiting example, the modem 63 can be a USB cellular modem, and the communication 20 can be cellular communication.In one exemplary embodiment, the processor is equipped 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 transmitter / receiver to establish wireless communication with a remote Bluetooth transmitter / receiver (such as one found in a nomadic setup). Bluetooth is a subset of the IEEE 802 PAN (Personal Area Network) protocols. The IEEE 802 LAN (Local Area Network) protocols include Wi-Fi and have considerable cross-functionality with IEEE 802 PAN. Both are suitable for wireless communication within a vehicle. Other communication methods that can be used in this area include free-space optical communication (such as IrDA) and non-standard consumer IR protocols.

[0016] In another embodiment, the nomadic device 53 includes a modem for voice-band or broadband data communication. In the data-over-voice embodiment, a technique known as frequency-division multiplexing can be implemented when the owner of the nomadic device can speak over the device while data is being transferred. 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).

[0017] Although frequency division multiplexing (FDM) may be common and still used for analog cellular communication between the vehicle and the internet, it has been largely replaced by hybrids of CDMA (Code Domain Multiple Access), TDMA (Time Domain Multiple Access), and SDMA (Space Domain Multiple Access) for digital cellular communication. These are all ITU IMT-2000 (3G) compliant standards and offer data rates of up to 2 Mbps for stationary or walking users and 385 kbps for users in a moving vehicle. 3G standards are now being superseded by IMT-Advanced (4G), which offers 100 Mbps for users in a vehicle and 1 Gbps for stationary users. If the user has a data plan associated with the mobile device, it is possible that the plan allows broadband transmission, and the system could utilize a much greater bandwidth (thereby accelerating data transfer).In another embodiment, the nomadic device 53 is replaced by a (not shown) cellular communication device installed in the vehicle 31. In yet another embodiment, the ND 53 can be a wireless local area network (LAN) device that can communicate, for example (and without limitation), via an 802.11g network (i.e., WiFi) or a WiMAX network.

[0018] In one embodiment, incoming data can be routed through the nomadic device via Data-over-Voice or Dataplan, through the onboard Bluetooth transmitter / receiver, and into the vehicle's internal processor 3. In the case of certain temporary data, the data can be stored, for example, on the HDD or another storage medium 7 until it is no longer needed. WiFi can also be used to transmit data, e.g., in a peer-to-peer manner.

[0019] Additional sources that can be connected to the vehicle include a personal navigation device 54, which may have, for example, a USB connection 56 and / or an antenna 58; a vehicle navigation device 60 with a USB 62 or other connection; an onboard GPS device 24; or a remote navigation system (not shown) that has connectivity to the network 61. USB is one of a class of serial networking protocols. IEEE 1394 (FireWire), EIA (Electronics Industry Association) serial protocols, IEEE 1284 (Centronics Port), S / PDIF (Sony / Philips Digital Interconnect Format), and USB-IF (USB Implementers Forum) form the backbone of device-to-device serial standards. Most of these protocols can be implemented for either electrical or optical communication.

[0020] Furthermore, the CPU could be in communication with various other auxiliary devices 65. These devices could be connected via a wireless 67 or wired 69 connection. The auxiliary device 65 could include, but is not limited to, personal media players, wireless health devices, portable computers, and the like. Additionally, or alternatively, the CPU could, for example, be connected to a vehicle-mounted wireless router 73 using a WiFi transmitter / receiver 71. This would allow the CPU to connect to remote networks within range of the local router 73.

[0021] In addition to exemplary processes being executed by a vehicle data processing system located in a vehicle, in certain embodiments the exemplary processes can be executed by a data processing system in communication with a vehicle data processing system. Such a system may include, but is not limited to, a wireless device (for example, a mobile phone) or a remote data processing system (for example, but is not limited to, a server) connected by the wireless device. Collectively, such systems may be referred to as a vehicle-associated data processing system (VACS). In certain embodiments, depending on the specific implementation of the system, certain components of the VACS may execute specific parts of a process.For example, and without limitation, if a process involves a step of sending or receiving information with a paired wireless device, then it is likely that the wireless device will not perform the process, since the wireless device would not "send and receive" information with itself. It is understandable to the average professional when it is not appropriate to apply a particular VACS to a given solution. All solutions assume that at least the vehicle data processing system (VCS) located within the vehicle itself is capable of performing the exemplary processes.

[0022] When using means other than cash to purchase goods, various methods of further identification are often required. For example, when using a credit card, gas pumps often require a user to enter a postcode, or possibly a PIN if the purchase is made with a debit card. Businesses that accept checks usually require the user to provide additional verification, such as a photo ID, to confirm that the buyer owns the checking account.

[0023] Even when using credit cards online, merchants typically require the entry of a three-digit code from the back of the card to ensure that the card number hasn't simply been copied or otherwise stolen from the front. However, for a variety of reasons, this can add a degree of inconvenience in certain situations. While some of the examples given here may seem rare, many of them will become more common as purchasing technology advances.

[0024] For example, in one scenario, a user might choose to purchase a product using a cordless phone. The purchase could be made using an account stored on the phone and linked to a bank or credit line account. To ensure the purchase isn't made using a stolen phone, the merchant might require secondary authentication, such as a PIN, password, or CID number. However, these numbers can be inconvenient to enter. Given the multitasking capabilities of phones, along with Bluetooth and other wireless connectivity, it's not unreasonable to envision a scenario where a phone wirelessly connects to a local facility for the purpose of making a purchase, using, for example, a purchasing application or other software / hardware installed on the phone.Simultaneously, the user can talk, text, browse the internet, etc. on the phone. Requiring the user to enter secondary identification may interrupt the ongoing communication session.

[0025] Although the interruption may be brief, it can also be avoided in certain situations, allowing for secondary identification beyond user-entered identification. For example, it is reasonable to assume that a person who drives their own (or family) vehicle and also owns their own (or family) telephone is likely either an account holder or authorized to use an account, particularly for (but not limited to) purchases of goods such as gasoline. The exemplary embodiments suggest non-restrictive examples of how communication between the telephone and a vehicle, in addition to or as an alternative including telephone / vehicle identification, can be used as a "background" means of secondary identification, thus eliminating the need for explicit input of identification.

[0026] This could be useful in a variety of scenarios and, although it is largely about convenience, can even provide increased security, as the likelihood of an unauthorized person possessing both a stolen phone and a vehicle is relatively low.

[0027] Fig. Figure 2A shows an illustrative example of a verification process. In this example, the process receives a validation request 201. In this example, the authentication front-end process is a secondary application / firmware running on the wireless device. It could also be integrated at any reasonable point on the communication line. For example, the process could be integrated into a fuel dispenser with a wireless transmitter / receiver, be part of a secondary application created to interact with various wireless devices, run on an onboard vehicle data processing system, and so on.

[0028] In this example, once the request is received, the process checks whether the wireless device is communicating with a vehicle data processing system. This establishes that the device is at least capable of providing some form of vehicle-based communication. In other, not shown, cases, an application running at the kiosk could request communication verification from both a wireless device and a vehicle, or the kiosk could communicate directly with a vehicle and request verification that a wireless device has connected, and so on.

[0029] If no communication is established, process 207 fails, and validation is not achieved. In such a case, secondary validation (e.g., a PIN, postal code, password, etc., without restriction) could be used. If communication with the vehicle exists, the system can check during this process whether a vehicle ID (transferable, for example, from the vehicle data processing system to the wireless device) matches a vehicle ID stored on the wireless device at a previous point when the purchase scheme was initiated. This could help prevent a situation where authorization was obtained simply based on a pairing between the wireless device and any unauthorized vehicle.If the application were running on a fuel pump, the pump could similarly query the phone for a stored ID and then query the vehicle for an ID and compare the two IDs, leading to a validation / rejection situation depending on the results of the comparison.

[0030] In this example, once the IDs have been compared and a match found, the process validates purchase 211. This could include, but is not limited to, sending purchase information (card number, account number, etc.), a validation code for use when validating purchase information, etc.

[0031] This system could also be used, for example, as a robust means of validating a credit card purchase. The user could swipe a card, and a process could establish communication with a wireless device, a vehicle, or both. Identifying the wireless device and the vehicle (and, if applicable, communication between them) could serve as a more secure means of identifying a user than simply entering, for example, a postcode. If a phone and wallet were stolen, a card and postcode would be easily obtainable (e.g., from a driver's license). But in this example, the thief would also need to possess the vehicle to use the card.Although the proposed exemplary embodiment concerns short-range communication, if long-range communication were established between a wireless device and a vehicle, the process could even be used to validate a card purchase or a device-based purchase at a retailer's business location (rather than near the point of purchase, such as a fuel pump).

[0032] Fig. Figure 2B shows an illustrative example of a second verification process. In this illustrative example, the exemplary process shown can again be operated in a suitable medium, in this case on a vehicle data processing system (VDS), which is equipped, for example, with wireless communication technology. The VDS communicates with a remote device, such as, but not limited to, a fuel pump 221 equipped with a transmitter / receiver. As a result of this communication, a request for payment information / validation is received from the remote device 223.

[0033] The VCS then communicates with a wireless user device, such as, but not limited to, a mobile phone 225. A validation request is sent to the wireless device 227, including any necessary information accompanying the request (such as a code or other suitable information that can verify the vehicle's ID to the wireless device). The wireless device can validate the vehicle both as authorized to communicate with the wireless device and as matching any cross-comparison information exchanged between the two data processing systems. A validation and any additional verification from the wireless device can be sent back to the VCS 229.

[0034] After any necessary internal checks (such as local verification of the wireless device's identification and authorization rights), the VCS can send a remote confirmation of payment to the merchant's device 231. Additionally, the VCS can then transmit data such as payment type, account ID, etc., along with the verification to the merchant 233. Additional information would include, but is not limited to, location (GPS), time, date, etc.

[0035] In at least one embodiment, an even higher level of security can be achieved by storing account numbers on one of the two systems (wireless device, VCS) that does not communicate with the remote merchant system, and using the other system for communication. In this scenario, the payment request is processed by the communicating system but can only succeed after verification by the non-communicating system and forwarding of the account information stored there by the communicating system. This could help prevent the "forced" transmission of account information when only a single device is involved, either by spoofing a second device ID or by other hacking of the device.

[0036] Fig. Figure 3A shows an illustrative example of another verification process. In this example, the system executing the process (e.g., and without limitation, a wireless device) receives a 301 payment request. As mentioned earlier, the request could come from a merchant system, another application running on or communicating with the wireless device, etc.

[0037] After receiving the request, the wireless device performing the verification process communicates with the vehicle data processing system 303. If no connection to the VCS exists, the process 307 refuses validation, as validation is not possible without communication. In alternative embodiments, the process could request the establishment of communication, provide input for secondary verification (PIN, password, etc.), and so on.

[0038] When communication exists between the wireless device and the VCS, the wireless device sends an identification characteristic to the VCS 309. This bidirectional identification between the two systems can provide an additional level of security, if desired. In response to a verification request and the transmission of a phone ID (e.g., but not limited to, a mobile ID number (MIN), processor ID, user ID, electronic serial number (ESN), etc.), the device receives an acknowledgment from the VCS 311, which in this case includes a vehicle identification (e.g., but not limited to, user ID, account ID, VIN, ESN, etc.).The wireless device can then not only verify that the vehicle has authorized the transaction (a process which alone could potentially be faked in this case), but can also verify the identity of the vehicle based on received information compared with information stored on a wireless device 315.

[0039] If all validations and / or comparisons are correct (317), the process can then send an authorization for the transaction (319) to the merchant facility. Additionally, or alternatively, account information to complete the purchase can be sent (or other suitable payment information, such as a smart transfer of stored funds).

[0040] In the system described above, all verification takes place between the wireless device and the vehicle data processing system. Verification information, such as identification information, does not need to be sent to the dealer device; instead, after verification is complete, account information and / or validation authorization can be sent to the dealer device. In at least one example, private-key encryption strategies can be implemented between the wireless device and the vehicle data processing system, eliminating the need to transmit any translatable, interceptable data. For example, if the process described above were used to verify a credit card swipe, the card data would be physically transmitted by the swiper, and an authorization code could be received from the wireless device.Since the wireless facility and the VCS might have established a private key session at some point prior to system initialization, a participant attempting to intercept the transmission would not obtain account information or readable validation information. Other suitable encryption strategies can also be implemented between the three systems (merchant, wireless facility, VCS) to encrypt data, such as, but not limited to, public / private key encryption.

[0041] Fig. Figure 3B shows an example of another verification process. In this example, a VCS receives an authorization request from a wireless device 331, which may be communicating with a merchant system. Along with the request, the VCS also receives an ID of the wireless device 333, which can be used to verify that the wireless device is a valid device. The wireless device ID can be compared by the VCS to a stored device ID to verify the identity of the requesting device. If the device is invalid (e.g., an unauthorized device is requesting validation), the process can simply deny validation 339.

[0042] If the facility ID is a valid ID, the process can approve the facility as a valid requesting facility and send an acknowledgment to the facility (341). In addition to sending the acknowledgment to the facility, the process can also send a vehicle ID (343), allowing the wireless facility to validate the VCS as an approved system for providing backend validation. In this way, it would be difficult to fake one side of the validation process, since each system in the two-party system knows the identity of the other system and requires specific validation of the other system's identity before the transaction is approved.

[0043] Two scenarios are presented below, the first being the less complex system of Fig. 2A outlines and the second the more complex system of Fig. 3A and Fig. Figure 3B outlines this. In both cases, secure transactions can be established based on the presence of both a known wireless device and a vehicle. Although all the examples given here are useful for illustrating possible processes, they are not intended to limit the scope of protection of the invention.

[0044] In the first scenario, Bob owns a mobile phone running a validation application and a Ford Escape equipped with a vehicle data processing system (such as, but not limited to, the Ford SYNC system). Bob arrives at a gas station and wants to refuel his vehicle. His phone is capable of Bluetooth communication with a gas pump, and the pump requests account information from the phone.

[0045] Before transmitting account information, the phone checks to verify that communication with the Ford Escape's VCS (Vehicle Control System) has been established. Once communication is verified, the phone then checks a received vehicle ID against an ID stored on the phone or receives other validation information from the VCS. If the validation / comparison matches an expected value, the phone then transmits any necessary account / authorization information to the pump for use when purchasing gasoline. In this scenario, anyone else using either Bob's phone or Bob's vehicle, but not both, will not be able to purchase gasoline this way because at least one of the verifications will fail.

[0046] In a second scenario, Mary has similar devices to Bob. Upon arriving at the gas pump, Mary's phone also receives a request for information and checks if communication with a VCS (Vehicle Control System) has been established. In addition to requesting verification and / or vehicle ID from the VCS, Mary's phone sends a specific form of ID to the VCS. The VCS then compares this received ID to a locally stored ID to ensure that it is indeed Mary's phone and not a bogus requester seeking validation. Once the phone's identity is established, the VCS can send back verification and / or a vehicle identifier. Mary's phone can compare this vehicle identifier to a stored vehicle identifier to ensure that it was indeed Mary's vehicle that sent back the verification / ID.Once both systems have mutually validated each other, any necessary information can be forwarded to the dealer system.

[0047] Numerous other configurations and communication channels are possible that can achieve a similar result and are considered to be within the scope of protection of the invention.

[0048] Fig. Figure 4A shows an illustrative example of a verification configuration process. This example shows a wireless device that first establishes a link with a VCS. In this example, an initialization request is sent from the wireless device to the VCS (401). Communication with the VCS is then established (403), and identification data can be sent from the wireless device to the VCS (405).

[0049] In response to the transmission of identification information, the process can receive vehicle identification information (VIN) 407, which can be stored locally 409. Additionally, although not shown, further verification information relating to a financial account can be entered at this point. This could include, for example, a password, a CID number, a PIN, etc. Entering this information (and validating it, for example, by communicating with an account provider) can help prevent a subscriber with a stolen phone / vehicle that stores previously entered financial information from simply creating a new pairing between an unauthorized and an authorized system and then using the stored financial information based on "false" verification.

[0050] Fig.Figure 4B shows an illustrative example of a second verification configuration process. In this example, a VCS receives an initialization request from a wireless device 421. In addition to the request, the VCS receives one or more elements that identify the wireless device 423. The VCS can then store the identification information received from the wireless device 425 and respond to the wireless device with a vehicle ID.

[0051] In another embodiment, not shown, one or both devices can store user identification information. At a certain point in the initialization process, one or both systems can require an initializer to verify the stored user information. For example, and without limitation, a username, address, and password could be stored on a wireless device. Initialization could then require a user to verify this information using the VCS (or vice versa), so that no improper pairing could be faked using only one authorized device.

[0052] Although this concept has been largely discussed in the context of financial transactions, it is also possible to use dual-factor authentication to control, for example, a home system such as a garage door. Any system that could be controlled by a telephone could first require authentication using a secondary source, and this concept is not limited to financial transactions. Additional possible, non-restrictive examples of locations where facility authentication could be used include, but are not limited to, parking garages, home garages, customs stations, gated communities, and so on.

[0053] In at least one non-restrictive example, geographic location can also be used to authenticate a user. For instance, a "default" area can be defined within which a user can be authenticated. This could be based on where a vehicle is parked, typical user habits, custom perimeters, and so on. If the validation attempt is made outside this area (e.g., if someone has taken the car and phone to an unusual location), validation can be denied or an additional authentication step can be required. This is just one example of an additional security measure that could be implemented.

Claims

[1] Computer-implemented method, comprising: Receiving a validation request in a vehicle data processing system (VCS) from a paired wireless device; Receiving facility identification information from the wireless facility; Validating the identity of the wireless device; and Sending vehicle identification information and payment-related information to the wireless device in response to validation of the wireless device's identity. [2] Method according to claim 1, wherein the facility identification information includes a mobile identification number. [3] Method according to claim 1, wherein the facility identification information includes an electronic serial number. [4] Method according to claim 1, wherein the facility identification information includes a processor ID number. [5] Method according to claim 1, wherein the validation further comprises comparing the received identification information with previously stored identification information. [6] Method according to claim 1, wherein the vehicle identification information includes a vehicle identification number. [7] Method according to claim 1, wherein the vehicle identification information includes an electronic serial number.

Images