WO2016000014A1

WO2016000014A1 - A method and system for vehicle rental

Info

Publication number: WO2016000014A1
Application number: PCT/AU2015/000321
Authority: WO
Inventors: Laurent Jean Bernard GABORIT
Original assignee: Oneblip Pty Ltd
Priority date: 2014-06-30
Filing date: 2015-05-29
Publication date: 2016-01-07

Abstract

The present invention relates generally to the automotive and security industries and, in particular, to rental of vehicles. One embodiment of the present invention provides a system for vehicle rental. The system comprises a vehicle including a tag, a door and a controller module. The tag has an encrypted identifier associated with the vehicle. The controller is coupled to a lock of the door of the vehicle. The system also comprises a server, a wireless communications network, and a mobile device. The mobile device is capable of reading the identifier, communicating with the server regarding renting of the vehicle, and receiving authorization data from the server. The mobile device then, in response to receiving the authorization data from the server, wirelessly transmits the read identifier to the controller module, which actuates the lock if the received identifier is the identifier associated with the vehicle.

Description

A METHOD AND SYSTEM FOR VEHICLE RENTAL

Technical Field

[0001] The present invention relates generally to the automotive and security industries and, in particular, to rental of vehicles. The present invention also relates to a method and system for renting of vehicles, and to a computer program product including a computer readable medium having recorded thereon a computer program for the rental of vehicles.

Background

[0002] In a conventional vehicle rental system, each vehicle is equipped with a reader module which is wirelessly connected to a server to allow the server to track the position of the vehicle. When a registered user wants to rent the vehicle, the user swipes (or places) a smart card over the reader module, and the reader module wirelessly communicates with the server to confirm that the user is allowed to rent the vehicle. The doors of the vehicle are then unlocked to allow the user access to the vehicle's key, which is stored in a compartment inside the vehicle, if the user is allowed to rent the vehicle.

[0003] In the conventional system, the vehicle rental system must be supported by a wireless communication system. Typically, a vehicle rental company pays a fee to use an existing wireless communication system or maintains its own wireless communication system to enable the server to communicate with the rental vehicles. The use of such a wireless communication system increases the expenses incurred by the vehicle rental company.

[0004] Thus, a need exists to provide a car rental method and system that does not require vehicle rental companies to maintain its own wireless communication system to communicate with the rental vehicles.

Summary

[0005] It is an object of the present invention to substantially overcome, or at least ameliorate, one or more disadvantages of existing arrangements. [0006] Disclosed are arrangements which seek to address disadvantages associated with existing arrangements by providing a vehicle rental method and system that does not require a wireless connection between rental vehicles and a remote server.

[0007] According to a first aspect of the present disclosure, there is provided a method for execution by a wireless mobile device for allowing access to a rental vehicle, the method comprising: reading, by the mobile device, an identifier associated with a vehicle, the identifier being encrypted and located on a tag in proximity of the vehicle; communicating, by the mobile device, with a server regarding renting of the vehicle; receiving, by the mobile device, authorization data from the server; in response to receiving the authorization data from the server, wirelessly transmitting, by the mobile device, the read identifier to a controller module located in the vehicle, the controller module being coupled to a lock of a door of the vehicle, wherein the controller module actuates the lock if the received identifier is the identifier associated with the vehicle.

[0008] According to a second aspect of the present disclosure, there is provided a system for vehicle rental, the system comprising: a vehicle having a tag, a door and a controller module, the tag having an identifier which is encrypted and associated with the vehicle and being located on the vehicle, and the controller being coupled to a lock of the door of the vehicle, a server; a wireless communications network; and a mobile device configured to: read the identifier; communicate with the server regarding renting of the vehicle; receive authorization data from the server; in response to receiving the authorization data from the server, wirelessly transmit the read identifier to the controller module, wherein the controller module actuates the lock if the received identifier is the identifier associated with the vehicle.

[0009] According to another aspect of the present disclosure, there is provided a computer program product including a computer readable medium having recorded thereon a computer program for implementing any one of the methods described above.

[0010] Other aspects of the invention are also di sclosed. Brief Description of the Drawings

[001 1] At least one embodiment of the present invention will now be described with reference to the drawings, in which:

[0012] Fig. 1 shows a block diagram of a vehicle rental system according to an aspect of the present disclosure;

[0013] Figs. 2A and 2B collectively form a schematic block diagram representation of an electronic device with which described arrangements described herein can be practised;

[0014] Fig. 3 is a flow diagram of a method for execution by a mobile device for renting a vehicle;

[0015] Fig. 4 is a flow diagram of a method for execution by a controller module of a rental vehicle; and

[0016] Fig. 5 is a flow diagram of a method for execution by a mobile device to cease rental of a vehicle.

Detailed Description

[0017] Where reference is made in any one or more of the accompanying drawings to steps and/or features, which have the same reference numerals, those steps and/or features have for the purposes of this description the same function(s) or operation(s), unless the contrary intention appears.

[0018] It is to be noted that the discussions contained in the "Background" section relate to discussions of a system which form public knowledge through their respective publication and/or use. Such should not be interpreted as a representation by the present inventor or the patent applicant that such a system in any way forms part of the common general knowledge in the art.

[0019] Fig. 1 shows a block diagram of a vehicle rental system 100. The vehicle rental system 100 includes mobile devices 1 1 OA, ... , 11 ON, a server 120, vehicles 130A, ... , 130N, and a wireless communications network 140. The mobile devices 1 10A, 1 ION are collectively referred to hereinafter as the mobile device 1 10. The vehicles 130A, 130N are collectively referred to hereinafter as the vehicles 130. The description hereinafter relates to a situation where the mobile device 1 10A communicates with the vehicle 130A to rent the vehicle 130A. However, the reference numerals 1 10 and 130 have been used to indicate the methods 300, 400, and 500 are executable by any one of the mobile devices 110 and vehicles 130

[0020] Each of the vehicles 130 includes doors 132, a controller module 134, and a tag 136. The doors 132 located on the vehicle 130 include locks to lock and unlock the doors 132, which prevent access to the cabin of the vehicle 130 when the doors 132 are locked. The term doors 132 is used hereinafter for consistency, but the terms "gates", "hatch", "portals" and the like are equally applicable. The controller module 134 is an embedded electronic device for controlling access to the vehicle 130 by actuating (i.e., locking and unlocking) the locks of the doors 132. The tag 136 is fixed to the vehicle 130 and has an encrypted identifier associated with the vehicle 130. The encrypted identifier on the tag 136 may be, for example, any one of a two-dimensional barcode (e.g., a quick response (QR) code), a barcode, a Radio Frequency Identification (RFID) and the like. The encrypted identifier includes details of the vehicle 130 associated with the encrypted identifier. The controller module 134 uses the encrypted identifier to actuate the lock of the doors 132, the method of which will be described hereinafter with reference to Figs. 3 to 5 of the accompanying drawings.

[0021 ] The mobile device 1 10 may be, for example, a mobile phone (e.g., an iPhone^1M, a Samsung Galaxy™, etc.) or a tablet (e.g., iPad^1M, Samsung Galaxy^{I M}, etc.) or the like that is capable of reading the encrypted identifier. The mobile device 1 10 is used to scan the encrypted identifier if the encrypted identifier is of a barcode type, or contactlessly communicate with the encrypted identifier if the encrypted identifier is of a RFID type.

[0022] The mobile device 1 10 is also capable of wirelessly communicating with the controller module 134 via a wireless communication system, such as Bluetooth^{1 M} type local

interconnection, Wi-Fi (including protocols based on the standards of the IEEE 802.1 1 family), Infrared Data Association (IrDa) and the like. Preferably, the mobile device 1 10 employs the Bluetooth^IM low energy (also known as Bluetooth^IM LE or Bluetooth^{1 M} Smart), which is a low power Bluetooth^IM standard, to wirelessly communicate with the controller module 134. [0023] The mobile device 1 10 also wirelessly communicates with the server 120 via the wireless communications network 140. The wireless communications network 140 enables communications between the mobile device 1 10 and the server 120 and may, for example, comprise a mobile communications network using Long Term Evolution (LTE) 4G standards, 3G standards, or the like. The wireless communications network 140 may alternatively comprise a fixed cable communications network with Wi-Fi hotspots, or the like. By using the mobile device 1 10 to communicate with the server 120, the controller module 134 of the vehicle 130 is advantageously not required to maintain communications with the server 120.

[0024] In order to unlock the doors 132, the mobile device 1 10, using a software application module executed by the mobile device 1 10, reads the encrypted identifier from the tag 136 and transmits the encrypted identifier to the controller module 134. The controller module 134 then verifies that the encrypted identifier matches with the identifier stored in the controller module 134. If the identifiers match, the controller module 134 sends a control signal to one or more of the locks of the doors 132 to unlock at least one of the doors 132. Otherwise, if the identifiers do not match, the doors 132 remain locked.

[0025] The server 120 manages the rental vehicle system 100 by tracking the rental of vehicles 130 by users of the mobile devices 1 10. The server 120 however does not communicate with the controller module 134 of the vehicle 130.

Embedded Electronic Device Description

[0026] Figs. 2A and 2B collectively form a schematic block diagram of an embedded electronic device, which can be used to implement either or both of the mobile device 1 10 and the controller module 134, including embedded components, upon which the methods 300, 400, and 500 described hereinafter are desirably practiced. The electronic device 1 10 may be, for example, a mobile phone or a tablet (e.g., iPad^1M, Samsung Galaxy^{I M}, etc.), in which processing resources are limited. The electronic device 134, on the other hand, may be an embedded processor in which processing resources are limited. Further, any one of the embedded components described with reference to Figs. 2 A and 2B may be omitted in the electronic device 1 10, 134. Nevertheless, the methods 300, 400, and 500 to be described may also be performed on higher-level devices such as desktop computers, server computers, and other such devices with significantly larger processing resources. [0027] As seen in Fig. 2A, the electronic device 1 10 or 134 comprises an embedded

controller 202. Accordingly, the electronic device 1 10 or 134 may be referred to as an

"embedded device." In the present example, the controller 202 has a processing unit (or processor) 205 which is bi-directionally coupled to an internal storage module 209. The storage module 209 may be formed from non-volatile semiconductor read only memory (ROM) 260 and semiconductor random access memory (RAM) 270, as seen in Fig. 2B. The RAM 270 may be volatile, non-volatile or a combination of volatile and non-volatile memory.

[0028] The electronic device 1 10 or 134 includes a display controller 207, which is connected to a video display 214, such as a liquid crystal display (LCD) panel or the like. The display controller 207 is configured for displaying graphical images on the video display 214 in accordance with instructions received from the embedded controller 202, to which the display controller 207 is connected.

[0029] The electronic device 1 10 or 134 also includes user input devices 213 which are typically formed by keys, a keypad or like controls. In some implementations, the user input devices 213 may include a touch sensitive panel physically associated with the display 214 to collectively form a touch-screen. Such a touch-screen may thus operate as one form of graphical user interface (GUI) as opposed to a prompt or menu driven GUI typically used with keypad- display combinations. Other forms of user input devices may also be used, such as a microphone (not illustrated) for voice commands or a joystick/thumb wheel (not illustrated) for ease of navigation about menus.

[0030] As seen in Fig. 2A, the electronic device 1 10 or 134 also comprises a portable memory interface 206, which is coupled to the processor 205 via a connection 219. The portable memory interface 206 allows a complementary portable memory device 225 to be coupled to the electronic device 110 or 134 to act as a source or destination of data or to supplement the internal storage module 209. Examples of such interfaces permit coupling with portable memory devices such as Universal Serial Bus (USB) memory devices, Secure Digital (SD) cards, Personal Computer Memory Card International Association (PCMIA) cards, optical disks and magnetic disks.

[0031 ] The electronic device 1 10 or 134 also has a communications interface 208 to permit coupling of the device 1 10 or 134 to a computer or communications network 140 via a connection 221. The connection 221 may be wired or wireless. For example, the connection 221 may be radio frequency or optical. An example of a wired connection includes

TV!

Ethernet. Further, an example of wireless connection includes Bluetooth ¹ type local interconnection, Wi-Fi (including protocols based on the standards of the IEEE 802.1 1 family), Infrared Data Association (IrDa) and the like.

[0032] Typically, the electronic device 1 10 or 134 is configured to perform some special function. The embedded controller 202, possibly in conjunction with further special function components 210, is provided to perform that special function. For example, for the device 1 10, the components 210 may represent a lens, focus control and image sensor of the mobile device. In another example, the components 210 may represent the locks of the doors 132. The special function components 210 are connected to the embedded controller 202. As another example, the device 110 may be a mobile telephone handset. In this instance, the components 210 may represent those components required for communications in a cellular telephone environment. For the mobile device 1 10, the special function components 210 may represent a number of encoders and decoders of a type including Joint Photographic Experts Group (JPEG), (Moving Picture Experts Group) MPEG, MPEG-1 Audio Layer 3 (MP3), and the like.

[0033] The methods described hereinafter may be implemented using the embedded controller 202, where the processes of Figs. 3 to 5 may be implemented as one or more software application programs 233 executable within the embedded controller 202. The electronic device 1 10 of Fig. 2A implements the described methods 300 and 500. The electronic device 134 of Fig. 2A implements the described method 400. In particular, with reference to Fig. 2B, the steps of the described methods 300, 400, 500 are effected by instructions in the software 233 that are carried out within the controller 202. The software instructions may be formed as one or more code modules, each for performing one or more particular tasks. The software may also be divided into two separate parts, in which a first part and the corresponding code modules performs the described methods and a second part and the corresponding code modules manage a user interface between the first part and the user.

[0034] The software 233 of the embedded controller 202 is typically stored in the non-volatile ROM 260 of the internal storage module 209. The software 233 stored in the ROM 260 can be updated when required from a computer readable medium. The software 233 can be loaded into and executed by the processor 205. In some instances, the processor 205 may execute software instructions that are located in RAM 270. Software instructions may be loaded into the

RAM 270 by the processor 205 initiating a copy of one or more code modules from ROM 260 into RAM 270. Alternatively, the software instructions of one or more code modules may be pre- installed in a non-volatile region of RAM 270 by a manufacturer. After one or more code modules have been located in RAM 270, the processor 205 may execute software instructions of the one or more code modules.

[0035] The application program 233 is typically pre-installed and stored in the ROM 260 by a manufacturer, prior to distribution of the electronic device 1 10 or 134. However, in some instances, the application programs 233 may be supplied to the user encoded on one or more CD- ROM (not shown) and read via the portable memory interface 206 of Fig. 2A prior to storage in the internal storage module 209 or in the portable memory 225. In another alternative, the software application program 233 may be read by the processor 205 from the network 140, or loaded into the controller 202 or the portable storage medium 225 from other computer readable media. Computer readable storage media refers to any non-transitory tangible storage medium that participates in providing instructions and/or data to the controller 202 for execution and/or processing. Examples of such storage media include floppy disks, magnetic tape, CD-ROM, a hard disk drive, a ROM or integrated circuit, USB memory, a magneto-optical disk, flash memory, or a computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external of the device 201. Examples of transitory or non-tangible computer readable transmission media that may also participate in the provision of software, application programs, instructions and/or data to the device 201 include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on

Websites and the like. A computer readable medium having such software or computer program recorded on it is a computer program product.

[0036] The second part of the application programs 233 and the corresponding code modules mentioned above may be executed to implement one or more graphical user interfaces (GUIs) to be rendered or otherwise represented upon the display 214 of Fig. 2A. Through manipulation of the user input device 213 (e.g., the keypad), a user of the device 201 and the application programs 233 may manipulate the interface in a functionally adaptable manner to provide controlling commands and/or input to the applications associated with the GUI(s). Other forms of functionally adaptable user interfaces may also be implemented, such as an audio interface utilizing speech prompts output via loudspeakers (not illustrated) and user voice commands input via the microphone (not illustrated).

[0037] Fig. 2B illustrates in detail the embedded controller 202 having the processor 205 for executing the application programs 233 and the internal storage 209. The internal storage 209 comprises read only memory (ROM) 260 and random access memory (RAM) 270. The processor 205 is able to execute the application programs 233 stored in one or both of the connected memories 260 and 270. When the electronic device 1 10 or 134 is initially powered up, a system program resident in the ROM 260 is executed. The application program 233 permanently stored in the ROM 260 is sometimes referred to as "firmware". Execution of the firmware by the processor 205 may fulfil various functions, including processor management, memory management, device management, storage management and user interface.

[0038] The processor 205 typically includes a number of functional modules including a control unit (CU) 251, an arithmetic logic unit (ALU) 252 and a local or internal memory comprising a set of registers 254 which typically contain atomic data elements 256, 257, along with internal buffer or cache memory 255. One or more internal buses 259 interconnect these functional modules. The processor 205 typically also has one or more interfaces 258 for communicating with external devices via system bus 281 , using a connection 261.

[0039] The application program 233 includes a sequence of instructions 262 though 263 that may include conditional branch and loop instructions. The program 233 may also include data, which is used in execution of the program 233. This data may be stored as part of the instruction or in a separate location 264 within the ROM 260 or RAM 270.

[0040] In general, the processor 205 is given a set of instructions, which are executed therein. This set of instructions may be organised into blocks, which perform specific tasks or handle specific events that occur in the electronic device 1 10 or 134. Typically, the application program 233 waits for events and subsequently executes the block of code associated with that event. Events may be triggered in response to input from a user, via the user input devices 213 of Fig. 2 A, as detected by the processor 205. Events may also be triggered in response to other sensors and interfaces in the electronic device 1 10 or 134. [0041 ] The execution of a set of the instructions may require numeric variables to be read and modified. Such numeric variables are stored in the RAM 270. The disclosed method uses input variables 271 that are stored in known locations 272, 273 in the memory 270. The input variables 271 are processed to produce output variables 277 that are stored in known

locations 278, 279 in the memory 270. Intermediate variables 274 may be stored in additional memory locations in locations 275, 276 of the memory 270. Alternatively, some intermediate variables may only exist in the registers 254 of the processor 205.

[0042] The execution of a sequence of instructions is achieved in the processor 205 by repeated application of a fetch-execute cycle. The control unit 251 of the processor 205 maintains a register called the program counter, which contains the address in ROM 260 or RAM 270 of the next instruction to be executed. At the start of the fetch execute cycle, the contents of the memory address indexed by the program counter is loaded into the control unit 251. The instruction thus loaded controls the subsequent operation of the processor 205, causing for example, data to be loaded from ROM memory 260 into processor registers 254, the contents of a register to be arithmetically combined with the contents of another register, the contents of a register to be written to the location stored in another register and so on. At the end of the fetch execute cycle the program counter is updated to point to the next instruction in the system program code. Depending on the instruction just executed this may involve incrementing the address contained in the program counter or loading the program counter with a new address in order to achieve a branch operation.

[0043] Each step or sub-process in the processes of the methods described below is associated with one or more segments of the application program 233, and is performed by repeated execution of a fetch-execute cycle in the processor 205 or similar programmatic operation of other independent processor blocks in the electronic device 1 10 or 134.

[0044] The mobile device 1 10 has a rental application program that manages the rental of the vehicle 130 on the mobile device 110. The rental application program is executed by the processor 205 of the mobile device 1 10 and runs method 300 and 500, which will be described hereinafter.

[0045] When the rental application program is launched on the mobile device 1 10, the rental application program shows on the display 214 of the mobile device 1 10 a user interface showing at least two choices of either renting a vehicle 130 or ceasing to rent the vehicle 130. If a user of the mobile device 1 10 selects the rent a vehicle option, a method 300 for renting the vehicle 130 is executed. On the other hand, if the user of the mobile device 1 10 selects the cease renting of the vehicle 130, a method 500 for ceasing rental of the vehicle 130 is executed.

[0046] The controller module 134 has a vehicle application program that manages the actuating of the locks of the doors 132. When the controller module 134 receives data from the mobile device 1 10, the vehicle application program is executed by the processor 205 of the controller module 134 and runs method 400, which will be described hereinafter.

[0047] Fig. 3 shows a flow diagram of a method 300, which may be executed by the processor 205 of the mobile device 1 10 for renting the vehicle 130. The method 300 starts with step 305 where the display 214 of the mobile device 1 10 shows locations of vehicles 130. The display 214 may display a map with a first dot indicating the location of the mobile device 110 and second dot(s) indicating location(s) of vehicle(s) 130 that are close to the mobile device 1 10. The mobile device 110 may, for example, display locations of vehicles 130 that are within 1 km of the mobile device 1 10. The user of the mobile device 1 10 then physically proceeds to one of the shown locations. Upon arriving at the location, the user selects a button on the display 214, thereby indicating that the user has arrived at the location of the vehicle 130. For example, the button may be associated with the second dots so that the button is selected by tapping on one of the second dots. In another example, the button may be a rent vehicle button displayed on the display 214, which the user can select.

[0048] In an alternative rental implementation, the user of the mobile device 1 10 may reserve rental of the vehicle 130 through a website of the rental vehicle system 100 before coming to the vehicle 130. In this implementation, the user accesses the website associated with the vehicle rental system 100 and reserves a vehicle 130 that is available to rent.

[0049] Upon reserving the rental of the vehicle 130, the website then displays the rental terms and conditions to the user, similar to step 330 described hereinafter. If the user declines the rental terms and conditions, then the rental of the vehicle 130 is terminated. If the user accepts the rental terms and conditions, then the website enables the server 120 to transmit authorization data enabling the mobile device 1 10 to access the rented vehicle 130. The mobile device 1 10 receives such authorization data from the server 120 via the wireless communication network 140 or the like.

[0050] In the alternati ve implementation, the display 214 of the mobile device 1 10 shows the location of the reserved vehicle 130 in step 305. For example, the display 214 shows a map with a first dot indicating the location of the mobile device 1 10 and a second dot indicating the location of the reserved vehicle 130. Upon arriving at the location of the reserved vehicle 130, the user selects a button on the display 214 indicating that the user has arrived at the location of the vehicle 130. For example, the button may be associated with the second dot so that the button is selected by tapping on the second dot. In another example, the button may be a rent vehicle button displayed on the display 214, which is selectable by the user. The method 300 then advances to step 310.

[0051 ] In step 310, the encrypted identifier of the tag 136 is read. When the user selects the rent vehicle option in step 305, the mobile device 1 10 activates the reader of the mobile device 110 depending on the encrypted identifier of the tag 136. In one implementation, the tag 136 on each vehicle 130 in the system 100 may be different. The mobile device 1 10 therefore offers a list of selections that the user can select depending on the type of tag 136 that is fixed on the vehicle 130. In another implementation, all of the vehicles 130 use the same type of tag 136 and the mobile device 1 10 immediately activates a reader suitable for the tag 136, without prompting the user to select a reader type.

[0052] If the encrypted identifier is a two-dimensional barcode, the mobile device 1 10 activates a camera of the mobile device 1 10 and displays the view of the camera and a button to capture the encrypted identifier on the display 214. The user then activates the button to capture the encrypted identifier. The mobile device 1 10 then displays on the display 214 that the encrypted identifier of the vehicle 130 has been successfully retrieved.

[0053] If the encrypted identifier is a RFID, the mobile device 1 10 activates a Near Field Communication device and displays, on the display 214, an instruction to the user to place the mobile device 110 close to the tag 136. When the user places the mobile device 110 close to the tag 136, the mobile device 1 10 contactlessly communicates with the tag 136 to retrieve the encrypted identifier. The mobile device 1 10 then displays on the display 214 that the encrypted identifier of the vehicle 130 has been successfully retrieved. The method 300 then proceeds to step 320.

[0054] The mobile device 1 10 transmits the received, encrypted identifier to the server 120, in step 320. The transmission of the encrypted identifier from the mobile device 1 10 to the server 120 is via the wireless communications network 140. The server 120 then checks the availability of the vehicle 130 and transmits the details of the availability of the vehicle 130 to the mobile device 1 10. The method 300 proceeds to step 330.

[0055] In step 330, the mobile device 1 10 determines whether the vehicle 130 is available. This step is performed when the mobile device 1 10 receives the data relating to the availability of the vehicle 130 from the server 120. If the vehicle 130 is not available (NO), the method 300 concludes and the mobile device 1 10 displays on the display 214 that the vehicle 130 is not available for rental. If the vehicle 130 is available (YES), the method 300 continues to step 340.

[0056] The mobile device 1 10, in step 340, determines whether the user of the mobile device 1 10 agrees with the rental terms and conditions. The mobile device 110 displays the rental terms and conditions on the display 214 and presents two choices to the user: to accept or to decline the rental terms and conditions. If the user selects the decline option (NO), the method 300 concludes and the mobile device 1 10 displays on the display 214 that the rental of the vehicle 130 is terminated. If the user selects the accept option (YES), the method 300 continues to step 342.

[0057] In step 342, the mobile device 110 transmits the user acceptance of the rental terms and conditions to the server 120. The mobile device 1 10 transmits data indicating the user acceptance of the rental terms and conditions to the server 120. The method 300 then proceeds to step 344.

[0058] In step 344, the mobile device 1 10 receives authorization data from the server 120. When the server 120 receives the user acceptance of the rental terms and conditions, as described with reference to step 342 hereinbefore, the server 120 transmits authorization data to the mobile device 1 10 to enable the mobile device 1 10 to access the rented vehicle 130. The method 300 then proceeds to step 350 [0059] n the alternative implementation where the vehicle 130 is reserved by the user through the website of the system 100, the transmission of the encrypted identifier and the check performed by the server 120 (as described in steps 320 and 330 above) are not required by the mobile device 1 10. Step 340 is also skipped when performing the method 300, as the user has previously agreed to the rental terms and conditions when reserving the vehicle 130. Further, steps 342 and 344 are skipped as the mobile device 110 has previously received authorization data from the server 120, as described in paragraph [0051] hereinbefore. Thus, in the alternative implementation, the method 300 proceeds from step 310 to step 350.

[0060] In step 350, the mobile device 1 10 transmits rental information, the encrypted identifier, and an identification of the mobile device 1 10 to the controller module 134. This step is performed in response to the mobile device 1 10 receiving the authorization data from the server 120. The rental information includes data indicating whether the communication is for renting or for ceasing renting of the vehicle 130. In this case, the rental information data indicates that the communication transmission to the controller module 134 is for renting the vehicle 130. The identification of the mobile device 1 10 may be a serial number or any other unique identification of the mobile device 1 10. Before the mobile device 1 10 transmits the data to the controller module 134, the mobile device 1 10 first establishes wireless communication with the controller module 134 by, for example, enabling, pairing and establishing a Bluetooth™ connection with the controller module 134. The method 300 then continues to step 360.

[0061 ] Upon receipt of the data from the mobile device 1 10, the controller module 134 performs the method 400, as executed by the vehicle application program contained in the controller module 134.

[0062] Fig. 4 shows a method 400, which may be executed by the processor 205 for the controller module 134 to actuate the locks of the doors 132. The method 400 commences at step 410 when the controller module 134 receives the rental information, the encrypted identifier, and the mobile device identification as described in step 350 hereinbefore or step 520 hereinafter. The method 400 proceeds to step 415.

[0063] In step 415, the controller module 134 determines the purpose of the communication by the mobile device 1 10 through the rental information data. If the controller module 134 determines that the communication is to rent the vehicle 130 (COMMENCE RENTAL), then method 400 proceeds to step 420. Otherwise (CEASE RENTAL), the method 400 continues to step 430.

[0064] The rental information, which is sent in step 350 of the method 300 by the mobile device 1 10 to the controller module 134 includes the data that the communication sent the mobile device 1 10 is for renting the vehicle 130. Thus, the method 400 proceeds to step 420 when receiving rental information data from the method 300.

[0065] In step 420, the mobile data identification is stored in a memory 260 of the controller module 134. The stored mobile data identification indicates that the mobile device 1 10 is currently associated with the renting of the vehicle 130. As will be discussed hereinafter in relation to the method 500 for ceasing rental of the vehicle 130, the stored mobile data identification is used by the controller module 134 to determine whether ceasing of rental of the vehicle 130 by a mobile device 1 10 is allowed. The method 400 then proceeds to step 422.

[0066] The controller module 134 decrypts the received, encrypted identifier in step 422. The decrypted identifier includes unique data relating to the vehicle 130. The controller module 134 has counterpart data, stored in the memory 260 of the controller module 134, which

complements the unique data. The method 400 then proceeds to step 424.

[0067] In step 424, the controller module 134 determines whether the decrypted identifier is valid. The controller module 134 determines whether the decrypted identifier is valid by comparing the unique data in the decrypted identifier with the stored counterpart data in the controller module 134. If the decrypted identifier is not valid (i.e., the decrypted identifier does not match the stored counterpart data) (NO), the method 400 ends and the controller module 134 transmits information to the mobile device 1 10 that the identifier is not valid. In turn, the mobile device 1 10 in step 360 proceeds to end the method 300, as described below. If the decrypted identifier is valid (i.e., the decrypted identifier matches the stored counterpart data) (YES), the method 400 proceeds to step 426.

[0068] The controller module 134 unlocks the door(s) 132 of the vehicle 130 in step 426. The controller module 134 transmits a control signal to the central locking system of the vehicle 130 to allow at least one of the doors 132 to be opened. The method 400 then proceeds to step 428. [0069] The controller module 134 transmits a valid identifier confirmation to the mobile device 1 10 in step 428. The method 400 ends at the conclusion of step 428.

[0070] Steps 430 to 436 of the method 400 will be described hereinafter with reference to the method 500 of Fig. 5.

[0071 ] In step 360, the mobile device 110 waits for a valid identifier confirmation. Upon receipt of data from the controller module 134, the mobile device 110 determines whether a valid identifier confirmation is received from the controller module 134. If the mobile device 1 10 determines that a valid identifier confirmation is not received from the controller module 134 (NO), the method 300 concludes and the mobile device 1 10 displays on the display 214 that there is an error in verifying the data and the vehicle 130 is unable to be unlocked. If the mobile device 1 10 determines that a valid identifier confirmation is received from the controller module 134 (YES), the method 300 proceeds to step 370.

[0072] The mobile device 1 10 transmits rental information of the vehicle 130 to the server 120, in step 370. In this step, the server 120 updates its records to reflect that the vehicle 130 is now being rented by the user of the mobile device 1 10. In the alternative implementation where the vehicle 130 is reserved through the website of the system 100, the server 120 updates its records automatically from the reservation through the website, without having to confirm with the mobile device 1 10. The alternative implementation therefore allows step 370 to be skipped. The method 300 concludes at the end of step 370, or at the end of step 360 for the alternative implementation.

[0073] The alternative implementation thus enables the method 300 to be performed by the mobile device 100 without having to establish communication with the server 120.

[0074] Fig. 5 shows a flow diagram of a method 500 for ceasing rental of the vehicle 130. The method 500 is executed when the user of the mobile device 1 10 selects an option to cease rental of the vehicle 130, as described in paragraph [0047] hereinbefore. The method 500 begins in step 510 where the encrypted identifier of the tag 136 is read. As described with reference to step 310 above, the mobile device 1 10 activates a reader depending on the encrypted identifier. However, for simplicity sake, only the two-dimensional barcode implementation is described here, but the encrypted identifier may be an y one of the examples described in paragraph [0022] hereinbefore. The mobile device 1 10 activates a camera of the mobile device 1 10 and displays the view of the camera and a button to capture the encrypted two-dimensional barcode on the display 214. The user then activates the button to capture the two-dimensional barcode. The mobile device 1 10 in turn displays on the display 214 that the two-dimensional barcode of the vehicle 130 has been obtained. The method 500 then proceeds to step 520.

[0075] In step 520, the mobile device 110 transmits rental information, the encrypted identifier, and an identification of the mobile device 1 10 to the controller module 134. The rental information includes data indicating whether the communication is for renting or for ceasing renting of the vehicle 130. In this case, the rental information data indicates that the

communication transmission to the controller module 134 is for ceasing rental of the vehicle 130. The identification of the mobile device 1 10 is as described hereinbefore in paragraph [0060]. Before the mobile device 1 10 transmits the data to the controller module 134, the mobile device 1 10 first establishes wireless communication with the controller module 134 by, for example, enabling, pairing and establishing a Bluetooth™ connection with the controller module 134. The method 500 then proceeds to step 530.

[0076] When the controller module 134 receives the data from the mobile device 1 10, the controller module 134 performs the method 400, as executed by the vehicle application program resident in the controller module 134. Steps 410 and 415 of the method 400 are as described above in paragraphs [0062] and [0063].

[0077] As the rental information in this case indicates that the communication from the mobile device 110 is to cease rental of the vehicle 130, the method 400 proceeds to step 430. The controller module 134 decrypts the encrypted identifier in step 430. As described in paragraph [0066] hereinbefore, the decrypted identifier includes a unique data relating to the vehicle 130 and the controller module 134 has a counterpart data, stored in the memory 260 of the controller module 134, which complements the unique data. The controller module 134 therefore extracts the unique data relating to the vehicle 130. The method 400 proceeds to step 432.

[0078] The controller module 134 determines whether the decrypted identifier and the mobile device identification is valid, in step 432. As described with reference to step 420 of the method 400, the mobile device identification is stored in the memory 260 of the controller module 134. Therefore, in step 432, the controller module 134 determines whether the unique data and the mobile device identification received from the mobile device 110 matches with the counterpart data and the mobile device identification, respectively, as stored in the controller module 134. If any one of the decrypted identifier and the mobile device identification does not match (NO), the method 400 ends and the controller module 134 transmits information to the mobile device 1 10 that one of the decrypted identifier and the mobile device identification is not valid. On the other hand, if the decrypted identifier and the mobile device identification are valid (YES), the method 400 continues to step 434.

[0079] The controller module 134 transmits a valid identifier confirmation to the mobile device 1 10 in step 434. The method 400 proceeds to step 436, in which the controller module 134 locks the doors 132. The method 400 then ends at the conclusion of step 436.

[0080] In step 530 of the method 500, the mobile device 1 10 receives data from the controller module 134 and determines whether the mobile device 1 10 receives a valid identifier

confirmation from the controller module 134. If the mobile device 1 10 determines that a valid confirmation is not received (NO), the method 500 concludes and the mobile device 1 10 displays on the display 214 that there i s an error in verifying the data and the ceasing of rental of the vehicle 130 is not possible. The mobile device 1 10 also informs the user to re-attempt the process of ceasing rental of the vehicle 130. If the mobile device 1 10 determines that a valid confinnation is received (YES), the method 500 continues step 540.

[0081] The mobile device 1 10 transmits cease rental information of the vehicle 130 to the server 120, in step 540. In this step, the server 120 updates its records to reflect that the vehicle 130 is no longer rented by the user of the mobile device 1 10. The method 500 concludes at the end of step 540.

[0082] controller module 134controller module 134controller module 134controller module 134controller module 134controller module 134controller module 134

Industrial Applicability

[0083] The arrangements described are applicable to the automobile and security industries and particularly for the vehicle rental industries. [0084] The foregoing describes only some embodiments of the present invention, and modifications and/or changes can be made thereto without departing from the scope and spirit of the invention, the embodiments being illustrative and not restrictive.

[0085] In the context of this specification, the word "comprising" means "including principally but not necessarily solely" or "having" or "including", and not "consisting only of. Variations of the word "comprising", such as "comprise" and "comprises" have correspondingly varied meanings.

Claims

CLAIMS:

1. A method for execution by a wireless mobile device for allowing access to a rental vehicle, the method comprising:

reading, by the mobile device, an identifier associated with a vehicle, the identifier being encrypted and located on a tag in proximity of the vehicle;

communicating, by the mobile device, with a server regarding renting of the vehicle; receiving, by the mobile device, authorization data from the server;

in response to receiving the authorization data from the server, wirelessly transmitting, by the mobile device, the read identifier to a controller module located in the vehicle, the controller module being coupled to a lock of a door of the vehicle,

wherein the controller module actuates the lock if the received identifier is the identifier associated with the vehicle.

2. The method according to claim 1, wherein the communicating with the server comprises: wirelessly transmitting, by the mobile device, the read identifier to a server;

wirelessly receiving, by the mobile device, rental details from the server, the rental details comprising terms and conditions for renting the vehicle;

displaying the rental details on a display of the mobile device;

receiving, by the mobile device, input from a user accepting the terms and conditions for renting the vehicle; and

transmitting, by the mobile device, the user acceptance of th e terms and conditions to the server.

3. A computer readable storage medium having a computer program recorded therein, the program being executable by a mobile device to make the computer perfon a method for allowing access to a rental vehicle, said program comprising:

code for reading, by the mobile device, an identifier associated with a vehicle, the identifier being encrypted and located on a tag in proximity of the vehicle;

code for communicating, by the mobile device, with a server regarding renting of the vehicle;

code for receiving, by the mobile device, authorization data from the server; in response to receiving the authorization data from the server, code for wirelessly transmitting, by the mobile device, the read identifier to a controller module located in the vehicle, the controller module being coupled to a lock of a door of the vehicle,

4. The computer readable storage medium of claim 3, wherein the code for communicating with the server comprise:

code for wirelessly transmitting, by the mobile device, the read identifier to a server; code for wirelessly receiving, by the mobile device, rental details from the server, the rental details comprising terms and conditions for renting the vehicle;

code for displaying the rental details on a display of the mobile device;

code for receiving, by the mobile device, input from a user accepting the terms and conditions for renting the vehicle; and

code for transmitting, by the mobile device, the user acceptance of the terms and conditions to the server.

5. A system for vehicle rental, the system comprising:

a vehicle having a tag, a door and a controller module, the tag having an identifier which is encrypted and associated with the vehicle and being located on the vehicle, and the controller being coupled to a lock of the door of the vehicle,

a server;

a wireless communications network; and

a mobile device configured to:

read the identifier;

communicate with the server regarding renting of the vehicle;

receive authorization data from the server;

in response to receiving the authorization data from the server, wirelessly transmit the read identifier to the controller module, wherein the controller module actuates the lock if the received identifier is the identifier associated with the vehicle.

6. The system according to claim 5, wherein the mobile device is further configured, in the step of communicating with the server, to:

wirelessly transmit the read identifier to a server;

wirelessly receive rental details from the server, the rental details comprising terms and conditions for renting the vehicle;

display the rental details on a displ ay of the mobil e devi ce;

receive input from a user accepting the terms and conditions for renting the vehicle; and transmit the user acceptance of the terms and conditions to the server.

7. The invention according to any one of the preceding claims, wherein the identifier is any one of a barcode, a two-dimensional barcode, and a Radio Frequency Identification (RFID).

8. The invention according to any one of the preceding claims, wherein the wireless transmission from the mobile device to the controller module is using a wireless communication system selected from the group consisting of Bluetooth, Wi-Fi, and Infrared Data Association.

9. The invention according to claim 8, wherein the wireless communication system selected is a Bluetooth low energy.

10. The invention according to any one of the preceding claims, wherein the server does not communicate with the controller module.