4681-1.doc Managing objects Field of Invention This invention relates to tracking objects lent, loaned or otherwise temporarily placed in the possession of a person. More particularly it relates to tracking test drives of vehicles at vehicle 5 dealerships. Background When a person attends a vehicle dealership to purchase a vehicle they usually take the vehicle for a test drive. Prior to taking the vehicle it is usually necessary to identify the driver, using their driver's licence, and record details of the vehicle, the time it was taken. Upon return it is necessary to record 10 that the vehicle has been returned. Current systems are paper based and frequently are not completed correctly. Typically there is a standard form upon which the salesperson records vehicle, driver and other details. Vehicle details may include the registration (licence) number and VIN. Upon return the salesperson records the vehicle has been returned. Completion of paperwork on 15 return of the vehicle is problematical. The salesperson may be in the car yard when the person returns the car. If the person does not wish to proceed the keys are returned and no the potential buyer may leave or test drive another vehicle. The paperwork is typically in an office and the salesperson may not even bother to enter relevant details on the paperwork. If any traffic offences such as speeding have been detected by traffic cameras, the dealership may 20 receive an infringement notice some weeks later. If the paperwork has been mislaid or incorrectly completed, the dealership may have difficulty in legitimately transferring responsibility to the actual driver. Similarly, if there has been an accident and the paperwork has not been correctly completed before the test drive the dealership may have difficulty in legitimately transferring responsibility to the actual driver 25 Summary of the Invention In one broad form the invention provides an object tracking system, the system comprising a database including details of a plurality of objects, a computer program for selecting one of the objects and recording details relating to the loan of the object to a borrower. The term "loan" is to include paid and unpaid for loans. Thus a test drive of a vehicle is an unpaid 30 for loan of the vehicle whilst a service vehicle paid for whilst a borrower's vehicle is being serviced is a paid for loan. The computer program preferably runs on a mobile computing device, such as a mobile phone or a tablet computer. Preferably the objects are vehicles. 35 Preferably the details of the objects include at least one of owner, business location, identifying data, description, type of object and business department. Preferably the details relating to the loan of the object to a borrower include time and date the object is borrowed, details relating to the borrower and details relating to the user that authorised the loan. Preferably the system records details of the borrowers. 40 Preferably the detail of the borrower includes at least one of identifying data, phone number, email address, street address and a photograph. Preferably when an object is returned details relating to the time and date of return are recorded. Details of the user who accepted the return of the object are recorded. The user who accepts return of an object maybe different to the user that authorised borrowing. Users may be restricted to what 45 objects they may book in, depending on one or more of user laver and business department.
4681-1.doc -2 Comments relating to the state of the object may also be recorded. In one form the invention provides a mobile application that communicates with a back end database. A user may be required to log onto the system. The data available to a user of the application may depend on the user's ID. A user may be 5 associated with one or more locations, owners or businesses. Users may have different access levels. The data available to a user may be restricted by one or more of user level, location, owner, business object category and business department. The user may log in and search for or select an object to be loaned. Searching for or selection of an object may be based on one or more of owner, business location, object identifying data, description, 10 type of object and business department. Preferably this is based initially on object identifying data, such as vehicle VIN, stock number or registration number. The user may search for, select or enter data relating to the borrower. The application may require a photograph of a borrower or of identifying document(s) to be captured. The application preferably displays borrowing terms on a display and requires the borrower to 15 accept the terms of borrowing before completion of the borrowing transaction. The application may require a signature for acceptance. In a preferred form of the invention a user logs on to the system. To book out an object the user searches for or selects objects and the available objects are filtered based on being not booked out, associated with (belonging to) the location currently associated with the user and also optionally 20 being filtered by user level, object type and business department. In one broad for the invention provides an object tracking system, the system comprising a server with a database including details of a plurality of objects, at least one remote device with a remote application for selecting one of the objects and recording details relating to a loan of the object to a borrower in the database. 25 In another broad form the invention provides an object tracking system, the system comprising a database including details of a plurality of objects, a remote application for selecting one of the objects and recording details relating to a loan of the object to a borrower in the database the database application running on a server and at least one remote device running the remote application, 30 the remote application operable to retrieve object data indicative or a plurality of objects from the server and select a one or the plurality of objects; retrieve borrower data indicative or a plurality of borrowers from the server and select a one or the plurality of borrower; 35 pass selected borrowing data indicative of at least the selected object and the selected borrower to the server the server operable to receive the selected borrowing data from the remote application; create a borrowing record associated with the object and the borrower selected by the remote 40 application. In another broad form the invention provides an object tracking system, the system comprising a server with a database including object data representative of details of at least a plurality of objects, the server operable to receive data from a remote application for selecting one of the objects and recording details relating to a loan of the object to a borrower in the database. 45 The remote application may be operable to retrieve details of at least one object from the server. The remote application may be operable to retrieve details of a plurality of objects from the server. The remote application may be operable to retrieve details of a plurality of objects from the server and to select a one of the plurality of objects. The remote application may be operable to send object data indicative of an object to the server.
4681-1.doc -3 The server may be operable to create a record representative of a selected object after receiving object data indicative of a selected object from the remote application. The object data may include data indicative of at least one of: Manufacturer; 5 Stock code; Model; Model year; Condition; Category; 10 Identifying data; Description; Type of object; Department; Owner, and 15 Business location. Where the object is a vehicle the object data may include data indicative of at least one of: Manufacturer; Stock code; Model; 20 Model year; Colour; Registration number; Vin number; Condition; 25 Category; Other identifying data; Description; Type of object; Department; 30 Owner, and Business location. The criteria for selection of a filtered list of at least one object may be based on one or more of owner, business location, object identifying data, description, type of object and business department. 35 The object data may include an availability flag, indicative of the availability of the object. The object data may include a borrowed flag, indicative of the object being borrowed. The object data may include an availability flag and the server may be operable to change the availability flag when a borrowing record is created or when a borrowing record is completed. The server may be operable to pass object data to the remote application restricted to available, 40 unavailable or both available and unavailable objects. The remote application may be operable to request object data from the server restricted to available, unavailable or both available and unavailable objects. The remote application may be operable to send instructions to the server to retrieve details of at least one borrower. 45 The remote application may be operable to retrieve details of a plurality of borrowers from the 4681-1.doc -4 server. The remote application may be operable to select a one of the plurality of the borrowers. The remote application may be operable to send selected borrower data indicative of a selected borrower to the server. 5 The server may be operable to create at least one record representative of a selected borrower after receiving selected borrower data indicative of a selected borrower from the remote application. The borrower data may include data indicative of at least one of: an image, including an image of the borrower, and images of borrower identity documents, including passports, driver's licence, social security card and credit card; 10 the borrower's name; unique data associated with the borrower, including driver's licence, passport number, tax number or social security number; contact data, including email, telephone or username; birthdate, and 15 postal or street address. The remote application may be operable to select a one of a plurality of borrowers and a one of a plurality of objects. The server may be operable to: receive selected borrower data indicative of a selected borrower and object data indicative of a 20 selected object, and associate the selected borrower with the selected object. The server may be operable to: receive selected borrower data indicative of a selected borrower and object data indicative of a selected object from the remote application, and 25 associate the selected borrower with the selected object. The server may be operable to create at least one record associating a selected borrower with a selected object. The remote application may be operable to send instructions to the server to retrieve details of at least one lender authoriser. 30 The remote application may be operable to select a lender authoriser from a plurality of lender authorisers. The remote application may be operable to send lender authoriser data indicative of a lender authoriser to the server. The server may be operable to associate a selected borrower, a selected object and a selected lender 35 authority. The server may be operable to: receive selected borrower data indicative of a selected borrower, object data indicative of a selected object and lender authoriser data indicative of a lender authoriser, and associate a selected borrower, a selected object and a selected lender authority. 40 The server may be operable to create at least one borrowing record associating a selected borrower, a selected loan authoriser and a selected object together. The at least one borrowing record may include authorisation time data indicative of the date, time or both date and time of authorisation of the loan. The authorisation time data may be received by the server. 45 The authorisation time data may be sent by the remote application. The authorisation time data may be created by the server.
4681-1.doc -5 The remote application may be operable to require acceptance of borrowing terms by a borrower before sending said at least one of said selected borrower data and selected object data to the server. The remote application may be operable to obtain borrowing data indicative of at least one borrowing record from the server. 5 The remote application may be operable to obtain borrowing data indicative of a plurality of borrowing records from the server. The remote application may be operable to obtain borrowing data indicative of a plurality of borrowing records from the server and operable to select a one of said borrowing records. The remote application may be operable to: 10 obtain borrowing data indicative of a plurality of borrowing records from the server; select a one of said borrowing records, and return selected borrowing completion data indicative of completion of the selected borrowing to the server. The selected borrowing data may include completion data indicative of a borrowing being complete 15 or incomplete. The selected borrowing completion data may be indicative of details of a user who accepted the return of the object. The server may be operable to: receive selected borrowing completion data indicative of completion of a selected borrowing, and 20 update records of said selected borrowing to indicate the borrowing is complete. The server may be operable to pass borrowing data to the remote application restricted to complete, incomplete or both complete, incomplete borrowings. The remote application may be operable to request borrowing data from the server restricted to complete, incomplete or both complete, incomplete borrowings. 25 The remote device may include a user interface for user input of instruction(s), data or both data and instruction(s). The remote device may include a mobile computing device, including mobile phone or a tablet computer. A user or an object may be associated with one or more locations, owners or businesses. 30 In another broad form the invention provides A computer program for operation on a remote device for communication with a server with a database including details of a plurality of objects, the computer program for selecting one of the objects and recording details relating to a loan of the object to a borrower in the database. The program may be operable to retrieve details of at least one object from the server. 35 The program may be operable to retrieve details of a plurality of objects from the server. The program may be operable to retrieve details of a plurality of objects from the server and to select a one of the plurality of objects. The program may be operable to send object data indicative of an object to the server. The program of any one of the proceeding claims wherein object data includes data indicative of at 40 least one of: Manufacturer; Stock code; Model; Model year; 45 Condition; Category; 4681-1.doc -6 Identifying data; Description; Type of object; Department; 5 Owner, and Business location. The program of any one of the proceeding claims wherein the object is a vehicle and the object data includes data indicative of at least one of: Manufacturer; 10 Stock code; Model; Model year; Colour; Registration number; 15 Vin number; Condition; Category; Other identifying data; Description; 20 Type of object; Department; Owner, and Business location. The program of any one of the proceeding claims wherein criteria for selection of a filtered list of at 25 least one object is based on one or more of owner, business location, object identifying data, description, type of object and business department. The program of any one of the proceeding claims wherein the object data includes an availability flag, indicative of the availability of the object. The program of any one of the proceeding claims wherein the object data includes a borrowed flag, 30 indicative of the object being borrowed. The program of any one of the proceeding claims wherein the object data includes an availability flag and the server is operable to change the availability flag when a borrowing record is created or when a borrowing record is completed. The program may be operable to request object data from the server restricted to available, 35 unavailable or both available and unavailable objects. The program may be operable to send instructions to the server to retrieve details of at least one borrower. The program may be operable to retrieve details of a plurality of borrowers from the server. The program may be operable to select a one of a plurality of the borrowers. 40 The program may be operable to send borrower data indicative of a borrower to the server. The program of any one of the proceeding claims wherein borrower data includes data indicative of at least one of: an image, including an image of the borrower, and images of borrower identity documents, including passports, driver's licence, social security card and credit card; 45 the borrower's name; 4681-1.doc -7 unique data associated with the borrower, including driver's licence, passport number, tax number or social security number; contact data, including email, telephone or username; birthdate, and 5 postal or street address. The program may be operable to select a one of a plurality of borrowers and a one of a plurality of objects and to send selected borrower data indicative of a selected borrower and s elected object data indicative of a selected object to the server. The program may be operable to send instructions to the server to retrieve details of at least one 10 lender authoriser. The program may be operable to select a lender authoriser from a plurality of lender authorisers. The program may be operable to send lender authoriser data indicative of a lender authoriser to the server. The program of any one of the proceeding claims wherein the server is operable to create at least one 15 borrowing record associating a selected borrower, a selected loan authorised and a selected object together. The program of any one of the proceeding claims wherein the at least one borrowing record includes authorisation time data indicative of the date, time or both date and time of authorisation of the loan. The program of any one of the proceeding claims wherein the authorisation time data is sent by the 20 computer program. The program may be operable to require acceptance of borrowing terms by a borrower before sending said at least one of said selected borrower data and selected object data to the server. The program may be operable to obtain borrowing data indicative of at least one borrowing record from the server. 25 The program may be operable to obtain borrowing data indicative of a plurality of borrowing records from the server. The program may be operable to obtain borrowing data indicative of a plurality of borrowing records from the server and operable to select a one of said borrowing records. The program may be operable to: 30 obtain borrowing data indicative of a plurality of borrowing records from the server; select a one of said borrowing records, and return borrowing completion data indicative of completion of the selected borrowing to the server. The borrowing data may include completion data indicative of a borrowing being complete or incomplete. 35 The borrowing completion data may be indicative of details of a user who accepted the return of the object. The program may be operable to request borrowing data from the server restricted to complete, incomplete or both complete, incomplete borrowings. The program may be operable to provide a user interface for user input of instruction(s), data or both 40 data and instruction(s) on the remote device. The program of may be operable on a mobile computing device, including mobile phone or a tablet computer. These and other aspects of the invention shall be more readily understood from the following non limiting description of a preferred embodiment and the accompanying drawings. 45 Brief Description of the Drawings Figure 1 is a view of a mobile phone showing a log in screen of a vehicle test drive booking 4681-1.doc -8 application according to an embodiment of the invention. Figure 2 is a view of a mobile phone showing a home screen of the vehicle test drive booking application. Figure 3 is a view of a mobile phone showing a "new test drive" screen of the vehicle test drive 5 booking application. Figure 4 is a view of a mobile phone showing a first "Identify Vehicle" screen of the vehicle test drive booking application. Figure 5 is a view of a mobile phone showing a second "Identify Vehicle" screen of the vehicle test drive booking application. 10 Figure 6 is a view of a mobile phone showing an "Identify Driver" screen of the vehicle test drive booking application. Figure 7 is a view of a mobile phone showing a "Book out" screen of the vehicle test drive booking application. Figure 8 is a view of a mobile phone showing a "Book In" screen of the vehicle test drive booking 15 application. Figure 9 is a view of a mobile phone showing a "Statistics" home screen of the vehicle test drive booking application. Figure 10 is a view of a mobile phone showing a "Settings" screen of the vehicle test drive booking application. 20 Figure 11 is a flow diagram of the log in process. Figure 12 is a flow diagram of the book out process. Figure 13 is a flow diagram of the vehicle identification sub process of the book out process. Figure 14 is a flow diagram of the vehicle book in process. Figures 14 to 43 are views of a user interface of a remote program running on a remote device, such 25 as a mobile phone or tablet computer. Detailed Description of Preferred and other Embodiments The test drive system utilises a back end/front end architecture, whereby all relevant data is stored in a central back end server with users accessing and recording test drives from separate front end applications, typically running on mobile phones or tablet computers. The server may be distributed 30 across more than one hardware device. The back end has data relating to dealerships, departments and/or categories of vehicles, vehicle data and user data. Vehicle data typically includes Make, Model, Year, VIN, Stock number and other data such a colour. All of this data may be manually input into the system or imported from suitable data files. 35 Alternatively, some or all of the data, particularly vehicle data may be accessed from a dealership's existing stock control system and can effectively "piggy back" off that system, so as to avoid duplication of data entry. To better understand the invention, an embodiment will be described first with reference to the end user experience and then with reference to the background functionality. 40 Referring to figures 1 to 10 there is shown a mobile device 10 running an application 12 according to an embodiment of the invention. Ideally the mobile device is a mobile phone but may be a tablet or other portable computer. On start-up of the application 12 a user is presented with a log in screen 14 with username and password fields 16, 18 respectively. After entering the user credentials the user logs in using login 45 button 20. A home screen 22 is presented to the user (figure 2). The information displayed on the home screen 22 may depend on the class of user (discussed later) as well as the identity of the user.
4681-1.doc -9 The system is intended to be used across multiple dealerships and so each user is usually associated with a single dealership. However, a user, such as an owner or dealer principal of multiple businesses, may be associated with multiple dealerships. Only data associated with the dealership(s) with which a user is associated is available to a user. It 5 will be understood that all actions subsequently described assume a single dealership and all data is limited to that dealership. The home screen 22 preferably displays the user's real name at 24 and details of their last login at 26. If a picture of the user has been stored it may be displayed at 28. The home screen includes a "Test Drive" button 30, a "Book in" button 32 and a log out button 34. 10 Optionally settings and statistics buttons 36 and 38 may also be displayed. "Test Drive" button 30 is selected when a person wishes to take a vehicle for a test drive. The user presses the "Test Drive" button 30, which opens a "New Test Drive" screen 40 (figure 3). This screen 40 includes an "identify vehicle" button 42 and a driver details button 44 as well as a book out button 46. 15 If the user is associated with multiple dealerships/franchises, optionally the system may first provide a screen (not shown) whereby the user selects the appropriate dealership. The system may record the last dealership used by the user and may automatically select that dealership without user action, until the user selects another dealership, such as through the settings menu. The screen also includes indicators 48 and 50 to indicate whether mandatory information has been 20 selected/captured to allow the vehicle to be taken for a test drive. Initially these will be negative, indicated by a cross or red marker. The "book out" button 46 may be inactive or disabled until all mandatory information has been collected or selected. When all mandatory information has been collected/selected for that test drive the indicators are positive (a tick or green) and the book out button 46 is activated. 25 The next step is to identify the vehicle to be driven. Accordingly, the salesperson presses the "identify vehicle" button 42. In a normal situation details of all vehicles of the dealership will be available in the system. Vehicles may be categorised, such as whether they are "new", "used", "demonstrator", "service department loan vehicles" or "other". 30 A user may be associated with one of these categories as their default category. By default the system may limit vehicles to those of the user's default category or may provide the user with a category selections screen whereby the user may confirm their current selected category or select another category. The selection screen may also include an "all vehicles" option. If the user selects a different category to the stored default category that "new" category may be stored and become the 35 user's default category. Depending on the user's user type only some of the options may be available. For instance, a dealer principal will usually have access to all options whist a salesman may only have access to "new", "used", "demonstrator" vehicles and service personnel may only have access to "service department loan vehicles". 40 The user is presented with a search and filter/selection screen 52 whereby the user may identify and select the correct vehicle. Most dealerships associate a stock number with each vehicle. The user may enter a VIN at 54, a stock number at 56 or a registration number at 58. On completion of the relevant field the data is returned to the back end and an appropriate search conducted of vehicles in the database. The search 45 will be limited by the vehicle category, the user's ID, dealership ID and Category ID. Vehicles that have already been booked out but not yet booked in are excluded from the search results. If no match is found the system displays a "No Match found" message or similar. If the vehicle has been booked out but not booked back in (returned) the system may display a message to that affect. This may be because the user has entered the incorrect data or because the 4681-1.doc - 10 vehicle has been returned but not been booked in. The system may prompt the user to verify data and if necessary book in the vehicle. If a match is found the system displays data such a Vehicle Make at 60, Vehicle Model at 62, Vehicle Year at 64. The system may also fill in the other searchable fields, 54, 56 and 58. Thus if the 5 vehicle has been identified by searching on registration number at 58 the system may fill in the VIN and stock number fields 54, 56. A summary line 66 may be displayed and the user may confirm by selecting the displayed item. If no match is found the user may manually filter records in an attempt to identify the vehicle using the drop down lists of make 60, model 62 and year 64. Ideally each lower list is filtered by the higher 10 selections. Thus the user may select the make, such as Ford, which limits the list of models to Ford models, such as Falcon, Focus, Mondeo, etc. A list of possible vehicles may be displayed at 68 and the user may select the correct vehicle, at 70. Selection may be indicated by a tick 72. After selecting the vehicle the user presses the "done" button 74, which takes the user to the driver 15 selection/entry sub system. Drivers may be "new" or already recorded in the system. The "driver details" screen 80 shown in figure 6 is initially devoid of data. Drivers are identifiable within the system by their driver's licence and the initial step is to enter the driver's licence number at 82. The jurisdiction (state) may be entered at 84 if necessary. The system searches for a single matching driver's licence number. There 20 should only be one matching record but potentially the same number may be used in different jurisdictions. If multiple records are found the system may prompt for restriction by jurisdiction or may present. If multiple records are found these may be presented to the user to select or an error message may be displayed. Assuming one record is found the fields for name 86, address 88, date of birth 90 and optionally 25 telephone number 92 and photo 94 are completed for the user to check against the physical driver's licence, which they should have in their possession. Assuming all data matches, the user confirms the details are correct. If data is missing the user may enter this. If a photograph is required a photograph may be captured using the "upload photo" button 98. This may be made mandatory even where all other data is present. 30 If no match is found the user is prompted to enter the relevant data in the relevant field and store this in the system. A telephone number may be entered and checked against publicly available records (such as the White Pages) to obtain the relevant address details. However, this would need to be checked against the physical licence. If the address details are not found or different to that on the physical licence 35 the data may be entered or edited in the driver details fields. Once the user is satisfied the driver details are correct and the system is satisfied all mandatory data has been collected the user may proceed to the "Book Out" screen 100, shown in figure 7. This displays the vehicle selected at 102 and the driver selected or entered at 104. If these are not correct the selections may be edited using buttons 106 and 108 respectively. These take the user back to the 40 relevant screens. Ideally the driver needs to acknowledge the terms under which they may drive the vehicle. These terms may vary depending on the category of the vehicle selected. The terms may be viewed and accepted using the "View Terms" button 110. This may display the terms in a new screen and the driver, not the user may be required to scroll to the end of the document before proceeding. The 45 system may require the driver to sign to confirm acceptance of the terms. The system is intended to run on "smartphones" or tablets, which almost universally have touch screens so collection of a signature is feasible. Once the terms have been accepted the user presses the "Book out" button 112. The "Book out" button 112 may be disabled (greyed out) until the terms have been accepted. 50 Pressing the "Book out" button 112 finalises the transaction and stores the date and time of book out 4681-1.doc - 11 as well as other data such a user, driver etc. against the relevant vehicle. When the vehicle is returned the user selects "Book in" button 32 (figure 2), which opens the book in screen 120, shown in figure 8. If desired vehicles may be booked in by a user that is different to the user that booked out the 5 vehicle. Accordingly, initially a determination may be made as to whether there are any of the dealership's vehicles booked out. If there a no vehicles booked out if follows that none can be booked in and the book in button 32 may be greyed out. Alternatively, if a user such as a service technician is only allowed to book in service loan vehicles the initial determination may be based on whether any service loan vehicles have been booked out. 10 This book in screen 120 has drop down list 122 which shows summaries of all vehicles booked out by dealership (or of the user or category if so limited). This list may be may be further limited by the user ID and/or category depending on the set up of the particular user. The user may select the appropriate entry, which results in population of vehicle field 124 and driver field 126. This allows the user to confirm that the correct vehicle has been selected for booking in. 15 As an alternative the user may be required to enter vehicle identification data, such as VIN, stock number or registration number, with vehicles identified in a similar manner to the book out process, to identify the correct booked out vehicle. If no vehicle is found it may be because the data does not match in the database or the vehicle identified has not been recorded as being booked out. Appropriate messages can be displayed to the 20 user, such as "no record found, please check number" and "this vehicle is not recorded as being booked out". Once the correct vehicle has been identified and selected the system my prompt the user (or driver) to enter or select one or more "outcomes" of the test drive. These outcomes may include: 1. Sold; 25 2. Introduce to BM; 3. Trade-in price not accepted; 4. Vehicle unsuitable; 5. Requires mechanical inspection; 6. Return to re-test drive; 30 7. Return with expert; 8. Return with trade-in, and 9. Other. If "other" is selected then a short free text field may pop up. One or more of the outcomes may be selected. The selection/entry of outcomes may be a mandatory 35 step before a vehicle is booked in or may be optional. The system may also allow "issues" to be entered in a free form text box (not shown) accessed by "Issues" button 130. Matters recorded may be anything desired but typically may be perceived or real faults or failings of the vehicle reported by the test driver, such as "pulls left on braking" and "rear seat leg room too small". 40 The vehicle selected may be booked in by pressing "book in" button 128. This completes the test drive record and releases the vehicle to be booked out for another test drive. The name of the user who booked in the vehicle and the date and time of book in are recorded. The data recorded in the system may be reviewed by users. The level of data available is determined by the relevant user. A salesperson may review data related to test drives that they have booked out 45 but not that related to other salespeople. A dealer principal may review all data. Figure 9 shows a statistic screen 130 available to a dealer principal. The dealer principal may have multiple dealerships and, accordingly, the screen 130 includes dealership button 132 as well as salespeople button 134 and vehicle button 136.
4681-1.doc - 12 Data that may be view includes, but is not limited to: 1. Average number of test drives per day, per month and per year; 2. Most active sales person by test drives; 3. Most popular test drive vehicle; 5 4. Most popular address suburb of test drivers, and 5. Most popular test drive time of day for the past week/month. Rather than providing a singular "most popular" return, the system may provide an ordered list. Such a list may be of all relevant data within a selected period or may, for example, be limited to the top ten in each category. 10 In relation to most popular test drive vehicle this may be a consolidated list of similar vehicles. A user such as a salesperson may be limited to data such as: 1. Average number of test drives per day, per month and per year; 2. Most popular test drive vehicle; 3. Most popular address suburb of test drivers; 15 4. Most popular test drive time of day for the past week/month Some of the settings in the system may be modified by users depending on user level. Figure 10 shows a settings screen 140 available to a dealer principal. This screen 140 allows a dealer principal to modify basic data relating to a dealership. Data that can be modified includes but is not limited to Editing the dealership logo on all internal application pages post log-in (must show 20 guidelines for upload image resolution), dealership name, address, tel. no. and web URL - these fields will be common to all users and may be included in any communication with actual or potential customers. Lower level users such as salespeople may modify their contact details, such as their name displayed on the log on screen and a name used in communications (which may be different to the displayed 25 name), email address and mobile telephone number in the signature attached to client emails. The users may also be allowed to upload/take a personal photo for display when logged in. A user may also have the ability to change their password. Figures 11 to 14 show some of the flow charts relating to various actions described above. Figure 11 shows the initial log on process. 30 The application on the user's device 150 starts at 152 and first checks with the backend 151 for any messages or alerts at 154. If there are any messages or alerts these are displayed, at 156. Assuming no messages or alerts the application displays the log on screen at 158. The log one screen includes log on button 160, which if pressed checks for user ID (UID) and password at 162. If both are present the data is sent to the back end 151 for verification at 164. If not, an error message is 35 displayed at 166 and the user returned to the log on screen. If log on is successful the back end 151 retrieves data relating to the logged on user at 168 and configures the front end application 150 with that data at 170 and the application displays a logged in home page shown in figure 2 at 172. Figures 12 and 13 show the process steps in booking out a vehicle. Population of vehicle data may 40 occur as part of or immediately after log in or may occur when a user presses the "Test Drive" button 30. Referring to figure 12, at 250 the application obtains the department of category from the database using the user's ID. The user may be prompted to change category at 254 and if "no" is selected the user is prompted to identify the vehicle at 256. On pressing "yes" the user is taken to the identify 45 vehicle screen (shown in figure 13) at 258. After completion of the vehicle identification stage the user is returned to the book out screen where they may press the "identify driver' button at 260 and be taken to the "identify driver" screen at 262. After the driver is identified or selected the user is returned to the book out screen where they may 4681-1.doc - 13 press the "Book out" button at 264. The application checks for all required fields at 266 and if validation is successful shows a successful "book out" at 268 and creates a record in the server at 270. Identification of the vehicle being booked out occurs on the identify vehicle screen shown in figure 5 13. Population of vehicle data occurs by first obtaining a dealership flag at 180. The flag is checked if internal at 182, in which case vehicle data is obtained from an internal database 184. If the flag is not internal the flag is checked for "external" at 186. If external, vehicle data is obtained from an internal database 188. If neither, an error is flagged at 190. If vehicle data has been obtained the "Vehicle Identification" screen (figure 4) is shown at 192. 10 When the user presses a confirm button the system first checks if a VIN, stock or registration number at 194 and compares to the retrieved vehicle data at 196. If a match is found, the vehicle details are retrieved at 198, displayed and the "done' button displayed at 200. If no match an error message is displayed at 197 and the user returned to the vehicle Identification screen at 192. Alternatively, the user may have used drop down list(s) at 202 to select a vehicle. The vehicle details 15 are retrieved at 198, displayed and the "done' button displayed at 200. Figure 14 shows the book in steps. The system obtains data relating to booked out vehicles based from the back end at 210, which is used to populate a drop down list at 212. This may be based on one or more of user ID, dealership, department and vehicle category. The user selects an entry from the drop down list at 214. The 20 system displays vehicle and driver data at 216. When the "Book in" button is pressed at 218 the system may optionally check if the vehicle is already booked in at 220, in which case the user is returned to the vehicle selection stage 214. However, the system may be configured such that the list is only populated with booked out vehicles at 212. Assuming the vehicle is booked out, a confirmation button is displayed at 222 and if pressed the 25 vehicle is booked in with the date and user recorded at 224 and the server updated at 226. If the "issues" button is pressed at 230, any issues are entered at 232 and again the server is updated at 226. After the server has been updated the user is returned to book in screen. The user may finalise the particular book in process by pushing the home button at 234 or by pushing a "finished" button. 30 When either is pressed the system checks for changed data at 236 and if so prompts for an email to be sent to the driver at 238. If selected the driver's email and other details are retrieved at 240 and a receipt/confirmation/follow up emails sent to the driver. Dispatch of the email is recorded at 242.
4681-1.doc - 14 Figures 15 to _ shown screen shots of another embodiment of the invention, similar but slightly different to the first embodiment. Figure 15 shows a login screen 300 having user name field 302 and password field 304. A user may log on by entering relevant data and pressing login button 306. Password reset for a user may be 5 achieved by pressing password reset button 308, which takes the user to a rest screen 310. If the surname had been entered at 302 it is copied to username field 312. Otherwise the user may enter their username manually into field 312. Password reset is achieved by pressing reset button 314 or cancelled with button 316. The system checks the username entered at 312 and if in the system resets the password and sends an appropriate message (email, SMS, etc.) to the user's device(s) registered 10 in the system with a new password. A new user may register by pressing register button 320, which takes the user to a new user screen 0. Successful login takes the user to a home screen 322, which preferably displays the user's real name at 324. If a picture of the user has been stored it may be displayed at 328. 15 The home screen includes: A Book out Button 330, which initiates the process of Book out of a vehicle; A Statistics Button 332, which redirects the user to a Statistics Page; A Settings Button 334, which redirects the user to the Settings Page; An active Drives Button 336, which redirects the user to the Active Drives Page, and 20 A Logout Button 338, which initiates the Logout Procedure and Redirects the user to the Login Page 300. The "Book out" button 330 is selected when a person wishes to take a vehicle for a test drive. The user presses the "Book out" button 330, which opens a "New Test Drive" screen 340 (figure 3). This screen 340 includes a search filed 342. 25 Searches may be on the stock number or registration number and search type buttons 346 and 348 are provided to limit the search to stock number or registration number respectively. The category or department may be selected from drop down list 350. On some devices the drop down list may be presented as a pop up window 352, shown in figure 19 whereby a user may selected appropriate entry 354 and confirm this with the "done" button 356 30 One appropriate selections/entries have been made the user may initiate a search using search button 344. The criteria are transmitted to the back end server which searches records according to the criteria, and, assuming a match, returns appropriate data to the user's device and displays the results, 360 (fig 20). 35 Details of new vehicles may be entered by pressing new vehicle button 362 (fig 19), which opens new vehicle screen 364. The user may enter appropriate vehicle details, such as stock number 366, Registration number 368, make 370, model 372, department and year (not shown). This data is transmitted to the back end server when the user presses the submit button 374 and a new vehicle entry is created in the appropriate table(s) of the database. 40 Referring to figure 20, additional details of a vehicle 360 returned by the search may be displayed by pressing details arrow 376, which opens details screen 378. This screen displays a non-editable list of vehicle data, such as stock number 380, Registration number 382, make 384, model 386, year 388 and department 390. The user may return to the previous screen using back button 392. The next step of the book out process is initiated by pressing the continue button 396, which takes 45 the user to a client search screen 400. Existing clients may be searched for by driver's licence number or phone number, with selection buttons 402 and 404 providing appropriate criteria. Client data is entered in search field 406 and the search initiated by search button 408. The user device transmits appropriate search data to the back end server with a request for a search and the back end returns appropriate data if a match is found, displaying the relevant record(s) at 410. Telephone 50 numbers are not necessarily unique and multiple records may be returned with a telephone search.
4681-1.doc - 15 The or an appropriate entry is selected using selection arrow 412, which opens details scree 414 (fig 26). This displays additional data for the selected client, such as phone number 416, licence number 418 and name 420. Photographs of identity documents such as driver's licence, passport etc. the may be displayed at 422. Assuming the selected client is the correct person the user selects continue 5 button 424. New clients may be added using new client button 426 (figs 23 & 24), which opens new client screen 428 (fig 25). Appropriate Data is entered, such as phone number 430, licence number 432 and name 434. Photographs of identity documents such as driver's licence, passport may be captured by pressing icons 436. This opens a camera application on the device such that the user may capture an 10 image of an identity document. When all required data has been captured/entered the user presses the continue button 438. This causes the program to transmit the relevant data to the back end server with a request to create a new client record in the client record table(s). Whether a new client is created or an existing client selected, the program then displays a confirmation screen 440 (fig 27). This displays summary details of the vehicle selected at 442 and 15 the test driver at 444. The screen 440 includes a button 446 to display the terms and conditions and a terms acknowledgement box 448 to confirm acceptance of the terms and conditions. The screen includes a book out button 450. This button may be greyed out or inactive until the terms acknowledgement box 448 has been selected. Selection of the terms acknowledgement box 448 may also be prevented until the terms have been displayed by pressing the terms button 446. Pressing the 20 terms button 446 opens terms screen 452 which displays the actual terms at 454. Return to the confirmation screen 440 is via button 456. Alternatively, pressing the book out button 450 may cause the program to display a message 458 for a short period of time and then takes the user to the terms screen 452. On pressing book out button 450 the program shows final confirmation dialog 460 with yes and no 25 buttons, 460 and 462. If the user presses the yes button 462 the program transmits data to the back end server confirming acceptance and completion of the user book out process. As with the first embodiment a new "test drive" record is created in the appropriate database table(s). Details of test drives may be accessed using the active drives button 336 on the home screen 332. A quick menu 470 appears at the bottom of most screens which allows direct access to the book out 30 process, active test drives, statistics and settings via buttons 472, 474, 476 and 478 respectively. Pressing the active drives buttons 336 or 474 opens active drives screen 480. Records may be filtered to active, incomplete or all drives by filter buttons 482, 484 and 486 respectively. Pressing a button filters records returned from the back end server. Summary details are displayed at 488. Details of each test drive are displayed by pressing detail arrow 490 of the respective record. This opens details 35 screen 492 which shows relevant details at 494 and which, if it is an active test drive, allows the user to book in a test drive using book in button 496. Details screen 492 has toggle buttons 500 and 502 that allow details of the vehicle or client to be displayed at details section 494 respectively. The result of the test drive may be selected using drop down list 498, which expands to a pop up dialog 504, shown in figure 36. 40 Pressing book in button 496 displays confirmation dialog 506. Pressing "yes" 508 cause the program to transmit data to the back end server, which records that the test drive has been completed and enters additional data, as with the first embodiment, such as date and time and result. Settings for a user may be viewed/modified by pressing settings button. This opens settings screen 510, which displays various options, such as the user's profile 512. Details may be viewed by 45 pressing details arrow 514 on the appropriate entry, which opens a details screen 516. The details screen displays personal and business data at 518, with toggle buttons 520 and 522 changing what is displayed. Changes can be made and updated using update button 524. Statistics can be accessed via statistics button 332 on the home screen or statistics button in the lower menu. Either opens statistics screen 526. Statistics groups may be selected using buttons 528 50 and 530. Statistics types and groups may be filtered using drop down lists 532 and 534. These drop down lists display pop-up windows 538 and 540 respectively, shown in figures 44 and 45 4681-1.doc - 16 respectively. After selecting appropriate settings the user submits the request to the back end server via submit button 536. The results are returned by the server to the user's device and displayed on statistics screen 550. 5 4681-1.doc - 17 Unless the context clearly requires otherwise, throughout the description and any claims the words "comprise", "comprising", and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is to say, in the sense of "including, but not limited to". The features of the invention described or mentioned in this document may be combined in any 5 combination of features where features are not mutually exclusive. It will be apparent to those skilled in the art that many obvious modifications and variations may be made to the embodiments described herein without departing from the spirit or scope of the invention.