Patent Description:
This patent application also claims priority to <CIT>, entitled "Mobile Device-Enhanced User Selection of Specific Rental Vehicles for a Rental Vehicle Reservation", which claims priority to <CIT>, entitled "Mobile Device-Enhanced Rental Vehicle Transactions".

<CIT> discloses a vehicle access control. In various embodiments, a vehicle reservation from a wireless communication device is received, the vehicle reservation is authenticated, and access to the vehicle is provided after authenticating the vehicle reservation.

<CIT> discloses a method for accessing a motor vehicle, characterized that in that it comprises the following steps: establishment of a contactless communication at very short range between a communicating mobile device and a first contactless reader of the motor vehicle disposed near the outside surface of the motor vehicle; communication of an opening key from the communicating mobile device to the first contactless reader; recognition of the key and actuation of at least one door of the motor vehicle so as to open it and allow entry to the motor vehicle.

<CIT> discloses a mobile communication device that is equipped with hardware and/or software components to enable the device to output a data in a form of radio frequency signal, emulating outputting of the data by either an active or a passive RFID transponder.

The present invention provides a method according to claim <NUM> and a vehicle rental system according to claim <NUM>.

The inventors believe that room for improvement exists with respect to how portable computing devices (hereinafter "mobile devices") are leveraged to support rental vehicle transactions. Toward this end, the inventors disclose that a wide variety of rental vehicle transactions can be supported by mobile devices in a manner more convenient and efficient to customers.

The inventors also disclose how rental vehicles can be configured to support automated self-rental without a need to distribute any keys to renters. With such examples, machine-sensible items such as mobile devices can be used to effectively replace the role of keys for rental vehicles, including not only door lock/unlock function but also vehicle ignition function.

In the following, when a reference is made to an example when discussing <FIG>, it concerns an example which may be useful for understanding the context of how the claimed invention or components thereof may be used.

<FIG> depicts an exemplary system <NUM> for an embodiment that employs mobile devices to streamline how rental vehicle transactions are conducted. The system <NUM> may comprise at least one and preferably a plurality of mobile devices <NUM> in communication with a rental computer system <NUM> via a data communications network <NUM>. The system <NUM> may further comprise at least one and preferably a plurality of rental vehicles <NUM>, where these rental vehicles <NUM> are also configured to communicate with the network <NUM>. Thus, the rental computer system <NUM> can be configured to communicate with the rental vehicles <NUM> via the network <NUM>. Also, if desired by a practitioner, the mobile devices <NUM> can also be configured to communicate with the rental vehicles <NUM> via the network <NUM>.

The mobile device <NUM> can be a smart phone (e.g., an iPhone, a Google Android device, a Blackberry device, etc.), tablet computer (e.g., an iPad), or the like. Furthermore, the mobile device <NUM> can be a position tracking-enabled mobile device. That is, the mobile device <NUM> can be configured to track its geographic position and communicate data regarding same to other computing devices (e.g., to rental computer system <NUM>). The mobile device preferably employs a touchscreen or the like for interacting with a user. However, it should be understood that any of a variety of data display techniques and data input techniques could be employed by the mobile device. For example, to receive inputs from a user, the mobile device need not necessarily employ a touchscreen - it could also or alternatively employ a keyboard or other mechanisms.

<FIG> depicts an example of a mobile device <NUM> that is useful for understanding the invention. The mobile device <NUM> may comprise a processor <NUM> and associated memory <NUM>, where the processor <NUM> and memory <NUM> are configured to cooperate to execute software and/or firmware that supports operation of the mobile device <NUM>. Furthermore, the mobile device <NUM> may include an I/O device <NUM> (e.g., a touchscreen user interface for graphically displaying output data and receiving input data from a user), a camera <NUM>, wireless I/O <NUM> for sending and receiving data, a microphone <NUM> for sensing sound and converting the sensed sound into an electrical signal for processing by the mobile device <NUM>, and a speaker <NUM> for converting sound data into audible sound. The wireless I/O <NUM> may include capabilities for making and taking telephone calls, communicating with nearby objects via near field communication (NFC), communicating with nearby objects via RF, and/or communicating with nearby objects via BlueTooth. These components are now resident in many standard models of smart phones and other mobile devices.

<FIG> depicts an exemplary mobile application <NUM> that is useful for understanding the invention. Mobile application <NUM> can be installed on the mobile device <NUM> for execution by processor <NUM>. The mobile application <NUM> preferably comprises a plurality of computer-executable instructions resident on a non-transitory computer-readable storage medium such as a computer memory. The instructions may include instructions defining a plurality of GUI screens for presentation to the user through the I/O device <NUM>. The instructions may also include instructions defining various I/O programs <NUM> such as:.

The instructions may further include instructions defining a control program <NUM>. The control program can be configured to provide the primary intelligence for the mobile application <NUM>, including orchestrating the data outgoing to and incoming from the I/O programs <NUM> (e.g., determining which GUI screens <NUM> are to be presented to the user).

The network <NUM> can be any data communications network capable of supporting communications between the rental computer system <NUM> and mobile devices <NUM> as well as communications between the rental computer system <NUM> and rental vehicles <NUM>, wherein at least a portion of the data communication is wireless data communication as shown in <FIG>. It should be understood that network <NUM> may comprise multiple data communication networks that interconnect to form a larger network. The network <NUM> may be public, private, or a mix of public and private networks.

The rental computer system <NUM> can be a server or collection of servers that are configured to support rental vehicle transaction processing as described herein. The rental computer system <NUM> can be operated by a rental vehicle service provider such as a rental car company. However, it should be understood that other entities may operate the system. <FIG> depicts an example of the rental computer system <NUM> that is useful for understanding the invention. The system <NUM> may comprise a processor <NUM> and associated memory <NUM>, where the processor <NUM> and memory <NUM> are configured to cooperate to execute software that performs transaction processing as described herein. A memory in the form of database <NUM> may be configured to store various data structures representative of rental vehicle reservations and the customers for same. The system <NUM> may further comprise one or more I/O interfaces (e.g., I/O interfaces <NUM> and <NUM> for communicating via wireless RF and Internet links, respectively). It should be understood that <FIG> is exemplary only, and a practitioner may distribute the processing tasks described herein among numerous processors as well as distribute the data storage tasks described herein among numerous databases. Examples of rental car computer systems that can be employed for this purpose are described in <CIT>,<CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, and <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>,<CIT>, <CIT>, <CIT>, <CIT>,<CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, and <CIT>, and published <CIT>.

<FIG> describe exemplary process flows that can be executed by the processor <NUM> of the rental computer system to support various rental vehicle transactions.

<FIG> depicts an exemplary process flow for execution by the rental computer system to create or activate a rental vehicle transaction via communications over network <NUM> with a mobile device <NUM>. Step <NUM> may involve communicating data to the mobile device <NUM> via network <NUM> to populate various GUI screens on the mobile device <NUM> with information such as rental vehicle reservation options. The step <NUM> may also involve the rental computer system <NUM> receiving customer information for a reservation transaction from the mobile device <NUM>. At step <NUM>, the rental computer system <NUM> can store data representative of the rental vehicle transaction in database <NUM>.

<FIG> depicts an exemplary process flow for execution by the rental computer system to open a rental contract for a rental vehicle transaction. As is well understood, rental vehicle service providers typically require that customers become a party to a rental contract with the rental vehicle service provider in order for the customer to pick up a rental vehicle in accordance with a reservation. Simply having a rental vehicle reservation does not entitle the customer to pick up a rental vehicle. At step <NUM>, the rental computer system communicates data to the mobile device <NUM> via network <NUM> to populate various GUI screens on the mobile device <NUM>, where these screens are configured to solicit input from the customer for creating a rental contract from a reservation. Examples of GUI screens and process flows that can be used by step <NUM> for such rental contract creation are described in<CIT>, <CIT>, and <CIT> and published <CIT>. Once a rental contract is in place, the rental computer system <NUM> can also interact with the mobile device <NUM> to open the rental contract. As used herein, a rental contract is said to be open during the time from when the customer has actually picked up the rental vehicle to the time when the customer has returned control of the rental vehicle to the rental vehicle to the rental vehicle service provider. At step <NUM>, the rental computer system <NUM> can store data representative of the opened rental contract in database <NUM>.

<FIG> depicts an exemplary process flow for execution by the rental computer system to administer the return of a rental vehicle and end the corresponding rental vehicle transaction. When it comes time for a customer to end his or her rental of a rental vehicle, the rental computer system <NUM> can communicate at step <NUM> with the mobile device <NUM> via network <NUM> to populate various GUI screens on the mobile device <NUM>, where these screens are configured to solicit input from the customer for scheduling a return of the rental vehicle. In response to inputs from the mobile device <NUM>, the rental computer system <NUM> can store data representative of the return information and transaction completion in database <NUM>.

Additional aspects of the process flows of <FIG> are described below with reference to examples that are useful for understanding the invention.

It should be understood that the rental vehicle transactions supported by <FIG> and other examples described herein can include not only conventional retail rental vehicle reservations (including incremental rental vehicle reservations) but also replacement rental vehicle reservations. Drivers whose regular vehicles are disabled as a result of accidents or otherwise will often need to engage a rental vehicle while their regular vehicles are being repaired. As the term is used herein, a vehicle may become disabled by either the driver having had an accident, thereby causing damage for a repair facility (e.g., body shop, mechanic, etc.) to fix, or simply through mechanical failure, maintenance, or other similar desires or needs for changes requiring the custody of the vehicle to be relinquished to a repair facility. In many instances, an insurance company, automobile dealer, or fleet company will provide a rental vehicle to such drivers as part of the services provided through automobile insurance policies, dealer service policies, or fleet service policies. Such rental vehicles are referred to herein as "replacement rental vehicles" or "replacement vehicles". Replacement rental vehicles represent an important source of business for rental vehicle service providers given the large volumes of drivers whose regular vehicles become disabled as a result of accidents, mechanical breakdowns, and other causes.

In this business chain, there are four primary parties - the first is the driver (or customer) whose vehicle becomes disabled (thereby creating a need for a replacement rental vehicle), the second is the purchaser of rental vehicle services who books a rental vehicle reservation on behalf of the driver (typically an insurance company, automobile dealer, etc.), the third is the rental vehicle service provider with which the purchaser books the rental vehicle reservation, and the fourth is the repair facility where the driver's disabled vehicle is repaired.

In a typical replacement rental scenario, a driver whose regular vehicle has become disabled (e.g., the driver has had an accident) notifies the purchaser (e.g., the driver's insurance company) of his/her need for a replacement rental vehicle. The purchaser then books a reservation for a replacement rental vehicle with a rental vehicle service provider. Oftentimes, this reservation is consummated when the driver drops his/her disabled vehicle off at the repair facility. An employee of the rental vehicle service provider who has been notified of the booked reservation will meet the driver at the repair facility to provide the driver with the replacement rental vehicle. At this time, the rental vehicle service provider employee will fill out rental contract paperwork with the driver for the replacement rental vehicle, and if the terms are agreeable to the driver, the driver signs the rental contract paperwork to form a rental contract with the rental vehicle service provider.

Another common scenario is that an employee of the rental vehicle service provider will pick the driver up from the repair facility to take the driver to a nearby rental vehicle branch location. From the rental vehicle branch location, the driver and rental vehicle service provider employee can then fill out the rental contract paperwork to form the rental contract. In either event, once the rental contract paperwork has been filled out and signed, the driver is enabled to pick up his/her replacement rental vehicle.

The inventors have sought to improve the efficiency of this process through intelligent leveraging of mobile devices as described herein (see, for example, the examples described in connection with <FIG>). <FIG> depicts an exemplary system through which replacement rentals can be managed. That rental computer system <NUM> can include an automated reservation management computer system <NUM>, where the automated reservation management computer system <NUM> comprises reservation management software <NUM> and a database, which forms at least a portion of database <NUM>, in which replacement rental vehicle reservation transactions are stored. A purchaser computer system <NUM> can access the reservation management software <NUM> via a network <NUM> (which may include the Internet (see bidirectional communication path <NUM>)). Through the reservation management software <NUM>, a user of the purchaser computer system <NUM> can create and manage a plurality of replacement rental vehicle reservations on behalf of drivers/customers whose ordinary vehicles are undergoing repair at a repair facility. The management functionality provided by the system <NUM> can be employed to take management actions on rental vehicle reservations throughout all operational activity phases of rental vehicle reservations, including a reservation phase (starting from the time of reservation creation until a rental contract is opened), an open rental contract phase (starting from rental contract opening until rental vehicle return to close the rental contract), and a closed rental contract phase (for after the rental vehicle has been returned by the driver). A repair facility computer system <NUM> can also be in communication with the automated reservation management computer system <NUM> via the network <NUM> (see the bidirectional communication path <NUM>). The repair facility computer system <NUM> can be configured to communicate vehicle repair data to the automated reservation management computer system <NUM> for use in the management of replacement rental vehicle reservation transactions. Furthermore, as described herein, the repair facility computer system <NUM> can be configured to access the reservation management software <NUM> to manage the pick up process for replacement rental vehicles corresponding to replacement rental vehicle reservation transactions. An example of a suitable automated reservation management computer system <NUM> is the pioneering replacement rental vehicle reservation management system known as the ARMS® system operated by Enterprise, which is described in various patents and published patent applications such as: <CIT>,<CIT>, <CIT>, <CIT>, <CIT>, and<CIT>, and <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, <CIT>, and <CIT>.

It should further be understood that the rental vehicles underlying the rental vehicle transactions supported by <FIG> and other examples described herein can include not only conventional rental vehicles (e.g., the standard vehicles for which personnel of a rental vehicle service provider provide keys to customers at the time of pickup), but also self-rent rental vehicles. This applies to both retail rental vehicle reservations and replacement rental vehicle reservations. In fact, the inventors believe that a significant synergy results from the combination of mobile device-enhanced rental vehicle transaction processing as described herein with self-rent rental vehicles because this combination is expected to provide dramatic improvements in efficiency and convenience for customers. A "self-rent" rental vehicle is rental vehicle configured with hardware and software that enables authorized customers to access and start the rental vehicle without directly interacting with other people (such as personnel of a rental vehicle service provider), including during the rental vehicle pickup process. With a self-rent rental vehicle, the customer will have an access device that is configured to be recognized by hardware and software installed in the self-rent rental vehicle to unlock and de-immobilize the self-rent rental vehicle. As described herein, an example of such an access device can be the customer's mobile device <NUM>. However, in other examples, this access device can take the form of equipment such as a fob having an embedded radio frequency identification (RFID) chip. A sensor installed in the self-rent rental vehicle can detect the customer's mobile device (or a code stored by the RFID chip on a fob) and determine whether the customer is authorized to access the self-rent rental vehicle based on the sensed information. Examples of self-rent rental vehicles are those vehicles available through the WECAR® rental service, wherein WECAR® is a registered trademark of Enterprise Holdings, Inc. <FIG> depicts an exemplary system for a rental computer system <NUM> to communicate with a self-rent rental vehicle <NUM>. The self-rent rental vehicle <NUM> includes control hardware <NUM> that permits the customer to access the rental vehicle using an access device such as his/her mobile device <NUM>. Furthermore, the control hardware is configured to wirelessly receive data (e.g., via a wireless RF antenna or the like) communicated to it from a transmitter <NUM> (e.g., a wireless communications transmitter such as an RF antenna or the like). The rental computer system <NUM> can cause the transmitter <NUM> to broadcast authorization information <NUM> to the control hardware <NUM> on the self-rent rental vehicle <NUM>. The control hardware <NUM> would then store this authorization information for use when determining whether a customer is entitled to access the vehicle.

Rental vehicle service providers desire an ability to determine whether the customer who is to drive a rental vehicle is a licensed driver. That is, does the customer have a valid state driver's license? With conventional rental vehicle transactions, this assessment is made at a rental branch by personnel of a rental vehicle service provider. The customer is asked for his/her driver's license, and the employee of the rental vehicle service provider then makes an assessment as to whether he or she believes the license to be facially valid. However, it is desired for rental vehicle transactions involving self-rent rental vehicles to avoid any customer interaction with employees of a rental vehicle service provider. This raises the question of how to satisfy the desire for reviewing a customer's driver's license while permitting the customer to automate the rental vehicle pickup process. <FIG> depicts an exemplary process flow that provides a solution to this problem.

At step <NUM>, the rental computer system receives a message from the customer's mobile device <NUM> that includes image data representative of the customer's driver's license. A user can employ the camera feature of a mobile device <NUM> to generate such image data. The user can also load an image of the driver's license onto the mobile device if desired.

At step <NUM>, the rental computer system analyzes the driver's license image data to assess the validity of the driver's license. This operation may involve extracting text from the driver's license image data to obtain information such as the driver's name, address, and date of birth, the state of issuance for the driver's license, a driver's license number, date of expiration, etc. This operation may also involve extracting the patterns that appear in the image data to determine whether the extracted pattern conforms to the appearance of driver's licenses for a state (or for the state extracted from the license text if applicable). Suitable software from third party vendors that use image processing techniques to analyze the validity of driver's licenses can be used to perform step <NUM>.

If the extracted data from the driver's license fails to pass the conditions governing validity, then at step <NUM>, the rental computer system rejects the customer and sends a notification of the rejection to the customer's mobile device <NUM>. If the extracted data from the driver's license is deemed to pass the conditions governing validity, then at step <NUM>, the rental computer system updates a customer record for the customer to reflect that the customer is licensed to drive a motor vehicle. <FIG> illustrates an exemplary customer record data structure <NUM> for this purpose. The data structure <NUM> preferably includes data fields in association with each other such as a customer identifier field <NUM> (which can be a unique string for identifying the customer in the rental computer system), a customer name field <NUM>, a mobile device identifier field <NUM> (which can be for example a telephone number for the mobile device <NUM> or a unique identifier for the mobile device other than a telephone number), a driver's license identifier field <NUM> (which can be the extracted driver's license number), and a license validity flag field <NUM>. Based on the outcome of step <NUM>, field <NUM> can be set to indicate the customer as possessing a valid driver's license or not possessing a valid driver's license. The state of field <NUM> can then govern whether the customer is permitted to pick up a self-rent rental vehicle. It should be well understood that customer record <NUM> may include additional or different fields.

While the steps of <FIG> are described as being performed by the rental computer system, it should be understood that these steps or portions thereof could also be performed by some other third party computer system or by the mobile device <NUM> itself. In an example where a third party computer system performs the method steps (or at least step <NUM>), such third party computer system can then communicate the output of either steps <NUM> or <NUM> to the rental computer system so the rental computer system can update its database. In an example where the mobile device <NUM> performs the method steps (or at least step <NUM>), a mobile application resident on the mobile device can be configured to perform the steps with the output being communicated to the rental computer system.

Also, it should be understood that the customer record <NUM> can also include a field that identifies the extracted expiration date for the customer's driver's license. Logic can then be applied to either automatically change the validity flag field <NUM> when the current date falls after the expiration date or perform an expiration date check to assess validity when the customer later attempts to book a reservation or pick up a rental vehicle.

<FIG> depicts an exemplary process flow for creating a rental vehicle reservation for a self-rent rental vehicle in a manner that leverages automated driver's license assessments. At step <NUM>, the rental computer system receives a reservation request for the customer to rent a self-rent rental vehicle. This request can be received from the customer's mobile device, although that need not be the case (for example, the customer may make the request through a desktop computer via a website). The reservation request may include information such as the customer's name and address. If made via a mobile device, the request may include information such as the customer's name and a telephone number for the mobile device.

At step <NUM>, the rental computer system retrieves the customer record <NUM> for the customer identified in the reservation request and checks the license validity flag field <NUM> in the customer record <NUM>. If the license validity flag field <NUM> of the customer record indicates that the customer has already proven he or she is a validly licensed driver, then the process flow continues to step <NUM>. If the license validity flag field <NUM> of the customer record indicates that the customer has not proven he or she is a validly licensed driver, then the process flow continues to step <NUM>. At step <NUM>, the rental computer system prompts the customer to provide an image of his/her driver's license to check validity (for execution of the process flow in <FIG>). If this execution of the <FIG> process flow results in a determination the customer has a valid driver's license, then the process flow proceeds to step <NUM>. Otherwise, the rental computer system rejects the customer's reservation request and sends a notification of same to the customer (step <NUM>).

In the example of <FIG>, step <NUM> is reached after the rental computer system concludes that the customer has a valid driver's license. At step <NUM>, the rental computer system proceeds to check whether a rental vehicle in accordance with the reservation request is available. It should be understood that step <NUM> may involve several rounds of communication between the customer and the rental computer system to obtain all necessary information for a reservation.

If step <NUM> results in a determination by the rental computer system that a rental vehicle is not available as per the reservation request, then at step <NUM>, the rental computer system rejects the reservation request and notifies the customer re same.

If step <NUM> results in a determination by the rental computer system that a rental vehicle is available as per the reservation request, then at step <NUM>, the rental computer system creates a rental vehicle reservation for the customer and communicates authorization instructions for the reservation to the reserved rental vehicle to enable automated pickup by the customer. <FIG> depicts an exemplary data structure for a reservation record that can be created as a result of step <NUM>. The data structure <NUM> preferably includes data fields in association with each other such as a reservation identifier field <NUM> (which can be a unique string for identifying the particular rental vehicle reservation transaction), a rental vehicle identifier field <NUM> (which can be a unique string for identifying the particular rental vehicle), a customer identifier field <NUM> (which can be the unique string that identifies the customer for the reservation in the rental computer system), a start date/time field <NUM> (which can identify the date and time at which the rental vehicle becomes eligible for pickup by the customer), and an end date/time field <NUM> (which can identify the date/time that the reservation is scheduled to end). It should be understood that reservation records <NUM> can be joined with corresponding customer records via the customer identifier fields <NUM>/<NUM>. It should also be well understood that reservation record <NUM> may include additional or different fields. The rental computer system can communicate the reservation record data structure <NUM> as well as the corresponding customer record data structure <NUM> to the self-rent rental vehicle for local storage in control hardware <NUM>.

<FIG> depicts an exemplary system for control hardware <NUM> that can be deployed in a rental vehicle <NUM> to support self-rental capabilities. The hardware system <NUM> may comprise a processor <NUM> and associated memory <NUM> that cooperate with each other to execute the operations described herein.

The wireless I/O component <NUM> can be configured to communicate wirelessly and bidirectionally with the rental computer system <NUM>. For example, the processor <NUM> can receive the authorization information from the rental computer system <NUM> via wireless I/O <NUM> and store that authorization information in memory <NUM>.

The sensor <NUM> can be configured to sense the customer's mobile device <NUM> via techniques such as NFC, RFID, BlueTooth, or the like. The sensor <NUM> is preferably positioned in a location on the rental vehicle which permits the customer to conveniently position the mobile device <NUM> nearby.

Vehicle interfaces <NUM> permit the hardware system <NUM> to communicate with vehicle subsystems such as the vehicle's system for locking/unlocking doors, the vehicle immobilizer to de-immobilize the vehicle, and/or the vehicle's ignition system to start the vehicle.

<FIG> depicts an exemplary process flow for execution by system <NUM> to support self-rental capabilities. At step <NUM>, the sensor <NUM> senses the customer's mobile device <NUM>. The customer's mobile device <NUM> is configured to generate a signal sensible by sensor <NUM> where this signal contains information for uniquely identifying the mobile device <NUM>, the customer associated with the mobile device <NUM>, or a reservation for the customer associated with the mobile device <NUM> (for example, the same information that is present in fields <NUM> or <NUM> of the customer record <NUM> or field <NUM> of the reservation record <NUM>). As noted above, this sensible signal and sensor may employ communication techniques such as NFC, RFID, BlueTooth, or the like.

At step <NUM>, the processor checks the authorization record for the rental vehicle in memory <NUM> to assess whether the customer associated with the mobile device <NUM> is authorized to pick up the rental vehicle. As indicated, the authorization record can comprise the combination of reservation record <NUM> and the customer record <NUM> for the customer associated with the reservation. Thus, the processor <NUM> can compare the sensed information with the mobile device identifier or customer identifier in the authorization record. If there is match, the processor <NUM> can conclude that the person bearing the mobile device <NUM> near the rental vehicle is the same as the customer for the reservation. The processor may also perform further authorization checks such as comparing a current date/time with the start date/time field <NUM> of the authorization record to assess whether the rental vehicle pickup by the customer is timely.

If the processor <NUM> determines that all of the authorization conditions are met, then at step <NUM>, the system can provide the customer with access to the rental vehicle. At minimum, this may involve the processor <NUM> instructing the vehicle to unlock the doors (via vehicle interface <NUM>). In some examples, an ignition device (e.g., key or the like) may be left inside the vehicle for use by the customer once the customer gains access to the vehicle's interior (e.g., locating the ignition device in the glove box or locked compartment accessible via a code provided to the customer). In other examples, the system <NUM> may further instruct the vehicle to de-immobile the immobilizer and/or start the vehicle as described hereinafter. Next, at step <NUM>, the processor <NUM> logs the customer's vehicle access in memory <NUM>.

If the processor <NUM> determines that not all of the authorization conditions are met at step <NUM>, the system can then reject customer access to the vehicle at step <NUM>. This may involve leaving the vehicle doors locked and leaving the immobilizer in an immobilizing state.

<FIG> depicts exemplary process flows for execution by a mobile device and a rental computer system respectively to support mobility-based pickups of self-rental rental vehicles without requiring the customer to have his or her driver's license pre-approved. Thus, the process flows of <FIG> can support "walk-up" rentals of self-rent rental vehicles or rental vehicle pickups where the driver's license verification is performed at the time of pickup rather than at the time of reservation booking.

<FIG> depicts an exemplary process flow for execution by a mobile device <NUM> via mobile application <NUM>. At step <NUM>, the customer holds his/her driver's license in front of the mobile device's camera <NUM> and operates the mobile device to cause the camera to capture a photograph of the driver's license. The user can open the mobile application <NUM> where the mobile application <NUM> instructs the camera <NUM> to take the photograph in response to user input, or the user can capture the photograph outside the mobile application <NUM>, but then use the mobile application to subsequently export the photograph to the rental computer system <NUM>.

At step <NUM>, a similar procedure can be followed to capture a photograph of an identifier for the rental vehicle. For example, a bar code or QR code can be provided on the rental vehicle in a location easily photographed by the customer. The car identifier encoded by the bar code or QR code preferably matches the identifier used for the rental vehicle in field <NUM> of the reservation records <NUM>.

At step <NUM>, the processor then determines whether the two photographs are sufficiently close in time to be deemed a contemporaneous pair. For example, the customer can be required to take the two photographs within <NUM> seconds (or some other time limit) of each other. If not sufficiently close in time, the process flow can return to start. Otherwise, the process flow proceeds to step <NUM> where the mobile application instructs the mobile device to communicate the photographs to the rental computer system <NUM>.

<FIG> depicts the complementary process flow for execution by the rental computer system <NUM>. At step <NUM>, the rental computer system receives the photographs of the driver's license and car identifier from the mobile device <NUM>.

At step <NUM>, the rental computer system extracts relevant information from the driver's license image data to enable validity checking as previously described in connection with step <NUM> of <FIG>.

At step <NUM>, the rental computer system extracts the car identifier from the image data for the car identifier. This may involve processing a bar code or QR code image to convert such code to a character string.

At step <NUM>, the rental computer system analyzes the extracted driver's license data to assess validity (using techniques previously described in connection with step <NUM> of <FIG>). If the rental computer system concludes that the driver's license is invalid, then at step <NUM>, the rental computer system rejects the rental request by the customer and communicates this rejection to the customer's mobile device to notify re same. If the rental computer system concludes that the driver's license is valid, then the rental computer system proceeds to step <NUM>.

At step <NUM>, the rental computer system retrieves rental transaction data for the customer and/or rental vehicle. The rental computer system can retrieve all reservation records <NUM> that are keyed to the rental vehicle identified by the extracted car identifier (via field <NUM> of the reservation records).

In a true walk-up rental situation, there will not be a corresponding reservation record for the customer with respect to the rental vehicle. Thus, in the walk-up scenario, the rental computer system will check at step <NUM> for any retrieved rental vehicle reservation records <NUM> with respect to the rental vehicle that are deemed to overlap with the desired rental by the walk-up customer. If there is no deemed overlap, then at step <NUM>, the rental computer system will communicate rental authorization information to the rental vehicle identified by the extracted car identifier to permit access and pickup by the customer if the customer has otherwise agreed to all necessary terms and conditions for renting the rental vehicle. Thus, the customer would then be able to access the rental vehicle by placing his/her mobile device <NUM> near sensor <NUM> to initiate the process flow of <FIG>.

In a scenario where the customer had a pre-existing reservation, the rental computer system will check at step <NUM> for congruence between the retrieved rental vehicle reservation and the information from the customer's mobile device. For example, the rental computer system can check for matches between:.

The rental computer system at step <NUM> can also check for a match between the current time and the reservation start date/time field <NUM> of the retrieved reservation record <NUM>. The system can be configured to determine that a time match has occurred if the current time is within a specified tolerance of the time in the reservation start date/time field <NUM>. If the reservation is deemed supported by the extracted information, then the rental computer system can proceed to step <NUM> as noted above. Otherwise, the rental computer system can proceed to step <NUM> as noted above.

It should be understood that a wide number of variations on the process flows of <FIG> can be practiced. For example, rather than requiring that two photographs be taken, the user can be prompted to take a single photograph that includes both the driver's license and the car identifier. Toward this end, the car identifier can be provided on a location of the rental vehicle that is tailored to support proximal placement of the driver's license to permit easy photographing of the two. For example, a border shaped to accommodate expected sizes for a driver's license can be positioned next to the car identifier to facilitate this action. This would eliminate any need for step <NUM>. As another example, rather than step <NUM> involving capturing a photograph of the car identifier, step <NUM> can employ some other sensing technique to capture the car identifier. For example, RFID technology may be employed by which an RFID tag is present on the rental vehicle to uniquely identify the rental vehicle, and an RFID reader on the mobile device capture's the car identifier via RFID. In such an instance, the sensed RFID car identifier can then be communicated to the rental computer system for processing. As yet another example, the time proximity check of step <NUM> can be performed by the rental computer system rather than the mobile device. Still further, the time proximity check can be performed between a time for the car identifier capture and the current time rather than between the driver's license capture and the car identifier capture. As yet another example, as previously noted, the intelligence for analyzing driver's license validity can be deployed in the mobile application rather than the rental computer system <NUM> if desired by a practitioner.

Furthermore, while the preceding process flows and descriptions are tailored for the rental of self-rent rental vehicles, it should be understood that similar techniques can be used to streamline and improve the rent process for other types of rental vehicles with a reduced role for personnel of a rental car company. For example, a rental car company may choose to provide an automated key box or other kiosk arrangement at a location where rental vehicles can be picked up, and similar techniques can be employed to determine whether to provide a customer with access to a key for a rental vehicle from the automated key box or kiosk.

<FIG> depicts a process flow whereby a mobile device is used to support replacement rental vehicle reservations. <FIG> categorizes the operations into two general groups - activating replacement rental vehicle reservations and returning rental vehicles for replacement rental vehicle reservations. Within the activation group, <FIG> shows tasks for (<NUM>) notifications to drivers about the replacement rental vehicle reservations, (<NUM>) selection and verification of information by the drivers for the replacement rental vehicle reservations, (<NUM>) driver's license scanning for the replacement rental vehicle reservations, (<NUM>) rental vehicle entry by the driver for the replacement rental vehicle reservations, and (<NUM>) confirmation regarding same. Within the return group, <FIG> shows tasks for (<NUM>) notifications to drivers about the repair work being completed to the driver's ordinary vehicle, (<NUM>) selection and verification of return information by the drivers for the replacement rental vehicle reservations, (<NUM>) rental vehicle return by the driver for the replacement rental vehicle reservations, and (<NUM>) confirmation regarding completion of the replacement rental vehicle reservations.

<FIG> depicts an exemplary process flow for a rental computer system to support activation aspects of replacement rental vehicle reservations. With such an example, the driver will have a mobile application <NUM> resident on his/her mobile device <NUM> that is configured to support the operations described herein. If no such mobile application <NUM> is resident on the mobile device <NUM>, the driver can be prompted to download the appropriate mobile application <NUM> via the message discussed below with respect to step <NUM>. At step <NUM>, a replacement rental vehicle reservation for a driver is created and stored in the database <NUM>. This replacement rental vehicle reservation can be created in response to input from a business partner of a rental vehicle service provider (such as an insurance company). The business partner can use a system such as the automated reservation management computer system <NUM> to create such replacement rental vehicle reservation.

At step <NUM>, a message is sent to the driver's mobile device <NUM> to notify the driver that he/she has been authorized to pick up a replacement rental vehicle in accordance with the created replacement rental vehicle reservation. This notification can take the form of an email (see <FIG>) to an email address for the driver. However, it should be understood that the message can also take other forms such as a text message to the driver's mobile device. As shown in <FIG>, the message can include instructions prompting the driver to initiate an activation process for the created replacement rental vehicle reservation. The message can further include a user-selectable item (e.g., "Activate Priority Pass" button as shown in <FIG>) to start the activation process. Further still, the message can include an activation code for use by the driver as explained below. Thus, it should be understood that the reservation record data structure <NUM> that exists for the replacement rental vehicle reservation can also include a field that identifies the activation code associated with that replacement rental vehicle reservation. Moreover, it should be understood that the message could also include a selectable deep-link URL that includes the authorization code. It should further be understood that step <NUM> can be performed by the rental computer system or by a computer system associated with the business partner of the rental vehicle service provider who booked the replacement rental vehicle reservation (e.g., an insurance company).

Upon selection by the driver of the "Activate Priority Pass" button as shown in <FIG>, the mobile device <NUM> can navigate the driver to the mobile application's GUI screen of either <FIG> or <FIG>. <FIG> is a home screen of the mobile application <NUM>, and includes a user-selectable "Activate Priority Pass" button. <FIG> is a GUI screen of the mobile application <NUM> that is configured to solicit the activation code from the driver. If the landing page from the message of <FIG> is the home screen of <FIG>, the landing page from user-selection of the "Activate Priority Pass" button of <FIG> can be the GUI screen of <FIG>. Alternatively, the driver can also be provided with an ability to access the GUI screen of <FIG> starting from the home page (<FIG>) of the mobile application <NUM> rather than starting from the message shown in <FIG>. From the GUI screen of <FIG>, the driver can input the activation code for the replacement rental vehicle reservation, whereupon the mobile application <NUM> is configured to communicate this activation code to the rental computer system <NUM> to be checked for correctness (or the mobile application can be configured to check the correctness of the authorization code locally if the correct authorization code is provided to the mobile application for this purpose).

At step <NUM>, the rental computer system receives input from the driver's mobile device <NUM> that is indicative of a request to activate the replacement rental vehicle reservation. This input may take the form of the activation code entered via the GUI screen of <FIG>. Then, at step <NUM>, the rental computer system retrieves the record for the driver's replacement rental vehicle reservation from database <NUM> based on the received activation code. Next, at step <NUM>, the rental computer system communicates data about the retrieved replacement rental vehicle reservation to the driver's mobile device for populating various GUI screens of the mobile application <NUM>. For example, as shown in the GUI screen of <FIG>, this data may include details for the replacement rental vehicle reservation (e.g., repair information about the driver's ordinary vehicle undergoing repairs such as the name and address of the repair facility for such repairs, driver information (e.g., name, address, and telephone number), information about the replacement rental vehicle reservation, etc.). The GUI screen of <FIG> can also be configured to solicit a selection by the driver of a pickup mode for the reservation - for example, conventional pickup that involves human interaction or an automated rental vehicle pickup of a self-rent rental vehicle. In this example, we will presume the driver selects the automated pickup mode. Another exemplary GUI screen for this portion of the process is shown in <FIG> shows how the mobile application can be configured to solicit a selection by the driver of a rental vehicle for pickup from among a plurality of rental vehicles for pickup in accordance with the replacement rental vehicle reservation. The GUI screen can display rental vehicles by class and price. Furthermore, the rental computer system can be configured to restrict the choices presented to the driver to only those available rental vehicles whose class and/or price falls within a range authorized by the business partner for the replacement rental vehicle reservation. Alternatively, the rental computer system can be configured to list all available rental vehicles for selection but highlight those rental vehicles that fall within the authorization set by the business partner. In such an instance, should the driver select a rental vehicle outside the authorization, the driver can be notified and given an option to pay for the difference himself or herself.

At step <NUM>, the rental computer system receives selections from the driver's mobile device that were made with respect to the choice options that had been presented to the driver. These selections may comprise a particular rental vehicle (or particular group of rental vehicles such as a rental vehicle class) and a pickup mode (which as noted above will be an automated pickup mode for the purposes of this example). Next, at step <NUM>, the rental computer system communicates information about the driver's chosen selections to the mobile device for populating a verification GUI screen on the mobile device. <FIG> depicts an exemplary verification GUI screen in this regard.

If the driver verifies the information on the GUI screen of <FIG>, the mobile application can navigate the driver to the GUI screen of <FIG>. The GUI screen of <FIG> is configured to solicit payment information from the driver (e.g., for payment by credit card, debit card, PayPal, or the like). This payment information may be needed for the purposes of (<NUM>) paying for the replacement rental vehicle reservation or a portion thereof if the business partner has not picked up the full cost and/or (<NUM>) placing a hold on the driver's credit card should he or she keep the rental vehicle beyond the authorized time period. The GUI screen of <FIG> can be configured to solicit information such as a credit card type and credit card number (or a confirmation regarding same if the customer already has such information on file with the rental vehicle service provider). Further still, if the driver's mobile device is equipped with a scanner for a credit card (either integrated into the mobile device or as an attachment), the driver can swipe his/her credit card through the scanner rather than manually enter the credit card information. After receipt of the driver's payment information, the mobile device can communicate this payment information to the rental computer system. Then, at step <NUM>, the rental computer system can receive this payment information.

Another task is for the driver to provide proof that he/she has a valid driver's license. <FIG> depicts an exemplary GUI screen for display on the mobile device that is configured to begin the process of obtaining driver's license information from the driver. The GUI screen of <FIG> is configured to solicit an identification of the state for the driver's license. The mobile application then navigates the driver to the GUI screen of <FIG>. The GUI screen of <FIG> is configured to instruct the driver about how to scan his/her driver's license. A "Begin Scan" button or the like can be provided for user selection to enable the camera feature of the mobile device to capture a photograph of the driver's license. After capturing the photograph, the mobile application causes the mobile device to communicate the image data for the driver's license photograph of the driver's license and the state identification to the rental computer system. Next, at step <NUM>, the rental computer system receives this information for processing at step <NUM>.

Step <NUM> can involve the rental computer system processing the driver's license information as previously described in connection with <FIG>. Furthermore, step <NUM> can involve the rental computer system processing the payment information using conventional techniques. It should be understood that third party computer systems may also be employed to perform this processing and analysis with the results being reported to the rental computer system.

It should be understood that if the rental computer system already recognizes the driver as a validly licensed driver as described in connection with step <NUM> of <FIG> and the validity flag field <NUM> of customer record <NUM> of <FIG>, then the mobile application and rental computer system can interact in a manner that permits the driver to bypass the GUI screens of <FIG>.

In the event that the rental computer system determines that the driver's license and payment information are valid, then at step <NUM>, the rental computer system can activate the replacement rental vehicle reservation and update the reservation record <NUM> for the replacement rental vehicle reservation to reflect the activation. For example, an activation flag field in the reservation record <NUM> for the replacement rental vehicle reservation can be set to mark the reservation as activated. The rental computer system can also communicate this activation to the driver's mobile device for populating a GUI screen of the mobile application (see <FIG>). The driver will then be associated with an activated replacement rental vehicle reservation to make the driver eligible to pick up a self-rent rental vehicle using automated pickup techniques. Furthermore, this step can involve communicating data reflective of the activated replacement rental vehicle reservation to the driver's mobile device for local storage thereon.

<FIG> depicts an exemplary process flow for a mobile device to support accessing a self-rent rental vehicle in accordance with an activated replacement rental vehicle reservation. When the driver approaches the rental vehicle <NUM>, he/she can open the mobile application <NUM> and select the activate button (see <FIG>). To remind the driver to do this, the rental computer system or business partner computer system can communicate a reminder message to the driver's mobile device (see for example, the text message of <FIG>).

At step <NUM>, the mobile application <NUM> checks whether the replacement rental vehicle reservation has already been activated. This step may involve a communication with the rental computer system to gather this information, although this need not be the case if the mobile device locally stores data indicative of the replacement rental vehicle's activation. If the subject replacement rental vehicle reservation has not been activated, then at step <NUM>, the mobile application can enter the process flow beginning with <FIG> to begin an activation procedure. If the subject replacement rental vehicle reservation has been activated, then at step <NUM>, the mobile application causes the mobile device to display a GUI screen that instructs the user how to access the subject self-rent rental vehicle. An exemplary GUI screen for this purpose is shown at <FIG>. At step <NUM>, the mobile application instructs the mobile device to activate an output mechanism for communicating a unique identifier such as the customer identifier or mobile device identifier from the driver's customer record so that this information can be sensed by the sensor <NUM> located on the rental vehicle. As noted above, the output mechanism can employ data communication techniques such as NFC and BlueTooth. Also, if the data communication technique involves a persistent communication capability of the mobile device (e.g., an RFID tag or the like), then step <NUM> may not be needed as the RFID tag can be characterized as "always on".

This interaction can be accomplished in any of a number of ways. For example, the mobile application can prompt the user at step <NUM> to scan a car identifier such as a bar code or a QR code located on the rental vehicle to confirm that the subject rental vehicle is the rental vehicle corresponding to the activated replacement rental vehicle reservation. If the mobile device locally stores the reservation record <NUM> for the replacement rental vehicle reservation, this may involve comparing a scanned car identifier with the rental vehicle identifier field <NUM> of the reservation record <NUM>. If the two match, then the mobile application can perform step <NUM> (and unlocking is then contingent on the process flow shown in <FIG>). In another example, the mobile application can be configured to perform step <NUM> while the driver scans the car identifier on the rental vehicle, whereupon unlocking of the rental vehicle can be conditioned on both the unique identifier from the mobile device matching the authorization record for the rental vehicle (as per the <FIG> process flow) and a signal from the mobile device that the car identifier matches the rental vehicle identifier for the reservation record <NUM>. In still another example, the mobile application can be configured such that the driver need not scan the car identifier, and where unlocking of the rental vehicle merely follows the process flow described in connection with <FIG>. If the process flow of <FIG> operates to successfully confirm the driver as eligible to pick up the rental vehicle, then the control hardware <NUM> can signal the mobile device about this confirmation, whereupon the mobile device can signal the driver about same (e.g., the mobile application can cause the mobile device to beep or vibrate or change a display color). Thereupon, the mobile application can cause the mobile device to display the GUI screen of <FIG> which can be configured to provide further instructions regarding the rental vehicle. The driver would then be free to drive the rental vehicle away.

Also, optionally, telematics technology deployed on the rental vehicle can be configured to automatically detect information such as the rental vehicle's mileage and fuel level at the time of rental vehicle pickup. This information can be communicated from the rental vehicle to the rental computer system and/or mobile device for storage therein in association with the reservation record.

<FIG> depicts an exemplary process flow for a mobile device to support administering a return of the rental vehicle for the replacement rental vehicle reservation after pickup by the driver.

As discussed in the above-referenced and incorporated patents and patent applications, the automated reservation management computer system <NUM> can be configured to detect when repairs have been completed to the driver's ordinary vehicle. When such an event happens, the rental computer system or business partner computer system can send a message to the driver's mobile device notifying him or her of same (step <NUM>). <FIG> displays an exemplary email message for this purpose. As shown in <FIG>, this message can include a selectable option for the driver to begin the return process for the rental vehicle. The home screen of the mobile application <NUM> can also provide a selectable "return" option as shown in <FIG>. The message provided at step <NUM> can include a completion code for use by the driver to indicate he/she is initiating the return process. The rental computer system can be configured to maintain a field in the reservation record for the replacement rental vehicle reservation that stores a unique completion code for the reservation. Upon driver selection of the return button in the message or the home screen (see <FIG> and <FIG>), the mobile application can navigate the driver to the GUI screen of <FIG>, which is configured to solicit from the driver the completion code. Upon entry of the completion code, the mobile device can communicate the completion code to the rental computer system to indicate the driver's intent to return the rental vehicle.

At step <NUM>, the rental computer system receives this completion code from the mobile device, and then retrieves the reservation record for the replacement rental vehicle reservation based on the received completion code (step <NUM>). At step <NUM>, the rental computer system communicates pre-return information about the replacement rental vehicle reservation to the mobile device for display thereon.

The GUI screen of <FIG> depicts an example of how the mobile application can display such pre-return information. The GUI screen of <FIG> is also configured to solicit from the driver: (<NUM>) a vehicle return mode (e.g., an automated vehicle return or a conventional rental vehicle return at a rental vehicle branch location), and (<NUM>) a date and time for the vehicle return. Upon receipt of this information from the driver, the mobile application can ask the driver to verify the provided pre-return information (see <FIG>). Upon user verification, the mobile application can cause the mobile device to communicate the selected vehicle return mode and selected vehicle return date/time to the rental computer system.

At step <NUM>, the rental computer system receives this pre-return information from the mobile device, and the rental computer system then stores this information in database <NUM>, preferably appending the pre-return information to the reservation record <NUM> for the replacement rental vehicle reservation. The rental computer system can also communicate a confirmation of its receipt of the pre-return information to the mobile device for display thereon (see <FIG>). This confirmation GUI screen can be configured to instruct the driver further regarding the rental vehicle return process.

<FIG> depicts an exemplary process flow for a mobile device to support the final portion of the return process for the rental vehicle. The driver can open the mobile application on the return date and select the return button to initiate this process flow. At step <NUM>, the mobile application detects that the driver has selected the return button. At step <NUM>, the mobile application checks whether the driver has already provided pre-return information for the replacement rental vehicle reservation. If he/she has not, the mobile application can enter the screen flow beginning with the example of <FIG>. Otherwise, the mobile application can check whether the current date matches the scheduled return date from the pre-return information (step <NUM>). If not, the mobile application can notify the driver about this discrepancy and ask the driver if he/she is returning the rental vehicle early (step <NUM>). If the driver responds that he/she does not want to return the rental vehicle early, the process flow can terminate. However, if the driver responds that he/she wishes to continue with the vehicle return, then the process flow can proceed to step <NUM>. Also, if step <NUM> detects that the driver is returning the vehicle late, the mobile application can proceed to step <NUM>.

At step <NUM>, the mobile application causes the mobile device to display a GUI screen, where this GUI screen is configured to present the driver with return status information (see <FIG> for an example of such a GUI screen). Optionally, telematics technology deployed on the rental vehicle can be configured to automatically detect information such as the rental vehicle's mileage and fuel level at the time of return. This information can be communicated to the rental computer system and/or mobile device for association with the reservation record. The GUI screen of <FIG> can thus be able to present to the driver a display of how many miles were driven and how the current fuel level of the rental vehicle compares with the fuel level at the time of pickup.

The GUI screen also be configured to solicit input from the driver to indicate whether the rental vehicle has experienced any noticeable damage during the rental. If the mobile application receives input from the driver indicative of no such damage at step <NUM>, then the process flow can proceed to step <NUM>. If the mobile application receives input from the driver indicative of the existence of such damage at step <NUM>, then the process flow can proceed to step <NUM>. At step <NUM>, the mobile application can cause the mobile device to display one or more GUI screens that are configured to solicit details regarding such damage.

At step <NUM>, the mobile application then causes the mobile device to communicate information to the rental computer system regarding completion of the replacement rental vehicle reservation. In turn, the rental computer system can update its database so that the reservation record for the replacement rental vehicle reservation has its status changed to "closed" or the like. Furthermore, any damage items noted at step <NUM> and communicated at step <NUM> can be stored in association with the reservation record. A practitioner may also choose to design the mobile application so that a user can capture images of any vehicle damage to be uploaded to the rental system for storage in association with a record for the rental. Upon completion of the replacement rental vehicle reservation, the rental computer system can also communicate an update to the control hardware <NUM> of the subject rental vehicle to update its authorization record to remove authorization for the driver with respect to the now closed replacement rental vehicle reservation. In this fashion, the driver can be prevented from re-entering the vehicle after return. Another task for the rental computer system upon completion can be sending an electronic receipt for the rental transaction to the mobile device and/or an email address associated with the driver. <FIG> depicts an exemplary GUI screen that can be displayed on the mobile device to inform the driver of this completion.

Thus, it can be seen that <FIG> describe various aspects whereby mobile devices and self-rental rental vehicle can be employed to streamline the replacement rental vehicle reservation process.

<FIG> and <FIG> depict a process flow whereby a mobile device is used to support rental vehicle reservations of self-rent rental vehicles through a rental program offered by a rental vehicle service provider. An exemplary rental program can be the WECAR rental service discussed above. Basic tasks for this, as shown in <FIG>, can include:.

<FIG> depicts an exemplary process flow for Stages <NUM> and <NUM> above, with <FIG> providing larger views of the features from <FIG>. <FIG> provides an exemplary process flow for execution by the mobile application to perform Stage <NUM> above. <FIG> provides an exemplary process flow for execution by the rental computer system to perform Stage <NUM> above.

The mobile application <NUM> for the rental service can be downloaded by a customer at Stage <NUM> in response to any of a number of access paths. For example, the customer may visit a website associated with the rental service and download the mobile application from there. As another example, the customer may receive an email invitation or the like with a selectable link for downloading the mobile application. As yet another example, the mobile application can be downloaded from an "app store" or the like that is accessible via the mobile device. To complete initial registration, the rental computer system can email or a text a message to the customer that provides a unique code, QR code, or URL link, that is selectable by the customer to complete his/her registration as shown in <FIG>.

Also, to become enrolled with the rental program, the rental computer system can obtain information about the customer (e.g., name, address, contact information, etc.) for populating a customer record <NUM>. Such information, can, in part, be obtained from the customer prior to downloading the mobile application. Or, all of such information can be obtained from the customer via the mobile application. For example, at step <NUM>, the mobile application can cause one or more GUI screens to be displayed on the mobile device to solicit customer information. At step <NUM>, the mobile application receives the enrollment customer information. At step <NUM>, the mobile application checks whether all necessary customer enrollment information has been received. If no, it continues to request more information from the customer. If yes, the mobile application proceeds to step <NUM>.

At step <NUM>, the mobile application displays one or more GUI screens that guide the customer through a driver's license scanning operation (see <FIG>). Upon receipt of a photograph of the customer's driver's license (step <NUM>), the mobile application communicates the enrollment information and the driver's license photograph to the rental computer system (step <NUM>). At step <NUM>, the mobile application receives a responsive communication from the rental computer system. If the rental computer system provides a responsive communication that the customer's enrollment information is complete and driver's license is deemed valid, then the customer is notified of successful enrollment (see <FIG>) and the process flow ends. If the rental computer system provides a responsive communication that the customer's enrollment information is incomplete and/or driver's license is deemed invalid, then the customer is notified of an enrollment denial, and the customer will need to begin again in order to enroll (or at least at the stage of the process where faulty information was provided).

<FIG> depicts the process flow from the perspective of the rental computer system. At step <NUM>, the rental computer system receives the customer's enrollment information and driver's license image. At step <NUM>, the rental computer system determines whether a complete set of customer enrollment data has been provided and also analyzes the driver's license image to assess the validity of the driver's license. This step can be performed as described previously in connection with step <NUM> of <FIG>. If the enrollment data is complete and the driver's license is deemed valid, then at step <NUM>, the rental computer system can create the customer record <NUM>, such record including a unique customer identifier field and driver's license validity flag field, etc. as previously discussed. The rental computer system can also communicate a notification to the customer's mobile device that enrollment was successful. If the enrollment data is incomplete and/or the driver's license is deemed invalid, then at step <NUM>, the rental computer system can deny the customer's enrollment request and communicate a message to the customer's mobile device re same.

<FIG> depicts an exemplary process flow for Stage <NUM> above, with <FIG> providing larger views of the features from <FIG>. During stage <NUM>, the mobile application can cause the customer's mobile device to display various GUI screens that are configured to solicit reservation information from the customer. Exemplary items of reservation information can include: pickup location, return location, vehicle information (if a range of vehicle options are available for a given pickup location), pickup date/time, and return date/time. The mobile application can be configured to communicate with the rental computer system to determine availabilities and book a rental vehicle reservation for the customer if possible. Upon completion of this process, the rental computer system can create a reservation record <NUM> for the customer in association with the customer's customer record <NUM>. A confirmation of the reservation can be displayed on the customer's mobile device via the mobile application (see <FIG>).

<FIG> depicts an exemplary process flow for Stages <NUM> and <NUM> above, with <FIG> providing larger views of the features from <FIG>. <FIG> shows Stage <NUM> in larger form, while <FIG> shows Stage <NUM> in larger form.

The process flow of <FIG> begins when the customer arrives at the reserved rental vehicle. While near the rental vehicle, the customer opens the mobile application, and selects a "Start Reservation" button or the like. The mobile application then causes the mobile device to display a GUI screen that prompts the customer to (<NUM>) capture a photograph of the customer's driver's license, and (<NUM>) scan a scanable car identifier on the rental vehicle (e.g., a bar code or QR code on the vehicle). This information can then be communicated to the rental computer system for analysis, similar to what is shown in <FIG>. If the rental computer system determines that the customer is authorized to pick up the rental vehicle in accordance with the reservation, then the rental computer system communicates with the control hardware <NUM> of the rental vehicle to cause its doors to unlock and provide the customer with access to the rental vehicle.

It should be understood that a practitioner may choose to implement Stage <NUM> in different ways. For example, a practitioner may choose to design the rental pickup process so that the customer need not re-submit a driver's license photograph at the time of pick up if the customer record <NUM> for the customer in the database <NUM> already shows the customer as a validly licensed driver. In such a case, the customer would need to only scan the car identifier and communicate the scanner car identifier from his/her mobile device to identify himself/herself to the rental computer system. It should be understood that the communication from the mobile device to the rental computer system can include information for uniquely identifying the customer or customer's mobile device.

As another example, the verification process can be performed locally by the control hardware of the rental vehicle rather than by the rental computer system. Upon creation of the reservation, the rental computer system can be configured to communicate an authorization record to the control hardware <NUM> of the reserved rental vehicle that is a combination of fields from the reservation <NUM> and the customer record <NUM> for the customer associated with the reservation. This authorization record can be stored locally by the rental vehicle for use when verifying the customer during pickup (see <FIG>). If the practitioner wishes to verify the customer's driver's license at time of pickup, the process flow can still require the customer to scan his/her driver's license, such analysis to be performed by the rental computer system (or by the control hardware or mobile application if appropriately configured).

The process flow of <FIG> begins when the customer selects an "End Reservation" option from the mobile application. The mobile application can be configured to provide the customer with this option if it detects that the customer is currently using a rental vehicle for the reservation. The customer can select this button when he/she parks the rental vehicle to return it. The return location can be at a designated return location or a user-selected location within a geographical area of acceptable return locations, if the rental program supports such returns. Upon selection of the "End Reservation" option, the mobile application can prompt the customer for a confirmation that he/she will be ending the reservation. If the customer confirms the return, the mobile application can communicate a return instruction to the rental computer system to end the reservation, whereupon the rental computer system can instruct the rental vehicle to no longer provide the customer with access to the rental vehicle. The rental computer system can also update its reservation record in the database to reflect the closing of the reservation.

Another feature that can be supported by mobile devices to facilitate the rental process can be a feature whereby customers are able to select particular rental vehicles from among a plurality of rental vehicles for their reservation via their mobile devices. In an example useful for understanding the invention, this selection process can be performed within a defined time period immediately before the customer arrives at a rental location to pick up a reserved rental vehicle.

<FIG> depicts an exemplary process flow for execution by the rental computer system to present a mobile device with a plurality of specific rental vehicles for selection with respect to picking up a rental vehicle in accordance with a reservation. At step <NUM>, the rental computer system receives input from the customer's mobile device that the customer will soon be picking up a rental vehicle for his/her reservation. This input can be received in response to any of a number of techniques. For example, the process flow can require the customer to open the mobile application to send a message to the rental computer system regarding such notification. <FIG> illustrates an exemplary GUI screen through a mobile application for this purpose (see the "Choose From Virtual Aisle" button; see also <FIG> which shows an exemplary landing GUI screen after user-selection of the "Choose from Virtual Aisle" button). Or, if GPS-tracking is enabled on the mobile device, the mobile application can be configured to automatically prompt the customer as to whether he/she will soon be picking up his/her reserved rental vehicle in response to detecting that the customer's mobile device is within X miles of the reserved pickup location (e.g., <NUM> miles).

Then, at step <NUM>, the rental computer system communicates the rental vehicle pickup options to the mobile device for populating a GUI screen presented through the mobile application. For example, if the customer has reserved a "full-size" rental vehicle and there are <NUM> available "full-size" rental vehicles at the pickup location, the rental computer system can communicate data regarding these <NUM> available "full-size" rental vehicles to the customer's mobile device. The mobile application can then cause the mobile device to display one or more GUI screens (see <FIG>) that are configured to permit the customer to scroll through and select a rental vehicle from among these options. <FIG> shows an exemplary GUI screen for a user to confirm the selection of a particular rental vehicle from among the presented choices.

Upon customer selection of a presented option, the mobile application can communicate this selection to the rental computer system. Upon receipt of the selection (step <NUM>), the rental computer system can re-check the selected rental vehicle's availability (step <NUM>). This step may be necessary to accommodate for a situation where multiple customers are choosing from among pools of vehicles that include the selected vehicle at the same time. That is, while the customer was choosing from among the options, another customer may have rendered an option unavailable. If step <NUM> results in a determination that the selected rental vehicle is no longer available, the rental computer system can proceed to step <NUM> to send a notification about the unavailability to the customer's mobile device and return to step <NUM>. If step <NUM> results in a determination that the selected rental vehicle is still available, the rental computer system can proceed to step <NUM>.

At step <NUM>, the rental computer system places a time-limited hold on the selected rental vehicle in favor of the customer. This action prevents another customer from selecting that rental vehicle for pickup during a specified time period (e.g., <NUM> minutes). The rental computer system can then communicate a confirmation of this hold to the customer's mobile device for display to the customer (see <FIG> and <FIG> for examples of GUI screens for this purpose). Upon confirmation of the selection by the customer, the rental computer system can start a countdown with respect to the pickup time clock. If the system is configured such that the rental computer system communicates an authorization record to reserved rental vehicles, the rental computer system can provide the selected rental vehicle with an authorization record that includes a combination of fields from the reservation record <NUM> and customer record <NUM> for the customer. Furthermore, <FIG> shows an example of a GUI screen that can serve as a machine-readable identifier for establishing that the customer is entitled to pick up the selected rental vehicle during the hold period. For example, the identifier can be a barcode or the like. Thus, for rental locations or rental vehicles that support automated self-rentals, the customer can place the identifier shown by the GUI screen of <FIG> in proximity to a reader to gain access to the selected rental vehicle (presuming the customer does so within the hold period). Upon accessing the selected rental vehicle within the hold period, the rental vehicle communicates a signal to the rental computer system to identify the rental vehicle as picked up. Similarly, in an example where automated self-rental is not supported, this operation can be performed by an employee of the rental car company who makes such a notation in a data entry terminal.

Next, at step <NUM>, the rental computer system checks whether it has received a pickup notification for the selected rental vehicle within the pickup time window. As noted above, this notification can take the form of a message from the selected rental vehicle that the customer has accessed or requested access to the selected rental vehicle (e.g., by placing his/her mobile device near the vehicle sensor <NUM>). If the pickup time window expires before receiving such a notification, the rental computer system at step <NUM> can communicate a message to the customer's mobile device informing the customer about the expiration, remove the hold on the selected rental vehicle in the database, and return the customer to a vehicle selection process (see <FIG> and <FIG> for examples of GUI screens that can be configured to communicate such expiration to the customer). However, once again, if the notification is received within the pickup time window, then at step <NUM>, the rental computer system can update database <NUM> including the reservation record <NUM> for that reservation to reflect the pickup.

Thus, the operation of the <FIG> process flow (in coordination with the exemplary GUI screens of <FIG>) can permit a customer to select a particular rental vehicle from among multiple rental vehicle options via the mobile application prior to arriving at the pickup location. As discussed, it is preferred that the time-limited hold be defined such that the customer has a relatively short window in which to a pick up the particularly selected rental vehicle. In this fashion, it is expected that a rental car company will be able to more reliably present a wide range of options for rental vehicle selection. However, it should be understood that alternative implementations are possible. For example, some practitioners may choose to vary the length of the hold period for customers based on a tier level or other status level assigned to customers. Thus, customers who are members of a frequent renter program can be provided with the ability to hold a particular rental vehicle for a longer time than non-members (e.g., <NUM> hour holds for members of a frequent renter club and <NUM> minute holds for non-members). Further still, some practitioners may choose to make some club members of a rental car company not subject to any time-limited holds while non-members would be. As another example, a rental car company might choose to vary the hold requirements by rental vehicle type (e.g., where reservations for higher end vehicle classes will have longer hold periods than reservations for lower end vehicle classes). As still another example, a rental car company might choose to vary the hold requirements by the expected duration of the reservation transaction (e.g., a reservation where the renter is expected to keep the rental vehicle for <NUM> weeks would have a longer hold period than a reservation where the renter is expected to keep the rental vehicle for <NUM> days).

Also, other techniques can be used to permit a customer to select any rental vehicle for pickup from a class of reserved rental vehicles in accordance with a rental vehicle reservation. In one example, the customer can be free to place his/her mobile device near the sensor <NUM> of any rental vehicle he/she chooses. If the chosen vehicle is within the class of rental vehicle defined for the reservation, then the rental computer system can permit customer access for pickup.

As another example in instances where the rental computer system communicates authorization records to the rental vehicles, a process flow such as the one in <FIG> can be employed. At step <NUM>, the rental computer system updates the authorization records for a plurality of rental vehicles that are available to the customer in accordance with the rental vehicle reservation (e.g., broadcasting the authorization record to all available "full-size" rental vehicles if the reservation is for the "full-size" rental class) to thereby make all such rental vehicles eligible for customer selection. The customer will thus be authorized to access any of those rental vehicles. When the customer places his/her mobile device near the sensor of one of these vehicles, the so-selected rental vehicle can communicate this selection to the rental computer system. Upon receipt of such notification at step <NUM>, the rental computer system can proceed to step <NUM> whereupon it updates the authorization records for the non-selected rental vehicles that had been eligible for selection to remove the customer from their authorization records.

<FIG>depict process flows for an example useful for understanding the invention where control mechanisms are put in place to prevent a customer from quickly picking up multiple eligible rental vehicles by placing his/her mobile device near the sensors of multiple eligible rental vehicles in quick succession. The process flow of <FIG> for execution by the control hardware of a rental vehicle is similar to that of <FIG>, but adds steps <NUM>-<NUM> where it checks the rental computer system before providing the customer with access. Thus, if the locally stored authorization record for the rental vehicle shows that the customer is authorized to pick up the rental vehicle, then at step <NUM>, the control hardware communicates the access request for the customer to the rental computer system, and awaits permission from the rental computer system at step <NUM> before providing the customer with access. <FIG> illustrates the complementary process flow for execution by the rental computer system. This process flow is similar to that of <FIG>, but adds a step (step <NUM>) to check the database <NUM> to make sure the customer does not reflect the customer has already accessed another rental vehicle for pickup in connection with the reservation. If the database shows that the customer has already picked up a rental vehicle for the reservation, an access denial is communicated to the rental vehicle (step <NUM>). If the database check is clear, then at step <NUM>, the rental computer system updates the database to reflect the pickup before communicating access permission to the selected rental vehicle (step <NUM>).

Also, it should be understood that one of more of the GUI screens presented to a customer during the vehicle selection process can be configured to solicit from the customer input as to whether the customer would like to upgrade their vehicle selection. For example, if the customer had previously reserved an economy class rental vehicle, but at the time of pickup, the customer is desirous of renting a larger vehicle (such as a full-size class rental vehicle), one or more of the GUI screens presented to the customer can be configured to ask the customer whether he or she would like to change the vehicle class for the transaction. Depending on availability, in response to customer input indicative of a desire to upgrade, the system can identify available rental vehicles at the rental location at the higher class and provide the customer with the ability to select a particular one of those vehicles as described above. Further still, in response to a customer request to upgrade, updated pricing information for the upgrade can be presented to the customer through the GUI screens, and the customer can be prompted to provide input as to whether he or she agrees to any new terms and conditions regarding such upgraded rental (e.g., a new rental rate, etc.).

Furthermore, while the example of <FIG> is shown as operating in connection with a mobile application, it should be understood that such GUI screens can also be accessible by customers from a website.

<FIG> depicts an exemplary embodiment for a system that permits a customer to use a machine-sensible item such as a mobile device as a smart key for starting a rental vehicle. Smart keys are now well-known devices for gaining access to and starting motor vehicles. With a conventional smart key, a fob carried by a driver is sensed by a receiver in the vehicle to permit the driver to start the vehicle without placing an actual key in an ignition slot. Instead, to start most smart key-enabled vehicles, the driver needs to simply press a "start" button on the driver's console while also pressing the brake with his/her foot (and while the smart key is in proximity to the vehicle). An administrative hassle for rental car companies with respect to rental operations lies in the distribution of keys, whether actual ignition keys or smart key fobs, to renters for the rental vehicles. <FIG> describes an embodiment whereby a smart key emulator <NUM> is installed inside the vehicle, where this smart key emulator is remotely activated, thereby alleviating the need to deliver an ignition key or smart key fob to a renter.

Equipment <NUM> such as control hardware <NUM> can be installed in the rental vehicle. This equipment can include a sensor <NUM>, a wireless communication interface <NUM>, authorization logic <NUM>, and a smart key emulator <NUM>. The sensor <NUM>, wireless communication interface <NUM>, and authorization logic <NUM> can operate as described in connection with <FIG> and other examples previously described herein. A remote authorization center <NUM> such as rental computer system can communicate authorization instructions to the rental vehicle via the wireless interface <NUM>. These authorization instructions can be stored in a memory by the equipment <NUM> to serve as an authorization reference for access by the authorization logic executed by a processor within the vehicle. Then, when a customer places his/her machine-sensible item <NUM> near the sensor <NUM> as previously described, the sensor <NUM> can communicate sensed data indicative of the customer to the authorization logic <NUM>, and the authorization logic <NUM> can compare the sensed information with the authorization reference. If there is a match, the authorization logic can communicate an enable signal to the smart key emulator <NUM>.

The smart key emulator <NUM> can be configured to emulate a conventional smart key upon enablement. Thus, the enabled smart key emulator can communicate with the vehicle's (<NUM>) door lock/unlock system <NUM> to lock and unlock the vehicle doors, (<NUM>) immobilizer <NUM> to de-immobilize the vehicle, and (<NUM>) ignition system <NUM> to permit the de-immobilized vehicle to be started. Thus, by only enabling the smart key emulator <NUM> to output the appropriate codes for the vehicle in response to the customer being recognized as the customer who has reserved the rental vehicle as reflected in the authorization records for the rental vehicle, the customer will be able to use his/her proximate item <NUM> as if it were a smart key to gain access to the vehicle and enable start/stop of the vehicle's engine using methods previously described herein. Furthermore, it should be understood that the smart key emulator <NUM> or other components of the equipment <NUM> can also be configured to communicate with the vehicle's data bus via a physical connection to the OBDII or CAN bus port for purposes of data collection (and subsequent communication of the collected data back to the rental system <NUM>). Examples of data to be collected in this fashion can include vehicle location, vehicle identification number (VIN), fuel levels, mileage/odometer readings, etc..

In a preferred embodiment, the machine-sensible item <NUM> is a customer's mobile device <NUM> (such as a smart phone). However, it should be noted that the machine-sensible <NUM> could take other forms, such as an RFID tag or the like.

It should also be understood that a practitioner can choose to make the enable signal a simple "yes/no" binary signal, or alternatively a more complicated signal to reduce the opportunity for theft in the event a criminal attempts to steal the vehicle by breaking in and "hotwiring" a "yes" signal onto the communication link between the authorization logic and the smart key emulator <NUM>. For example, rather than a "yes/no" binary signal, the enable signal can take the form of a multi-bit code. Still further, the enable signal can be an encrypted signal communicated between the authorization logic <NUM> and smart key emulator <NUM> that changes over time as is used on many remote access computer systems. Thus, upon concluding that the customer is authorized to access and start the rental vehicle, the authorization logic <NUM> can be configured to communicate an encrypted "yes/enable" signal to the smart key emulator <NUM>. The smart key emulator <NUM> can then be configured to decrypt the received encrypted signal and condition the enablement on the decryption revealing that the authorization logic provided a "yes/enable" instruction. As noted, the encryption can be configured to change over time to minimize the risk of hacking.

Also, a protective enclosure can be provided around the authorization logic and smart key emulator to reduce the opportunity for a criminal to access the communication link for hotwiring purposes. For example, they can be deployed together in an integrated circuit.

It should also be understood that equipment <NUM> can be an aftermarket addition to a rental vehicle or it can be part of the original equipment from the manufacturer of the rental vehicle. <FIG> depicts an exemplary embodiment where the equipment <NUM> is aftermarket equipment. Through antennae <NUM> and <NUM> (which may include the antenna <NUM> of a cellular carrier), the rental vehicle is able to communicate with the remote rental system <NUM> as well as a remote aftermarket gateway service <NUM> (via network <NUM>). The aftermarket gateway service <NUM> can communicate instructions to the rental vehicle and receive data such as telematics data (e.g., mileage, fuel levels, etc.) from the rental vehicle. Thus, the rental system <NUM> can either be configured to communicate instructions to the rental vehicle directly or indirectly via the aftermarket gateway service <NUM>. The aftermarket authorization logic <NUM> can perform the authorization check on data sensed by sensor <NUM> (which can be an NFC sensor for sensing an NFC signal generated by item <NUM>) using authorization reference data from the rental system <NUM>. If the sensed data is deemed authorized, then the smart key emulator <NUM> is configured to generate a signal for enabling vehicle ignition. The OEM system <NUM> of the rental vehicle can include an OBDII/CAN port <NUM> through which the authorization logic accesses the rental vehicle to instruct components such as controller <NUM> (e.g., an engine CPU), door lock/unlock system <NUM>, immobilizer <NUM>, and security system <NUM> to enable/disable operation as appropriate.

<FIG> depicts an exemplary embodiment where the equipment <NUM> is included within the OEM system <NUM> of the rental vehicle. In such an arrangement, a OEM controller <NUM> can include the authorization logic <NUM> and smart key emulator <NUM>. Such a controller <NUM> can be a modified OEM telematics controller or the like (such as for OnStar or BlueLink systems). Further still, such OEM system <NUM> can be configured to communicate with a remote embedded OEM backend service <NUM> for the OEM telematics technology, to play effectively the same role in the process as can the aftermarket gateway service <NUM> for the exemplary embodiment of <FIG>.

<FIG> depicts an exemplary embodiment of a system employing a smart key emulator in operation. The equipment <NUM> resident in the vehicle includes a virtual key that functions as the smart key emulator along with a door lock interface <NUM>, door unlock interface <NUM>, trunk release interface <NUM>, panic button interface <NUM>, and any other interfaces <NUM> that are desired. An antenna can communicate a signal from the virtual key <NUM> to a key presence sensor <NUM> in the vehicle to emulate the presence of a smart key near the vehicle. If a smart key is detected by the sensor <NUM>, the sensor <NUM> can notify the vehicle immobilizer <NUM> as well as the locking/trunk system <NUM>, body control unit (BCU) <NUM>, and immobilizer <NUM> that the vehicle can be placed in condition for operation. This signal from the virtual key can be communicated as a low power, low frequency signal. An antenna can also communicate signals from the various interfaces to the vehicle's lock/unlock, trunk, and other systems <NUM> to effectuate a desired action. Thus, a mobile application or the like can be configured to also present buttons for selection by a user to lock/unlock doors, open the trunk, actuate the panic system, etc. The equipment <NUM> can also include a sensor <NUM> as previously described. However, this need not be the case if alternate techniques are used to verify the physical presence of the customer near the vehicle. According to the invention, the customer is using a position tracking-enabled mobile device (e.g., a mobile device with GPS capabilities) and the remote rental system compares the detected physical location of the customer with the detected physical location of the rental vehicle to assess their proximity.

Claim 1:
A method comprising:
receiving a request at a remote rental system (<NUM>, <NUM>) from a position tracking-enabled mobile device (<NUM>, <NUM>) of a user to use a vehicle (<NUM>), the request created by a mobile application (<NUM>) on the position tracking-enabled mobile device and comprising a request by the user to use the vehicle at the time of the request;
in response to the received request, the remote rental system (i) determining that the user is authorized to use the vehicle, (ii) wirelessly communicating a cellular command to wake up equipment (<NUM>) installed in the vehicle if the user is authorized, wherein the equipment obtains a GPS position for the vehicle from a GPS system (<NUM>) of the equipment, (iii) receiving the GPS position for the vehicle to determine a physical location for the vehicle, (iv) determining a physical location of the position tracking-enabled mobile device, and (v) verifying a physical presence of the user near the vehicle based a comparison between the determined physical location for the position tracking-enabled mobile device and the determined physical location for the vehicle; and
in response to the user authorization determining step and the verifying step, the remote rental system wirelessly communicating with the woken-up equipment to cause the woken-up equipment to provide an enable signal to a smart key emulator (<NUM>) included in the equipment, wherein the enabled smart key emulator emulates a smart key for the vehicle by wirelessly communicating with a smart key presence sensor (<NUM>) resident in the vehicle to (i) emulate a presence of a smart key in proximity to the smart key presence sensor and (ii) permit the user to keylessly start the vehicle without requiring the user to possess a smart key for the vehicle.