Method and apparatus for wireless valet parking key configuration and relay

Abstract

The present disclosure provides a method and apparatus for wireless valet parking key configuration and relay. A system includes a processor configured to receive a valet parking key request from a valet parking mobile device. The processor is further configured to: in response to the request, request authentication of the key transmission; and in response to authentication approval, transmit vehicle data and key data from the owner's mobile device to the valet parking mobile device, the vehicle data describing the vehicle, the key data being usable to access and activate the vehicle.

Description

Technical Field

[0001] The illustrative embodiments generally relate to methods and apparatus for wireless valet parking key configuration and relaying. Background Art

[0002] An inconvenience associated with valet parking is that the owner must hand over the keys to the vehicle. In some cases, this may allow the valet unrestricted use of the vehicle. Some solutions to this problem have been proposed, such as geo-fencing when valet parking, or limiting driving characteristics, speed, mileage, etc. Unfortunately, they are only stopgap solutions and do not address the need to hand over a device to the valet, which may be lost.

[0003] Ride-sharing concepts and applications allow access to vehicles via codes, so an alternative is to provide valet parking attendants with access codes. Of course, in this case, the owner still needs to restrict access if necessary, and if many vehicles are so equipped, the valet parking attendant will have to keep track of a large number of access codes. In addition, the owner must reconfigure the access code for each valet parking attendant or there is a risk of leaking the access code of the vehicle. Summary of the invention

[0004] In a first illustrative embodiment, a system includes a processor configured to receive a valet parking key request from a valet parking mobile device. The processor is further configured to: in response to the request, request authentication for key transmission, and in response to authentication approval, transmit vehicle data and key data from a vehicle owner mobile device to the valet parking mobile device, the vehicle data describing the vehicle, the key data being usable to access and activate the vehicle.

[0005] In a second illustrative embodiment, a system includes a mobile device processor configured to wirelessly receive a plurality of data sets including key data and vehicle data for a plurality of vehicles, each data set including vehicle data identifying a particular vehicle and key data for accessing and activating the particular vehicle and transmitted from another mobile device. The processor is further configured to display a selectable list of vehicles to which the data sets correspond, and to use the key data for a selected vehicle to cause a device including the processor to function as a remote key for the selected vehicle.

[0006] In a third illustrative embodiment, a computer-implemented method includes, in response to a transmission request received at a first mobile device from a second mobile device via a short-range wireless protocol, transmitting vehicle identification data, vehicle activation data, and usage constraints from the first mobile device to the second mobile device, the usage constraints constraining at least a duration of vehicle usage or activation data. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0008] Figure 2 An illustrative key sharing process is shown;

[0009] Figure 3 An illustrative valet side receiving and display process is shown;

[0010] Figure 4A and Figure 4B Illustrative displays from the perspective of a valet (4A) and a driver (4B) are shown; and

[0011] Figure 5 An illustrative key usage process is shown. DETAILED DESCRIPTION

[0012] As required, detailed embodiments are disclosed herein; however, it should be understood that the disclosed embodiments are merely illustrative and may be combined in different and alternative forms. The drawings are not necessarily drawn to scale; some features may be exaggerated or minimized to show details of particular components. Therefore, the specific structural and functional details disclosed herein should not be interpreted as limiting, but merely as a representative basis for teaching those skilled in the art to employ the claimed subject matter in various ways.

[0013] Figure 1 An example block diagram topology of a vehicle-based computing system 1 (VCS) of 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 implemented with a vehicle-based computing system may include a visual front end interface 4 located in the vehicle. A user may also be able to interact with the interface (if provided) using, for example, a touch screen display. In another illustrative embodiment, the interaction occurs through button presses, a spoken dialog system with automatic speech recognition, and speech synthesis.

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

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

[0016] Outputs to the system may include, but are not limited to, a visual display 4 and a speaker 13 or stereo system 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 may 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 bi-directional data streams shown at 19 and 21 respectively.

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

[0018] Exemplary communications between the ND 53 and the BLUETOOTH transceiver 15 are represented by signals 14 .

[0019] Pairing of the ND 53 and the BLUETOOTH transceiver 15 may be instructed by a button 52 or similar input. Thus, the CPU is instructed that the onboard BLUETOOTH transceiver is to be paired with the BLUETOOTH transceiver in the nomadic device.

[0020] Data may be transferred between the CPU 3 and the network 61 using, for example, a data plan, data over voice, or dual tone multi-frequency (DTMF) tones associated with the ND 53. Alternatively, it may be desirable to include an onboard modem 63 having an antenna 18 to transfer 16 data between the CPU 3 and the network 61 over the voice band. The ND 53 may then be used to communicate 59 with the network 61 outside of the vehicle 31, for example, through communications 55 with a cellular tower 57. In some embodiments, the modem 63 may establish communications 20 with the tower 57 to communicate with the network 61. As a non-limiting example, the modem 63 may be a USB cellular modem, and the communications 20 may be cellular communications.

[0021] In one illustrative embodiment, the processor is provided with an operating system that includes an application program interface (API) for communicating with modem application software. The modem application software can access an embedded module or firmware on the Bluetooth transceiver to complete wireless communication with a remote Bluetooth transceiver (e.g., those present in a nomadic device). Bluetooth is a subset of the IEEE 802 PAN (Personal Area Network) protocol. 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. Another means of communication that can be used in this field is free space optical communication (e.g., Infrared Data Crosslink (IrDA)) and non-standardized consumer infrared (IR) protocols.

[0022] In another embodiment, the ND 53 includes a modem for voice band or broadband data communications. In the data-over-voice embodiment, a technique called frequency division multiplexing can be implemented when the owner of the nomadic device can talk on the device while data is being transmitted. At other times, when the owner is not using the device, data transmission can use the entire bandwidth (300Hz to 3.4kHz in one example). Although frequency division multiplexing may be common for analog cellular communications between vehicles and the Internet, and is still used, it has been largely replaced by code domain multiple access (CDMA), time domain multiple access (TDMA), and space domain multiple access (SDMA) for digital cellular communications. If the user has a data plan associated with the nomadic device, the data plan may allow broadband transmission, and the system can use a wider bandwidth (speeding up data transmission). In yet another embodiment, the ND 53 is replaced by a cellular communication device (not shown) installed on the vehicle 31. In yet another embodiment, the ND 53 may be a wireless local area network (LAN) device capable of communicating through, for example (but not limited to), an 802.11g network (i.e., Wi-Fi) or a Wi-Max network.

[0023] In one embodiment, the incoming data may be delivered to the vehicle's internal processor 3 through the nomadic device via a data-over-voice or data plan, through the vehicle's onboard Bluetooth transceiver. For example, in the case of certain temporary data, the data may be stored on a HDD or other storage medium 7 until the data is no longer needed.

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

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

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

[0027] In addition to having the exemplary process performed by a vehicle computing system located in a vehicle, in certain embodiments, the exemplary process may be performed by a computing system that communicates with the vehicle computing system. Such a system may include, but is 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 via a wireless device. These systems may be collectively referred to as a vehicle associated computing system (VACS). In certain embodiments, specific components of the VACS may perform specific portions of the process depending on the specific implementation of the system. As an example and not limitation, if a process has a step of sending or receiving information via a paired wireless device, it is likely that the wireless device does not perform that portion of the process because the wireless device will 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 exemplary, non-limiting example of a process that may 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 may be configured as a dedicated processor to perform the process. Not all processes need to be performed in their entirety, and should be understood as examples of types of processes that may be performed to implement elements of the present invention. Additional steps may be added or deleted from the exemplary processes as desired.

[0029] With respect to the illustrative embodiments described in the accompanying drawings showing illustrative process flows, it should be noted that a general purpose processor may be temporarily enabled as a special purpose processor in order to perform some or all of the exemplary methods shown in these drawings. When executing code that provides instructions to perform some or all of the steps of the method, the processor may be temporarily reused as a special purpose processor until the method is completed. In another example, to the extent appropriate, firmware acting according to a pre-configured processor may cause the processor to act as a special purpose processor provided for the purpose of performing the method or some reasonable variant thereof.

[0030] As vehicles and mobile devices such as smartphones become more advanced, solutions are being considered that allow drivers to use their phones as a proxy for remote keys to enable passive entry and passive start solutions based on the presence of the phone (allowing touch entry and touch start). While this can save the user from having to carry keys, it still does not solve the valet sharing problem because in this case the owner must actually provide the valet with the owner's phone.

[0031] In an illustrative embodiment, the above-described problems are addressed by allowing the vehicle owner to share the digital aspects of a valet parking key for temporary use. This can allow the vehicle owner to have a one-touch (or even automatic) option for wirelessly sharing a valet parking key without any physical exchange of devices. Since the key can be subject to restricted use, parameters can be attached to the key that restrict the valet's use, while the key can simply expire (for example, but not limited to, the vehicle owner actually uses their own device to start the vehicle, the time period expires, the vehicle is driven more than the X distance the valet is allowed, etc.).

[0032] Figure 2 An illustrative key sharing process is shown. In this illustrative example, a process running on a device or vehicle on the driver's side receives 201 a communication from a valet parking application. This can be an explicit request from the valet parking device or application, or can be in response to a valet parking application that is about to arrive within a certain distance of the device or vehicle provided with the sharing application. If the device or vehicle on the driver's side approves 203 the request, the process presents a set of configurable parameters to the driver. These parameters can be pre-configured, or these parameters can be configured by the driver at each use. The initial values ​​of the parameters can be set based on location type, calendar or email, or in any other suitable manner.

[0033] For example, a driver may specify via email or calendar event that the driver will be staying at a hotel for 2 days, or at a restaurant for 2 hours. When the vehicle arrives at that location, the process can "know" the expected stop and set basic duration parameters based on that location. The process can also configure mileage based on the location type. In another example, a valet parking application can send the minimum mileage required to process a valet parking, which can be used to accommodate unexpected distances for remote parking lots, etc.

[0034] The process presents 205 the driver with a basic set of parameters (unless the driver prefers default parameters that are preset or specified by the valet parking application as described above). The process may also receive 207 any parameter modifications from the driver (extending or shortening time, distance, maximum speed, etc.). The process then sends 209 the permission data and vehicle data to the valet parking application and saves 211 the parameters locally. The locally saved parameters can serve as a fallback measure so that even if the valet parking parameters are hacked, the vehicle "knows" that it is appropriate not to make such changes. This also avoids the situation where a key that has expired and failed is still usable.

[0035] Regarding the data transmitted, the process may send the vehicle make, model, color, etc. The vehicle odometer reading may be sent and saved, and any other relevant information may be included. In addition, the process also transmits permission data for temporary entry and start (similar to the driver device key). And, in some cases, if there are certain other engagement requirements, such as "device in driver's seat" or "device within 2 meters of vehicle", etc., the process may send those requirements so that the valet key complies with the constraints set on the driver key if needed.

[0036] Figure 3 An illustrative valet side receiving and display process is shown. In this example, the process communicates 301 with a driver side device or vehicle to request 303 key data from the driver. This may include communications based on proximity or other automated functions, or communications explicitly requested from a valet parking application. The valet parking company may download and install a key receiving application that may be provided to an employee device or device held for use as a key.

[0037] If the initial request is approved (i.e., if the driver intends to use the valet parking service), the process can receive 307 the vehicle and key data. It is worth noting that multiple valet parking applications can synchronize and share key data so all valet parking attendants have access to all keys, and / or the key data can be stored in the cloud or on a local server and each valet parking device will obtain the required data from the central storage. This can prevent a single valet parking device containing keys from preventing a different valet parking attendant (one who does not own the device) from retrieving the vehicle. This can also accommodate shift changes, especially when valet parking attendants are using their own devices. Login or other authentication can provide the valet parking device application with all currently available keys.

[0038] The process receives the transmitted data and configures the parameters associated with the key 309. This can include, for example, a countdown clock to expiration and any usage constraints set on driving the vehicle. This is configured behind the scenes, but if an owner override is needed to change the parameters, the parameters can be displayed to the valet (i.e., the speed limit is 20 mph, but the valet must drive on a 40 mph road to reach the valet lot).

[0039] The process on the valet side then displays 311 the vehicle data, which may include, for example, the make and model, color, license plate, etc. The display may also include 313 an expiration countdown clock so the valet knows when the key will expire. If the key is expired 315 or close to expiration, the process may ask the valet if more time is needed (i.e., whether the customer has already retrieved the vehicle) 317.

[0040] If the valet needs more time, the process can send 321 a request to the driver device for an extension of time. If the driver approves 323 more time for the request, the process can add 327 time to the expiration time and continue to display the expiration time. If the driver does not approve the additional time, the process can notify 325 the driver that the valet parking key is now disabled, which may require the driver to reissue a new valet parking key when leaving (if necessary and if the driver is not just retrieving their own vehicle). If the key expires and no more time is added, the process can delete 319 the key data stored on any valet parking device and / or any central valet parking server. The driver can also initiate such a deletion command at any time, and if there is an automatic trigger for deletion (driver driving away from the location, driver using his own key, etc.), this may cause the deletion command to be sent to the valet parking device and / or server.

[0041] Figure 4A and Figure 4B Illustrative displays from the perspective of a valet (4A) and a driver (4B) are shown. Figure 4A , a non-limiting example of an application on the valet side 401 is shown. This includes, for example, a list of vehicles 403. Each vehicle may include a license plate number 405, color 407, and a current time before expiration 409. Other characteristics may be added or deleted as appropriate. The display also includes an option 413 for the valet to select a specific vehicle to which the selectable action is to be applied.

[0042] The illustrative display application also includes a scroll 415 option and a list 411 of how many additional vehicles are available. The display may also include functions such as a button for sending a request 417 for a new key download, a delete 421 button, and one or more key fob control buttons 419.

[0043] In one example, the valet parking application causes the selected vehicle to respond to the presence of a device that is a passive entry passive start (PEPS) key, so that the key fob functionality is not used, but the selection of the activation 419 button can enable the PEPS functionality of the selected vehicle. In other examples, the application interface can include key fob functionality (trunk, remote start, remote unlock, etc.). These can be dynamically configured for each vehicle so that the functionality corresponding to the actual possible vehicle functionality appears or is enabled on a vehicle-by-vehicle basis.

[0044] Figure 4B A non-limiting driver-side application interface 431 is shown, which may be present on a driver mobile device (e.g., a cell phone) or on a vehicle human-machine interface (HMI) in the vehicle. The interface includes a notification of a valet parking request, including, for example, identification 433 of the party. If the application requesting the key has a unique business identifier associated with it, the driver may know that the request is associated with the current location where the vehicle is parked or located. The process may also include the location 435 of the device or server that issued the request, which may include a directional arrow. Using data such as a received signal strength indicator (RSSI), various vehicle antennas / transceivers or other sensors may detect the location and direction.

[0045] The driver interface may also include, for example, a duration parameter 437 and a mileage parameter 439, as well as any other configurable parameters. In this example, if the default value is not appropriate, the driver can scroll the parameter value to change the parameter to the desired value. If there is a minimum value, such as transmitted by the valet parking application, the process can prevent scrolling past that point or alert the driver and / or valet if the minimum value is exceeded. For example, if the driver has a $150,000 vehicle, the driver may want to limit the mileage to .05 miles, but the valet parking minimum may be .2 miles. The driver can set a lower minimum with the valet, knowing that the vehicle may therefore be parked directly in front of the building. The interface also includes an option 441 for the driver to approve or deny the valet parking request.

[0046] Figure 5 An illustrative key usage process is shown. In this example, the process receives 501 an activation request from a valet using an application program on the valet's side. The process accesses 503 any parameters associated with the particular key (proximity, location within the vehicle, etc.) to determine if any additional 505 data is required. For example, a paranoid driver may not want the valet parking PEPS feature enabled for their vehicle unless the valet is within 10 feet of the vehicle (even though this is not a "normal" key parameter) to prevent accidental activation and access to the vehicle. These configurable parameters can indicate any additional data required for activation. In another example, the parameter can be, for example, an actual request sent to the driver's device that requires driver approval each time the key is used.

[0047] If no additional data is required, the process performs 507 an activation request for the selected vehicle so that the valet parking device can function as a PEPS or other suitable key for accessing and starting the vehicle. If additional data is required, the process may collect 509 the additional data and determine whether the collected data meets the required parameter settings 511. For example, the process may determine whether the valet is within 10 feet of the vehicle (to use the above parameter example) and if the data does not match, the process may notify 513 the valet of any problems. For example, in the previous example, the process may notify the valet that "the device must be within 10 feet of the vehicle's location to enable this key." There is also the possibility of limited functionality until the parameters are met, for example, the valet may use the device to locate the vehicle at any time with a short sound or flash, but may not enable unlock and start commands until the parameters are met.

[0048] By using the illustrative embodiments and the like, the driver has the option of providing on-demand keys to a valet parking service that does not necessarily require any on-site configuration or exchange of physical devices. These keys may also be used to restrict travel and may eventually expire, thereby addressing concerns about improper vehicle use.

[0049] Although exemplary embodiments are described above, this does not mean that these embodiments describe all possible forms of the invention. Rather, the words used in this specification are descriptive rather than restrictive, and it should be understood that various changes can be made without departing from the spirit and scope of the invention. In addition, the features of various implementation embodiments can be combined in a logical manner to produce contextually appropriate variations of the embodiments described herein.

[0050] According to the present invention, a system is provided, the system having a processor configured to: receive a valet parking key request from a valet parking mobile device; in response to the request, request authentication of the key transmission; and in response to authentication approval, transmit vehicle data and key data from the vehicle owner mobile device to the valet parking mobile device, the vehicle data describing the vehicle, the key data being usable to access and activate the vehicle.

[0051] According to one embodiment, the vehicle data includes a vehicle make or model.

[0052] According to one embodiment, the vehicle data comprises vehicle color.

[0053] According to one embodiment, the vehicle data comprises a vehicle registration number.

[0054] According to one embodiment, the key data comprises a set of vehicle remote key functions.

[0055] According to one embodiment, the key data comprises predefined parameters for using the key data.

[0056] According to one embodiment, the processor is further configured to: in response to the request, present the configurable usage constraints on an interface accessible to the driver.

[0057] According to one embodiment, the processor is configured to transmit usage restrictions with the key data and the vehicle data.

[0058] According to one embodiment, the processor is configured to save a copy of usage constraints on board the vehicle, said usage constraints constraining the use of the key data when accessing or activating the vehicle.

[0059] According to one embodiment, the usage constraint includes mileage.

[0060] According to one embodiment, the usage constraints include a key data duration.

[0061] According to the present invention, a system is provided, which has a mobile device processor configured to: wirelessly receive multiple data sets including key data and vehicle data of multiple vehicles, each data set including vehicle data identifying a specific vehicle and key data for accessing and activating the specific vehicle and transmitted from another mobile device; display a selectable list of vehicles corresponding to the data sets; and use the key data of the selected vehicle to enable the device including the processor to be used as a remote control key for the selected vehicle.

[0062] According to one embodiment, the processor is configured to display vehicle characteristics identified by the vehicle data for each vehicle as part of the selectable list.

[0063] According to one embodiment, the vehicle characteristics include a vehicle make or model.

[0064] According to one embodiment, the vehicle characteristics include vehicle color.

[0065] According to one embodiment, the vehicle characteristics include a vehicle registration number.

[0066] According to one embodiment, the processor is configured to display an expiration time for the key data associated with each vehicle as part of the displayed selectable list.

[0067] According to one embodiment, the processor is configured to: track a key data expiration time defined by the key data for each of the plurality of vehicles; and wirelessly request additional time from the driver device if the expiration time is within a predefined expiration threshold and the driver has not used the driver device to access or activate the vehicle after providing the key data.

[0068] According to the present invention, a computer-implemented method includes: in response to a transmission request received at a first mobile device from a second mobile device via a short-range wireless protocol, transmitting vehicle identification data, vehicle activation data and usage constraints from the first mobile device to the second mobile device, the usage constraints at least restricting the duration of vehicle usage or activation data.

[0069] According to one embodiment, the above invention is also characterized in that a request to exceed usage constraints is received from a second mobile device at a first mobile device; the request is displayed on the first mobile device; and in response to user approval of the request, user-modified usage constraints are sent, and the user-modified usage constraints are modified via the first mobile device in response to the request.

Claims

1. A system for wireless valet parking, comprising: A processor of a mobile device of a vehicle owner, the processor being configured to: receiving a valet parking key request from the valet parking mobile device in response to the valet parking mobile device being within a predetermined proximity of the vehicle owner mobile device; In response to the request, requesting authentication of the key transmission; as well as In response to authentication approval, vehicle data and key data are transmitted from the vehicle owner mobile device to the valet parking mobile device, the vehicle data describing the vehicle and the key data being usable to access and activate the vehicle.

2. The system of claim 1, wherein the vehicle data comprises a vehicle make, model or color.

3. The system of claim 1, wherein the vehicle data includes a vehicle license plate number. 4 . The system of claim 1 , wherein the key data includes a set of vehicle remote key functions. 5 . The system of claim 1 , wherein the key data includes predefined parameters for using the key data.

6. The system of claim 1, wherein the processor is further configured to: In response to the request, configurable usage constraints are presented on an interface accessible to the driver, and the usage constraints are transmitted with the key data and the vehicle data. 7 . The system of claim 6 , wherein the processor is configured to save a copy of the usage constraints on the vehicle, the usage constraints restricting use of the key data when accessing or activating the vehicle. The system of claim 6 , wherein the usage constraint includes mileage.

9. The system of claim 6, wherein the usage constraints include a key data duration.

10. A system for wireless valet parking, comprising: A processor of a valet parking mobile device, the processor being configured to: In response to a plurality of vehicle owner mobile devices corresponding to a plurality of vehicles being within a predetermined proximity of the valet parking mobile device, wirelessly receiving a plurality of data sets including key data and vehicle data for a plurality of vehicles, each data set including the vehicle data identifying a particular vehicle and key data for accessing and activating the particular vehicle and transmitted from the corresponding vehicle owner mobile device; Displaying a selectable list of vehicles corresponding to the data set; as well as Using the key data for a selected vehicle causes the valet parking mobile device to function as a key fob for the selected vehicle.

11. The system of claim 10, wherein the processor is configured to display vehicle characteristics identified by the vehicle data for each vehicle as part of the selectable list.

12. The system of claim 11, wherein the vehicle characteristics include vehicle make, model, or color.

13. The system of claim 11, wherein the vehicle characteristics include a vehicle license plate number.

14. The system of claim 10, wherein the processor is configured to display an expiration time for key data associated with each vehicle as part of the displayed selectable list.

15. The system of claim 14, wherein the processor is configured to: tracking a key data expiration time defined by the key data for each of the plurality of vehicles; and If the expiration time is within a predefined expiration threshold, and the driver has not used the owner mobile device to access or activate the vehicle after providing the key data, additional time is wirelessly requested from the owner mobile device.

Images