AU2015202848A1 - A fleet management system for transport providers - Google Patents

Abstract

Abstract A method for managing a fleet of vehicles involves operating a computer server, i.e. webserver 5, to serve shift notices to the computer devices of the drivers 1 a to 1 n and subsequently to monitor for acknowledgments from the 5 drivers that the shift notices have been received and accepted. The method further involves operating the web server 5 to record the acknowledgments in a database 11. Al (1 < r[El .. . .. . .

Description

AUSTRALIA PATENTS ACT 1990 COMPLETE SPECIFICATION A FLEET MANAGEMENT SYSTEM FOR TRANSPORT PROVIDERS The following statement is a description of the invention: 1 A FLEET MANAGEMENT SYSTEM FOR TRANSPORT PROVIDERS 1.1 TECHNICAL FIELD 5 The present invention relates to a method to assist transport providers manage the day to day running of a transportation business. 1.2 BACKGROUND Any references to methods, apparatus or documents of the prior art are not to be taken as constituting any evidence or admission that they formed, or form 10 part of the common general knowledge. The administrator of a transportation company such as a bus company is faced with many challenges in the day to day running of the business. Some of these challenges simply relate to the efficient running of the business so 15 that the administrator seeks to reduce the wastage of labor hours and to optimize the efficient use of assets while providing a high level of customer service. Other challenges are stipulated by regulatory bodies and concern such issues as making sure that vehicles are inspected prior to use and that drivers are in a fit state to operate vehicles. 20 A general issue that an administrator of a transportation company must grapple with is that it is difficult to scale the necessary administrative processes as the business grows. Consequently, the owner of a small transportation business will typically find it difficult to maintain efficiency and regulatory compliance of the transportation business as the number of 25 vehicles, drivers and routes increases over time. One particular problem that the administrator of a transportation company faces is that of keeping track of drivers and ensuring that they have received and accept the duties required of them during performance of their shifts.

2 It would be advantageous if a fleet management system were available that addressed the above problem. 1.3 OBJECT OF THE INVENTION It is an object of the present invention to provide is a fleet management 5 system that is an improvement on those systems which have hitherto been known and which assists an administrator of a transportation company to efficiently and scalably manage the transportation company. 1.3A SUMMARY OF THE INVENTION 10 According to a first aspect of the present invention there is provided a method for management of a fleet of vehicles comprising operating a computer server to: serve shift notices across a data network to remote computational devices of drivers of the vehicles; 15 monitor for acknowledgments of receipt and acceptance of the notices from each of the drivers; and record said acknowledgements for inspection by an administrator of the fleet. 20 Preferably the method includes operating the computer server to facilitate specification by the administrator of audience scope for the notices. For example, the audience scope may be one or more of: general distribution; driver specific; 25 vehicle specific; shift specific; or time based. In a preferred embodiment of the invention the method also includes 30 operating the computer server to serve shift itineraries to the driver devices.

3 Preferably each shift itinerary comprises information specifying steps to be complete by a respective driver during the shift. 5 In a preferred embodiment of the invention the method includes operating the computer server to monitor for confirmation that each step is completed sequentially. Preferably the method includes operating the computer server to determine 10 that each of the drivers has complied with an alcohol check requirement. In one embodiment of the invention the method includes operating the computer server to prompt drivers to enter on their device a passenger number for the driver's fleet vehicle. 15 Preferably the method includes operating the computer server to determine compliance with the alcohol check requirement in response to the driver indicating that at least one passenger has boarded said fleet vehicle. 20 In a preferred embodiment of the invention the method includes operating the computer server to issue an alert in response to the driver failing to comply with the alcohol check requirement. The method may include operating the computer server to determine 25 geographical positioning and presenting appropriate pages of a shift itinerary to the driver based on the determined geographical positioning. The method may include operating the computer server to require drivers to enter pre and post shift odometer readings of their fleet vehicles. 30 Preferably the method includes facilitating administrator specification of when forms and processes are served to said devices and time frames in which driver completion of forms is required.

4 For example, the administrator may specify that the forms and processes are to be presented to a driver pre-shift, post-shift, or upon a specified vehicle passenger count being reached. 5 It is preferred that the method includes operating the computer server to administer a driver vehicle check. Preferably the method includes operating the computer server to log driver 10 feedback for said vehicle check. The method may include notifying drivers that a vehicle is not to be used based on said feedback for said vehicle check. 15 According to a further aspect of the present invention there is provided a computer server that is programmed to implement the above method. According to a further aspect of the invention there is provided a software product in the form of a non-transitory computer readable medium, such as 20 an optical or magnetic or solid state disk, bearing machine readable instructions for a computer server to implement the previously described method. 1.3B BRIEF DESCRIPTION OF THE DRAWINGS 25 Preferred features, embodiments and variations of the invention may be discerned from the following Detailed Description which provides sufficient information for those skilled in the art to perform the invention. The Detailed Description is not to be regarded as limiting the scope of the preceding Summary of the Invention in any way. The Detailed Description will make 30 reference to a number of drawings as follows: Figure 1A depicts a webserver and database arranged to implement a preferred embodiment of the present invention.

5 Figure 1 B is a further diagram of the webserver and database showing the internal components of the webserver. Figure 1 is a screen shot of a manage notices page for a manager that is presented during performance of a method according to a preferred 5 embodiment of the invention. Figure 2 is a screen shot of drivers device screen for a driver to enter acknowledgment of receipt and acceptance of shift itinerary that is presented during performance of the method. Figure 3 is a screen shot of a shift details setup page for a manager 10 that is presented during performance of the method. Figures 4 to 9 are various screen shots that are generated on a driver's computational device during performance of the method. Figures 10 to 15 are flowcharts setting out procedural steps that are undertaken during performance of the method. 15 Figures 18 to 20 are various screen shots that are generated on a driver's computational device during performance of the method. Figures 20 to 22 are database tables for a datatabase used during performance of the method. 20 1.3C DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS Referring now to Figure 1 A, there is depicted a block diagram illustrating the entities involved in the performance of a method according to a preferred embodiment of the present invention. Broadly stated, a preferred embodiment of a first aspect of the method 25 involves operating a webserver 5 to serve shift notices to the computational devices, e.g. mobile phones, tablets etc, of drivers 1 a,..,1 n. The drivers are each allocated a vehicle and a computational device such as a smartphone 6 or tablet to which the server 5 is able to server data to across a data network, such as the Internet 4. The drivers 1 a,...,1 n are engaged by a transport company which controls the fleet of vehicles that the drivers are allocated. The transport company has 5 an administrator (or as it is equivalently called herein a "manager" 3) that is able to login to the webserver 5 using a computational device such as a desktop computer in communication with a data network such as the Internet 4. Clients 2a, 2b of the transport company are each equipped with a data 10 communications device such as a desktop computer or a smartphone. Non limiting examples of suitable smartphones are Apple iPhones or Android phones although Android is the preferred operating system. Consequently, the clients are able to login to the webserver 5 in order to interact with information that is of relevance to them. For example, the clients could 15 comprise mining companies that wish to check on the status of vehicle such as a bus transporting miners to one of their sites. The method involves operating a computer server, i.e. webserver 5, to serve shift notices to the computer devices of the drivers 1 a to 1 n and subsequently to monitor for acknowledgments from the drivers that the shift 20 notices have been received and accepted. The method further involves operating the web server 5 to record the acknowledgments in a database 11. The database is arranged according to tables that are set out in Figures 27 to 29. Figure 1 B includes a block diagram of the web-server 5 for carrying out a 25 method according to an embodiment of the invention that will be described. It will be understood that the computer system 5 comprises an exemplary electronic processor based system for carrying out the method. The computer system 5 includes a main board 53 which includes circuitry for powering and interfacing to at least one onboard processor 55. The at least 7 one onboard processor may comprise two or more discrete processors or processors with multiple processing cores. The main board 53 acts as an interface between microprocessor 55 and secondary memory 57. The secondary memory 57 will typically comprise 5 one or more optical or magnetic, or solid state, drives. The secondary memory 57 stores instructions for an operating system 59. The main board 53 also communicates with random access memory 61 and read only memory 63. The ROM 63 typically stores instructions for a Basic Input Output System (BIOS) which the microprocessor 55 accesses upon start up 10 and which preps the microprocessor 55 for loading of the operating system 59. The main board 53 may also be coupled to an optical disk reader/writer 72 so that tangible machine readable instructions borne on the disk can be loaded into RAM 61 and the secondary storage 57 and executed by the 15 central processor 55. An optical disk 77 bearing tangible machine readable instructions for the webserver 5 to carry out a method according to an embodiment of the present invention may be read by the disk drive 72 and subsequently executed by processor 55. The main board 53 also interfaces with a graphics processor unit 65. It will 20 be understood that in some systems the graphics processor unit 65 is integrated into the main board 53. The main board 53 will typically include a communications adapter, for example a LAN adaptor or a modem. The communications adaptor places the computer system 5 in data communication with a computer network such 25 as the internet 7 and thence to remote computational devices of transport providers 1a,...,1n and customers 3a,...,3m. A user of the computer system 5 is able to interface directly with it by means of keyboard 69, mouse 71 and display 67. Alternatively, as is more often the case for servers an administrator may interface with the computer system 30 across a data network by using a remote terminal application.

8 The programming of the webserver 5 is straightforward once the preferred method is understood from the following description. As previously alluded to, the data communications between the webserver 5 and each of the drivers 1 a,..,1 n, the administrator 3 and customers 2a, 2b, 5 are established via a data network such as the Internet 4 with broadband communication via mobile phone network(s) 9 to the various computational devices of the drivers, the administrator and the customers. The webserver 5 facilitates the serving of shift notices to the drivers' computational devices. The shift notices that are presented to the drivers on 10 their devices prompt each driver to acknowledge receipt of the notice and acceptance of the duties, i.e. the "steps" set out in the shift notice. The computer server 5 monitors for acknowledgments of receipt of the shift notices and of acceptance of the notices. When the computer server 5 receives an acknowledgment it stores it in the database 11. 15 As will be discussed several other pages and processes are served to the computational devices of the drivers and the driver responses are monitored and logged to assist the administrator in the smooth and regulatory compliant running of the transportation company. The computational devices of the drivers are typically GPS equipped and so 20 in some embodiments of the invention the webserver 5 is able to track the location of the drivers and serve pages and procedures to their devices based on their location. 1.4 Feature sets 25 In a preferred embodiment of the invention management method is broken down into the following feature sets: " Shift Management " Roster Management 9 " Maintenance Management " Vehicle Tracking 1.5 User groups Targeted user groups: 5 * Administrators Managers and heads of staff. * Drivers Anyone involved in driving of vehicles. * Clients 10 Contractors and all others who will be able to view reports and tracking. 1.7 Technical specifications 1.7.1 Mobile application platform 15 The mobile app that runs on the computational devices of the drivers 1a,...,ln comprises a combination of native phone applications and web frontends with native code being written solely for the Android platform. This approach has been adopted for the following reasons: * Ease of deployment 20 Android applications can be deployed directly to any Android device via a variety of mediums (web server, email, USB) with minimal setup and no ongoing subscription costs. In comparison, deploying iOS (iPhone/iPad) applications requires an enterprise subscription.

10 * Broader range of devices Android devices come in a variety of sizes, from 3 to 12 inches. It is recommended that the drivers side of the application be used on a screen of at least 7 inches, on a tablet with full phone capabilities. 5 Such a device would provide ample screen realestate for workers to complete forms, view maps as well as be large enough to not draw the attention of vehicle operators from their driving should they need to operate the device (e.g. read an important notification). * Greater control over the device 10 Native Android applications are able to continue running, even when not actively being used. This functionality enables the creation of programs that intelligently monitor network availability and the sending of queued data. Although Android is the preferred platform for the mobile devices it will 15 be realized that a method according to the present invention may be implemented using mobile devices that run other types of operating system. 1.7.2 Web application platform Keeping in mind the goal to maximise the availability and reliability of the 20 produced platform, the preferred serverside technologies are as follows: * Utilise companies that offer laaS that meet stringent standards To provide client confidence and maximum reliability, it is recommended that all servers required be purchased through companies that offer "Infrastructure as a Service" platforms that have 25 met the standards of governments and large corporations. This includes platforms such as (but in no way limited to) Amazon Web Services, Google App Engine, and the IBM Cloud.

11 * Provide failover redundancy for all mission critical servers All serverside applications should have a secondary backup system that can be automatically switched to in the event of server failure. Optimally this should be deployed in a separate availability zone, 5 separating it from the infrastructure the primary systems are dependent on (power, networking, cooling, etc.). * Transparent upgrades with zero downtime The platform used should provide a method of transparently updating the web services without interruption to end user access. This can 10 include new versions of the web application or the rapid and automated provisioning, deployment, and removal of additional servers to match system load and enduser demand. * Autonomous alerts and monitoring In the event of failure, system administrators and staff should be 15 notified autonomously of all incidents to various points of contact, this includes email and SMS. Such monitoring should be entrusted to a watchdog service provided by the laaS platform. 1.7.3 Security recommendations To properly protect sensitive business data along with client confidence, it is 20 recommended that the following basic security processes are observed: * Forced password complexity requirements and resets User credentials should be checked to ensure they meet a minimum complexity, this can include a minimum required amount of numbers, letters, and symbols. These passwords should also expire after a set 25 period of time has been surpassed, ideally this would be no longer than three months.

12 * Use of encrypted connections on all web services Spying, espionage, and hacking can all be mitigated by using encrypted connections between servers, clients, and devices. In the future, additional security can be implemented such as: 5 * TwoFactor authentication While traditional password follow a "user knows" model, TwoFactor authentication also requires that the user "have." This can mean that the user must enter a code sent via SMS to their personal phone or enter a key generated using a Timebased Onetime Password 10 Algorithm displayed on a portable device (mobile phone, lanyard key, etc.). 2 Feature 1 - Shift Manager 2.1 Description For the driver, the shift manager is an interactive step by step walk through 15 of all the tasks required of a driver in a given shift, replacing current paper forms. This will ensure that both Mine Transfers and the driver are compliant with all business processes and any other relevant standards. 2.2 Assumptions 2.3 Feature 1: Section 1 Daily 20 Notice and Work Instructions 2.4 Description A daily notice is additional information provided to drivers that is required to be read and understood before they begin their routes. Digitised, these will be disabled at the start of their shift, requiring the driver to acknowledge their 25 comprehension, tracking their response and logging it for future reference. These notices can contain rich media such as links and images when needed, and can be redisplayed at any time during their shift 13 A view of the administrative screen controlling notices to display to drivers is shown in Figure 1. 2.5 Usage scenarios 2.5.1 Driver 5 As shown in Figure 2, immediately after starting a shift on the device the driver sees the notices created by any administrator, they are required to scroll to the bottom of, and accept that they have read and understood the notice before being able to continue to the next notice (if any). When a driver acknowledges each notice, the acceptance is registered on 10 the server immediately. Administrators can view each item being agreed to in realtime, and review past agreements. At any time during their shift, the driver can reopen the notices and view them again. At this point the rereading of the data will not be registered on the server. 15 2.5.2 Administrator An administrator can control notices and how they're displayed via the web portal, they are able to create, edit, delete and assign notices to scopes. The scopes control who the notice is displayed to. The recommended scopes are: 20 * Everyone The notice is displayed to every driver at the start of their shift. * Specific driver The notice is displayed to only the selected driver at the start of their shift. 25 14 * Specific vehicle The notice is displayed to any driver who starts their shift in a specific vehicle. * Specific shift 5 The notice is displayed to any driver as long as they're working in a specific shift. * Time based The notice is displayed to any driver whose shift starts intersects with certain hours 10 2.6 Feature 1: Section 2 Shift itinerary 2.6.1 Description A shift itinerary is a detailed view of a drivers shift from start to end, controlling the flow of the drivers shift and providing step-by-stepinstructs 15 when needed. Each step must be completed before the driver is able to move onto the next step, with the device registering progress in realtime to the servers for the viewing of management; optionally, clients also have access to specific information about a drivers shift. Figure 3 is a view of the shift setup screen in the administrative web portal. 20 2.7 Usage scenarios 2.7.1 Driver Figure 4 is an example of the Shift Itinerary used at each stop the driver makes. Currently the driver can select each stop from the left menu and see 25 options relating to it such as the quick navigation to the point or its full address.

15 The driver is prompted to input the number of people who have boarded the bus at that stop, which is registered on the server for viewing in realtime or at a later stage by administrators and clients. With reference to Figures 5 and 6, after the first passenger has been logged 5 as entering the bus the driver is automatically prompted to complete their Daily Alcohol check with the witness signing their signature directly onto the device. Failure to complete the Daily Alcohol check will issue an alert to management and along with an audio/visual warning displaying on the device. 10 Future stages can implement an automatic switch to the correct stop screen when the vehicle is within sufficient range of the correct location. The shift itinerary also includes other functions such as controlling the display of forms and other procedures to be completed by the driver at various points. 15 An example of this is the requirement of odometer readings in the pre and post shift checks. 2.7.2 Administrators Administrators are able to view realtime and previously registered Daily Alcohol results via the web portal as well as control the flow of a drivers shift. 20 Managers can assign additional forms and processes that need to be completed on a pershift basis and define when they should be completed. Some examples of controllable shift flow are: * Preshift All forms and processes assigned to preshift are displayed before a driver is given permission to begin their journey. 25 * Postshift Items assigned to postshift are displayed when the driver completes all journeys and has specified that they are moving to end their current shift. Items must be completed before the shift is 16 registered to the web portal as being complete and drivers are advised that their shift has ended. * Passenger count Processes can be instructed to begin once the vehicle has reached a specified passenger count. 5 2.7.3 Clients Clients are also given the ability to view realtime updates about vehicles that are currently running jobs relevant to their associated entity. The updates give an instant view of the specific stages of a vehicles progress through the shift itinerary, including individual items in the prestart checklist, completed 10 forms, location history and more. Reporting capabilities are also present, with clients able to generate reports of most used stops, view individual pickup records, and are supplied with detailed information to help quickly resolve issues and make effective costsaving measures. 15 Clients and admins are also able to view the final headcount of the vehicle. 2.8 Feature 1: Section 3 Pre-start checklist 2.8.1 Overview The prestart checklist is displayed to all drivers after they've acknowledge that they have read and understood all daily notices and work instructions. 20 The prestart requires drivers carry out one set instruction at a time, prompting them if they've checked a specific component of the vehicle and asking if they have found any issues with the vehicle. Upon issues being found, the driver is directed to register the issue with the server. A notification is immediately sent to management via SMS regarding 25 the issue. The driver may be notified that further operation of the vehicle is temporarily prohibited depending on the issue category.

17 Figure 7 is a view of a notice screen show to drivers at the start of their shift. 2.9 Usage scenarios 2.9.1 Drivers After starting their shift, acknowledging their daily notices, and reading the 5 work instructions, each driver is required to complete the prestart checklist as shown in Figure 8. For each list item the driver is prompted: * Have you checked X? Drivers are prompted to check a specific component of the vehicle. * Was there a fault? If the driver has answered that they have 10 performed the check, they are then asked if a fault was found. If a driver answers that they haven't performed a check, they are prompted that driving the vehicle is prohibited until all checks are performed. * Issue logging If the driver specifies that a fault was found they are 15 prompted to fill out an issue report in the screen displayed in Figure 9. At this point the event has already been registered on the server and management notified about a developing issue. Depending on the issue category, three distinct outcomes can occur: Category A issues The highest priority of checks, these must be rectified 20 before the driver can continue. Category B issues Management is informed and the driver must wait for a response before continuing. Category C issues The issue is logged but the driver is not prevented from continuing, instead being advised to take caution. Issue is resolved at a later 25 date.

18 Issues can be registered with a vehicle at any time out of the prestart flow, giving administrators the control to move the issue to the maintenance schedule. 2.9.2 Administrators 5 Administrators are able to view realtime and previously registered prestart checklists via the web portal. Issues can be assigned severities, categories, and have photos attached to them for review by staff and clients, as well as resolution dates with driver notes. In future stages, staff will also be able to individually control the items on the 10 form, setting their input type, required state, and more. 2.9.3 Clients In addition to administrators, clients are also able to view the status of prestart checklists, and issues created from them, both in realtime and those previously registered to the web portal. 15 3 Time and Cost Analysis 3.1 Stage 1 3.1.2 Server Setup Inclusions * Server provisioning Planning and preparation of servers for mass 20 deployment of application. Including plan and schematic of network, as well as ensuring any rollout meets all project requirements. * Server deployment Actual deployment of servers, this task correctly rolls out machines with a focus on reliability and security. This task includes failover configuration. 25 19 3.1.3 Web Portal Inclusions * Application structure planning This task includes structuring and properly planning the development of the portal, producing documentation and class diagrams. 5 * User system The user system controls and grants access to administrators, drivers, and clients; ensuring only those who are authorized gain access to the information stored. * Device API The portal API allows devices in vehicles to communicate reliably with the administrative interface to register data 10 for reporting and realtime updates. * Communications configuration SMS and email capabilities will be constructed in this task, facilitating realtime alerts to management. * Responsive Design for User Interface All user interface elements will be built in accordance to responsive design principles to provide 15 optimal user experience for a range of screen sizes from desktop to mobile. * Daily Notices Creation Manager Allows administrators to create, edit, and delete daily notices. o Shift Creation Manager Allows administrators to create, 20 assign, and manage shifts. o User logon User authorization and identity confirmation process. o Primary Dashboard The primary overview of vehicles, shifts, and current operations. 25 o User account recovery Allow users to regain access to their accounts in case of lost passwords.

20 o Report viewer Generate staff, vehicle, and shift reports. Optionally edit existing reports. o Basic Staff management Add, edit, and remove staff. o Basic Client management Add, edit, and remove clients. 5 o Basic Vehicle management Add, edit, and remove vehicles. o Toolbox resource uploader Add, and remove vehicles documents to driver toolbox. 3.1.4 Android Application Inclusions * Realtime data synchronisation to web portal Data 10 synchronization module to manage the synchronization of data to the web portal with local caching and unlimited upload retries in the event of data connectivity problems. * MasterDetail Flow Table Interface User interface that provides optimal use of screen realestate for both portrait and landscape 15 modes of the phone. * Shift Itinerary o Step by step guidance through included shift modules o Shift progress synced to server in real time (pending data connectivity) using data synchronization module. 20 o Logging of driver shift details (date, start time, finish time, hours, kms) for time sheets. o Access to issue logger at any time through navigation menu o Access to Toolbox through navigation menu o Route pickup/dropoff guide with head count tracker. 25 o Per stop pickups / dropoffs recorded to web portal for reporting purposes 21 * Daily Notices & Work Instructions o Ensure notices and instructions are viewed, read and acknowledged at the beginning of the shift. o Ability to review notices at any stage throughout the shift. 5 * Prestart Checklist o Fully digitised version of the current prestart checklist with added kms reading check. o Link to vehicle issue logger when faulty identified with prepopulated issue type. 10 o Realtime synchronization with web portal through synchronisation module o Realtime alerts to administration for high severity issues * Postjob Checklist o Digitized postjob checklist including any tasks specified 15 during development stage. o Link to vehicle issue logger with prepopulated issue type if required o Realtime synchronization with web portal through synchronisation module 20 o Realtime alerts to administration for high severity issues * Fatigue Risk Management o Fully digitised version of the current fatigue risk assessment o Realtime synchronization with web portal through synchronisation module 22 o Realtime alerts to administration in the event of a failed assessment * Toolbox o List of locally stored reference documents that can be accessed by drivers at any stage through the navigation menu. 5 o Documents updates downloaded on a predefined schedule * Web Portal Access Direct access to web portal pages from within the application. 3.2 Stage 2 10 3.2.1 Summary: Development Time: Development Cost: 3.2.2 Android Application Upgrades * Induction document completion 15 Drivers will be able to read and acknowledge their induction documents through the application. The app will notify users upon login if they have any outstanding documents. * Direct mobile access to online leave applications Drivers will have direct access to leave online leave application forms 20 3.2.3 Web Portal Upgrades * Client portal The client portal includes realtime tracking and reporting of vehicles and jobs for end users. * Online Leave Applications The client portal includes realtime tracking and reporting of vehicles and jobs for end users.

23 4.1 Flow Diagrams 4.1.1 Figure 10 is an overview flowchart of the app according to a preferred embodiment of the present invention. 4.1.2 Figure 11 is a flowchart of the Shift Itinerary Process 5 4.1.3 Figure 12 is a Notices Process 4.1.4 Figure 13 is a flowchart of the Checklist Process 4.1.5 Figure 14 ToSite Run 4.1.6 Figure 15 FromSite Run 4.2 Android Application Screen Examples 10 4.2.1 Figure 16 - App Login Screen Example 4.2.2 Figure 17 - Daily Notices Screen Example 4.2.3 Figures 18, 19 - Prestart Checklist Screen Example 4.2.4 Figure 20 - Fatigue Risk Assessment Screen Example 4.2.5 Figure 21 - Pickup Information Screen Example 15 4.2.6 Figure 22 - Daily Alcohol Check Screen Example 4.2.7 Figure 23 - Leave Application Screen Example 4.3 Web Portal Screen Examples 4.3.1 Figure 24 - Dashboard 20 4.3.2 Figure 25 - Notification Manager 4.3.3 Figure 26 - Shift Setup Manager 4.4 Figures 27 to 29 - Database Tables 24 4.5 Glossary of terms Android The operating system running on variously branded phones (Samsung, HTC, etc.) API An Application Programming Interface is a service that allows end-user devices to communicate with a platform App A computer program that runs on mobile phones Database A server that manages and stores large amounts of information Failover A mechanism designed to prevent failure by automatically switching to a backup system laaS Infrastructure as a service, this involves the renting of servers and technologies from existing companies iOS The operating system running on portable Apple brand devices Master-Detail A standard layout of data, dividing sections into a master list and detailed view Load balancing Distribution of work between multiple servers Realtime An event that happens immediately Responsive design Automatically sizing content to fit the display size Server A computer designed to manage and serve information to applications and end users Watchdog A system designed to monitor an application or server for reliability USE FOR THE INVENTION The above description identifies at least one specific, substantial and credible 5 use for the invention. In particular, the above description identifies a method and system for management of a fleet of vehicles. In compliance with the statute, the invention has been described in language more or less specific to structural or methodical features. The term 10 "comprises" and its variations, such as "comprising" and "comprised of" is 25 used throughout in an inclusive sense and not to the exclusion of any additional features. It is to be understood that the invention is not limited to specific features shown or described since the means herein described comprises preferred forms of putting the invention into effect. 5 The invention is, therefore, claimed in any of its forms or modifications within the proper scope of the appended claims appropriately interpreted by those skilled in the art. 10 Throughout the specification and claims (if present), unless the context requires otherwise, the term "substantially" or "about" will be understood to not be limited to the value for the range qualified by the terms. Any embodiment of the invention is meant to be illustrative only and is not 15 meant to be limiting to the invention. Therefore, it should be appreciated that various other changes and modifications can be made to any embodiment described without departing from the spirit and scope of the invention.

Claims (20)

1. A method for management of a fleet of vehicles comprising operating a computer server to: 5 serve shift notices across a data network to remote computational devices of drivers of the vehicles; monitor for acknowledgments of receipt and acceptance of the notices from each of the drivers; and record said acknowledgements for inspection by an administrator 10 of the fleet.

2. A method according to claim 1, including operating the computer server to facilitate specification by the administrator of audience scope for the notices. 15

3. A method according to claim 2, wherein the audience scope may be one or more of: general distribution; driver specific; 20 vehicle specific; shift specific; or time based.

4. A method according to any one of the preceding claims including 25 operating the computer server to serve shift itineraries to the driver devices.

5. A method according to claim 4, wherein each shift itinerary comprises information specifying steps to be complete by a respective driver 30 during the shift. 27

6. A method according to claim 5, including operating the computer server to monitor for confirmation that each step is completed sequentially. 5

7. A method according to claim 6, including operating the computer server to determine that each of the drivers has complied with an alcohol check requirement.

8. A method according to claim 7, including operating the computer 10 server to prompt drivers to enter on their device a passenger number for the driver's fleet vehicle indicating a number of passengers aboard the vehicle.

9. A method according to any one of the preceding claims, including 15 operating the computer server to determine compliance with the alcohol check requirement in response to the driver indicating that at least one passenger has boarded said fleet vehicle.

10.A method according to claim 9, including operating the computer 20 server to issue an alert in response to the driver failing to comply with the alcohol check requirement.

11.A method according to any one of claims 1 to 4 including operating the computer server to determine geographical positioning data 25 associated with the vehicle.

12. A method according to claim 11, including presenting appropriate pages of shift itineraries to the driver based on the determined geographical positioning data. 30

13.A method according to any one of the preceding claims, including operating the computer server to require drivers to enter pre and post shift odometer readings of their fleet vehicles. 28

14.A method according to any one of the preceding claims including facilitating administrator specification of when forms and processes are to be served to said devices and time frames in which driver completion of forms is required. 5

15.A method according to claim 14, wherein the administrator is able to specify that the forms and processes are to be presented to a driver pre-shift, post-shift, or upon a specified vehicle passenger count being reached. 10

16.A method according to any one of the preceding claims, including operating the computer server to administer a driver vehicle check.

17.A method according to claim 16, including operating the computer 15 server to log driver feedback for said vehicle check.

18.A method according to claim 17, including notifying drivers that a vehicle is not to be used based on said feedback for said vehicle check. 20

19.A computer server that is programmed to implement a method according to any one of the preceding claims.

20.A software product in the form of a non-transitory computer readable 25 medium, such as an optical or magnetic or solid state disk, bearing machine readable instructions for a computer server to implement a method according to any one of claims 1 to 19.