WO2015076915A1 - Système d'attribution et procédé de déploiement de ressources - Google Patents

Système d'attribution et procédé de déploiement de ressources Download PDF

Info

Publication number
WO2015076915A1
WO2015076915A1 PCT/US2014/055396 US2014055396W WO2015076915A1 WO 2015076915 A1 WO2015076915 A1 WO 2015076915A1 US 2014055396 W US2014055396 W US 2014055396W WO 2015076915 A1 WO2015076915 A1 WO 2015076915A1
Authority
WO
WIPO (PCT)
Prior art keywords
driver
target
geographical
resource
computing device
Prior art date
Application number
PCT/US2014/055396
Other languages
English (en)
Inventor
Mashhur Zarif Haque
Original Assignee
Mashhur Zarif Haque
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US14/084,380 external-priority patent/US10181104B2/en
Application filed by Mashhur Zarif Haque filed Critical Mashhur Zarif Haque
Publication of WO2015076915A1 publication Critical patent/WO2015076915A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/08—Auctions

Definitions

  • the present invention is related generally to a driver allocation system and method, and more specifically to a system including mobile computing devices with application software capable of assigning and managing resources such as drivers, and the process to retrieve and drop off targets from locations throughout the world and drop those targets off at desired locations.
  • the existing process is costly for the requestors and the drivers alike because (1) the requestors spend a lot of time in managing the system such as but not limited to giving directions to each driver separately, VIN and Gate Pass information, and special instructions, making phone calls back and forth, (2) of thefts by unscrupulous drivers and others e.g. stolen headrest, missing books, keys, drive shift knobs, (3) drivers do not drive on clock but bill for more hours, (4) third party companies are paid for their services as a middle man, (5) accurate delivery time cannot be determined, (6) drivers are not paid for any lost receipt and (7) of inability to enforce driver accountability during vehicle transporting. Also, reporting by the drivers to reconcile the vehicle condition (e.g.
  • Condition status reports are now communicated verbally by the drivers to the requestors.
  • This verbal system has many deficiencies such as the requestor being usually very busy and multitasking may totally forget to record the problem, or may assign the problem to the wrong vehicle or wrong location in the vehicle. For example, vehicle A in actuality may pull to the right while driving; instead the requestor may assign the problem to vehicle B as being pulled to the left. Therefore, finding and repairing the problem become costly.
  • Each transporting trip is generally different from others as to such variables as the transporting distance, property value, ownership of the asset, insurance, and legal and other requirements.
  • Customization of each trip is presently accomplished by time consuming and costly manual methods. Examples of trip customization include items such as handling of assigned license plate and expenses. Involved parties frequently forget to gather necessary documents including license plates. Such lapses at the least cause costly delays and additional travels.
  • Customizable trip-by -trip features, such as handing of license plates and expenses, are not adequately addressed by the present method of assigning drivers to retrieve targets such as automobiles to be sold at auction or at remotely located dealerships.
  • a desired insurance system would also include situations where if a car, X, is transported by a driver, Y, from point, A, to point, B, the insurance policy for this trip consists of the trip from point, A, to point, B, by the driver, Y, and for the time period needed to complete the trip. Once the trip is completed the policy is terminated.
  • the stake holders in this new paradigm of insurance are the dealer (car owner), the driver and the insurance underwriter. The cost of insurance premium in this case could be shared partially by the dealer and the driver through mutually agreeable terms.
  • a desired system would also include a trip-specific electronic transmission of a digital license plate to the driver of the vehicle.
  • a method and system are provided to find, contract, organize, and manage drivers and the process of transporting vehicles by the requestor using internet based wired and wireless communication and management system.
  • the system allows for the purchase of by-the-trip insurance on-the-fly, trip-specific digital license plate transmitted to a target party by activation code, accurate record keeping of vehicle conditions, recordation and control of costs, efficient use of drivers by using real time GNSS (e.g. GPS) via mobile and fixed devices such as cell phones, tablet and desktop computers, etc.
  • GNSS e.g. GPS
  • An internet based application that will allow on a real time basis at least: (1) webcasting the need for services of driver(s) by a requestor whereby the need will be transmitted to the intended drivers or pool of drivers (2) responding to the requestor by the drivers with their terms and availability (3) accepting the terms of the drivers by the requestor (4) purchasing by- the-trip insurance on-the-fly (5) wirelessly transmitting a trip-specific digital license plate to the driver of the trip (6) executing the transportation of a vehicle or a fleet of vehicles in an optimal manner (7) recording and reporting the vehicle status before the vehicle leaves the auction gate (8) reporting and monitoring of the trip status report at any time (9) recording and reporting of expenses and drivers bills and (10) monitoring and controlling of the vehicle transportation process on a real time basis. It must be repeated here that each of the functions listed above can be accomplished on a real time basis.
  • An embodiment of the present invention may be used to coordinate drivers for an innumerable amount of purposes. Some examples include chauffer jobs or a simple errand trip request. Drivers are allocated by requestors to pick up and drop off targets, which may include anything the requestor might need. A preferred embodiment would be where the requestor is an automobile dealer and the target is a car desired for sale; however, as above, any conceivable target could be assigned to a driver for pick-up and delivery, including a passenger.
  • Fig. 1 is a diagrammatic representation of the relationships between various elements included in an embodiment of the present invention.
  • Fig. 1A is a diagrammatic representation of the relationships between various alternative elements included in an alternative embodiment of the present invention.
  • FIG. 2 is a diagrammatic representation showing in more detail the transfer of information amongst various elements of an embodiment of the present invention.
  • FIG. 3A is a first portion of a flow chart diagramming the step-by-step practice of a method embodying the present invention.
  • FIG. 3B is a second portion thereof.
  • FIG. 3C is a third portion thereof.
  • Fig. 4A is first portion of a flow chart diagramming the practice of a portion of a preferred embodiment of the present invention - namely, driver certification through use of the present invention.
  • Fig. 4B is a second portion thereof.
  • Fig. 5 is a flow chart diagramming the practice of a portion of a preferred embodiment of the present invention - namely, registering a company through use of the present invention.
  • Fig. 6 is a flow chart diagramming the practice of a portion of a preferred embodiment of the present invention - namely, applying for, requesting, and obtaining single trip car insurance.
  • Fig. 6A is a diagrammatic representation of the relationships between various elements thereof.
  • Fig. 7 is an elevational view of a digital license tag plate which may be incorporated into the practice of an embodiment of the present invention.
  • Fig. 7A is an elevational view of an alternative digital license tag plate which may be incorporated into the practice of an alternative embodiment of the present invention.
  • Fig. 8A is a screenshot of a user interface associated with the practice of a preferred embodiment of the present invention, showing a driver's user interface for accessing the various features associated with the present invention.
  • Fig. 8B is a screenshot of a user interface associated with the practice of a preferred embodiment of the present invention, showing scheduled trips associated with a driver's itinerary.
  • Fig. 8C is a screenshot of a user interface associated with the practice of a preferred embodiment of the present invention, showing trip status details.
  • Fig. 8D is a screenshot of a user interface associated with the practice of a preferred embodiment of the present invention, showing trip request settings entered by a requestor.
  • Fig. 8E is a screenshot of a user interface associated with the practice of a preferred embodiment of the present invention, showing a requestor's user interface for accessing the various features associated with the present invention.
  • Fig. 8F is a screenshot of a user interface associated with the practice of a preferred embodiment of the present invention, showing a driver search function performed by a requestor.
  • Fig. 8G is a screenshot of a user interface associated with the practice of a preferred embodiment of the present invention, showing a driver's registration options.
  • outwardly refer to directions toward and away from, respectively, the geometric center of the aspect being described and designated parts thereof. Additional examples include a mobile smart device including a display device for viewing a typical web browser or user interface will be commonly referred to throughout the following description. The type of device, computer, display, or user interface may vary when practicing an embodiment of the present invention. Drivers and couriers are the resources to be allocated using the present invention, and may often be used interchangeably, as may dealers and requestors. Said terminology will include the words specifically mentioned, derivatives thereof and words of similar meaning.
  • the overarching purpose of the present invention is to create a trip request from a requesting party 4 to a driver 6 or other resource, wherein the purpose of the trip is to collect a target and return, or deliver to a remote location, that target.
  • the trip request is automatically generated using a third-party service stored at a remote server 12. Some features may be individually selectable by the requesting party 4, or may be automatically generated, based on a number of parameters, by the remote server 12 CPU.
  • Fig. 1 shows the relationships between various elements of a driver allocation system 2.
  • a driver allocation service 5 which generally requires a central server 12 complete with CPU and data storage, a central database 14 stored within said central server, and software necessary to oversee the entire system, including sending instructions and receiving requests from the various other elements, including at least one requestor 4, one driver 6, data regarding a target 8. All of this information is shared over a wireless network 10, and via the internet.
  • the requestor 4 may be an automobile dealer or auction service that is looking for target 8 items, typically vehicles.
  • the requestor has a computer 38 capable of accessing the central server 12 and all software associated with the driver allocation system 2.
  • the requestor 4 will input or import his preferences 40 into the requestor computer 38, which will help to facilitate the selecting of drivers 6 for the acquisition of targets 8.
  • a requestor may have code(s) 42 for drive-away plates 28 which provide temporary displays of plate information, such as license plate number, expiration time or date, and the state in which the plate would be registered. This code may be transferred wirelessly over the wireless network 10 to a driver 6 who has functioning digital plates 28.
  • the requestor may have trip insurance 44 which may be associated with a particular trip.
  • a driver 6 may also have his or her own insurance 29 which would be associated with that trip. Alternatively, these insurances could each function to cover a portion of any given trip. Insurance data is transferred back and forth, and is stored in the central database, via the wireless network 10.
  • the requestor's payment account 46 must be associated with the driver allocation system 2 such that drivers are paid automatically upon successfully and satisfactorily completing a trip.
  • each driver 6 is associated with a mobile computer 16 such as a smart phone or tablet computer.
  • This computer includes data storage capable of storing the mobile application software 18 which allows the driver to interact with the central server 12, the requestor 4, and all other aspects of the driver allocation system 2.
  • the driver's preferences 20, including the driver's certifications, driving experience, general location, and other relevant details are also stored on the mobile device and are associated with the application software 18.
  • the mobile computer 16 should also include a Global Navigation Satellite System
  • GNSS GNSS
  • GNSS GNSS
  • the mobile computer 16 should also include a camera 24 or other device for scanning a vehicle's identification number (VIN), logging receipts for expenses, and for keeping record of the vehicle's condition such as by photographing dents, scrapes, and other defects. Photographs of starting and ending mileage would also be logged using the camera.
  • the scanning function also allows for files or data to be exploded and used for different file formats.
  • GUI graphical user interface
  • the driver may have digital license plates 28 which receive codes from a requestor 4 via the driver's mobile computer 16. This allows temporary licensure of a vehicle during the transportation process only, after which the temporary code expires and the digital tag may be reused. More detail on the digital tags can be found below and in Figs. 7 and 7A.
  • the driver may have his or her own insurance 29 associated with jobs accepted by the driver 6.
  • This insurance may be typical insurance; however, preferably the insurance would be trip-by -trip specific and would be estimated and paid for on a per-trip basis. More information on how trip-by-trip insurance would function can be found below.
  • the target 8 typically a vehicle identified by the requestor 4 for pickup, has a starting location 30, a starting condition 32, associated vehicle data 34 (e.g. a VIN), and a target ending location 36 and associated ending condition 37.
  • Vehicle condition includes basic information, such as the odometer reading of the vehicle, and also more important information, such as the condition of the vehicle externally and internally. If the ending condition 37 differs from the starting condition 32 in more than minor ways, there may need to be an insurance report made or payment may be withheld from the driver until the vehicle is repaired.
  • more than one target 8 may be designated to the driver(s) at a time.
  • a processor belonging to either the central server 12 or the requestor's 4 computer 38 will calculate an optimal route and/or an optimal amount of additional drivers 6 needed to complete the task of acquiring all targets 8 and moving those targets 8 to their respective dropoff destinations 36. Expense and time are necessary components to this calculation.
  • the requestor 4 will be notified how many drivers 6 and/or how many trips are going to be needed such that the requestor 4 can allocate the appropriate drivers 6 to the appropriate targets 8.
  • the system may further optimize the trips by the seating capacity of a number of vehicles, including each target 8 if the target is a vehicle. These factors are all computed to produce the optimal result for acquiring the target(s) 8.
  • Each driver 6 may also be assigned by the central server 12 processing the location(s) of each driver and the distance between driver(s) 6 and target(s) 8. Each driver verifies the target by scanning the ID data 34 (e.g. VIN) when the driver 6 reaches the target 8 start location 30. In the case where a VIN 34 is scanned, it may have optionally been scanned by the initiating / selling party previously. The second scan by the driver 6 verifies that this is the target 8 to be moved and authorizes the transaction. [0050] In the case of multiple vehicles, multiple targets, and/or multiple drivers, the requestor has the ability to track each and every target, driver, and vehicle at once using the same computer 38.
  • ID data 34 e.g. VIN
  • a "tracking view” allows the requestor 4 to review status updates and geographic positioning information on each driver 6 and target 8 as they are reported via the driver allocation service 5.
  • a map may be pulled up on the display of the requestor's computing device 38 which actively tracks the geographic GNSS position of each driver 6 actively being tracked and/or employed by the requestor 4 for a trip request.
  • the requestor 4 may select the indicator on the display for one driver 6, and the display will update showing the details of that particular driver, including details about the vehicle and/or target associated with the river, the estimated time of arrival for the driver, the status of the target, and other relevant details.
  • a report may be generated by the central server CPU 12 and delivered to a requesting party. For example, if a requestor 4 requests a report, the report sent to him may include an analysis of the trip including total expenses of all drivers, other payments, vehicle statistics, such as miles-per-gallon and average speed, and other valuable data. Similar data may be requested by a driver 6 and used to file tax documents such as a standard 1099 form.
  • drivers 6 When drivers 6 register with the driver allocation service 5 using their mobile computing devices 16, they may have the option of purchasing or renting the digital plates 28 which will be sent to the driver 6 at the address provided by the driver 6 via the driver's profile. Additionally, a pre-paid or pre-loaded debit card may be sent to the driver. This debit card may be reloaded by the driver 6 for purchasing supplies or other services, and it may be recharged when the driver 6 is paid by a requestor 4 from the requestor's payment account 46.
  • Fig. 1A demonstrates a similar setup wherein a third party driver company 7, who employs or has readily available a number of drivers 6.1, 6.2, 6.n, for performing the same tasks as discussed above.
  • the company 7 requires additional relationships to be formed via the wireless network 10, and has its own set of information and requirements for association with an alternative driver allocation system 3. Functionally the system operates the same as discussed above.
  • the driver company 7 has its own computer 50 including data storage and CPU for accessing its own version of application software 52 allowing the driver company 7 to interact with drivers 6 and requestors 4.
  • the driver company's preferences 54 including credentials and driver-related data, are stored on the company's computer 50 and would likely also be contained in the central database 14.
  • the driving company may have its own set of digital plates 56 for use by any number of drivers 6.1, 6.2, 6.n.
  • the driving company 7 may have its own insurance 58, preferably a trip-by-trip insurance, which can be applied to any or all trips by the company's drivers.
  • a similar scenario to that shown in Fig. 1A includes a lead driver who is assigned with finding additional drivers 6n for picking up additional targets 8 or for following the lead driver in a follow-car.
  • the lead driver may be invited to the job by the requestor 4, but the additional positions may be picked by the lead driver 6 himself, if the requestor 4 has set up the system to allow for this type of hiring.
  • This is ideal in a situation where the requestor 4 may have one suitable driver 6 located in an area, but does not have information on additional drivers 6n.
  • the lead driver 6 is contacted by the requestor 4, and then proceeds to invite additional drivers 6n to use the mobile software application 18 and join the lead driver 6 on the job.
  • a "trip manager” may be employed or otherwise retained by the requestor 4 to fill the roll, thereby removing steps from the requestor 4 and adding them to the trip manager.
  • the trip requestor 4 may set up a trip request and specify the target 8, but leave the assigning of drivers or drive teams to the trip manager.
  • Fig. 2 shows in slightly more detail how data elements are transferred between the requestor's computer 38, the central server 12 and database 14, through the wireless network 10, and to a driver's 6 mobile computer 16.
  • the data exchange is intended to link the requestor 4 with the best available drivers 6 that suit the requestor's 4 needs, while ensuring that drivers 6 are presented with optimal arrangements for picking up targets 8.
  • Figs. 3 A - 3C demonstrate a step-by-step method of practicing the present invention. It should be noted that these steps are not exhaustive of all of the steps that may go into the practice of the present invention, but instead represent one example of how the present invention may be practiced.
  • the method starts at 100 as shown in Fig. 3A.
  • the central database 14 is loaded with requestors who have registered at 102, and is further loaded with certified drivers at 104. Third party companies who register for use of the present invention would similarly be loaded into the database.
  • a requester designates a target or targets to be picked up at 106.
  • the target's information is then added to the database at 108.
  • the system 2 locates the target at 110 and assigns geographical coordinates to the target which allows drivers, requestors, or other users to see where the target's present location is.
  • the requestor may manually enter the target's location, or the information may be loaded by scanning a vehicle's VIN with a mobile computing device having GNSS positioning technology or other location equipment integrated into it.
  • This may include the type of target being picked up, the number of targets being picked up, the final drop-off location, the required date and time at which the target needs to be dropped off, various driver qualifications, or any other necessary job parameters that the requestor deems necessary to retrieve the target.
  • the requestor determines at 1 14 whether or not to select drivers or driver companies from a preferred list, or whether to allow the system 2 to generate a list of drivers based on job parameters and target location. If the requester chooses to use a preferred list of drivers, the system will access a list of preferred drivers at 116 that the requestor has previously set up based on previous jobs or previous work experience. Otherwise the system will generate a list based upon the job parameters. Either way, a list of drivers is generated at 118.
  • Fig. 3A The list of steps of Fig. 3 A is further continued in Fig. 3B where a trip request is generated.
  • the system database is updated at 120 with drop-off locations related to the target or targets assigned for pickup by the requestor. If the requestor has trip insurance at 122, then the trip insurance may be activated at 124 if the requester decides to utilize the trip insurance.
  • this trip insurance would function during the specified trip only and then would be deactivated.
  • a cost would be generated based upon the job parameters, the target, the driver(s) involved, and other related details. More about the trip-by-trip insurance generation is discussed below and at Fig. 6.
  • the requestor can choose to activate that code at 126.
  • the code is activated at 128, and any driver who is ultimately used in the trip would need to have a digital license plate capable of receiving the digital license plate code. If multiple drivers are required, multiple plate codes may be needed.
  • driver or drivers selected from the list generated at step 1 18 will be sent the driver instructions and other relevant details at 132.
  • the driver or drivers are asked to accept the request at 134. If a driver rejects the request, the next driver in the list will be selected at 136. Alternatively, the system may be required to draw on drivers outside of the generated list once that list is exhausted.
  • any additional data will be relayed to the driver(s) and notification that the driver is "on the job" is sent at 138.
  • the driver may be guided to the target's location at 140 using maps or step-by-step directions determined by the driver's mobile computer 16.
  • a check is performed at 142 whether the driver has reached the target. Directions are provided at 140 until the target is reached at 142.
  • the driver's status that the target has been reached is logged at 144, and the target's status is also logged at 146.
  • This step includes scanning a VIN for a vehicle, photographing the target for damage, odometer reading, or other relevant details, or otherwise inputting details about the target's condition into the driver's mobile computer. All of this information is saved in the central database 14 and is uploaded to the requestor 4 and any third party users who have access to view this information, such as the ultimate purchaser of the target from the requestor.
  • Fig. 3C The list of steps of Fig. 3B is further continued in Fig. 3C where the driver is guided to the drop-off destination at 148 using the driver's mobile computer 16.
  • the system constantly performs a check to determine whether the destination has been reached at 150. If the destination has not been reached, the driver has the opportunity to log expenses at 152.
  • Expenses are logged at 154, and may include hotel stays, food, fuel, vehicle repairs, insurance costs, or any other relevant details. These may be input using a camera attached to the mobile device photographing receipts, or the data may be entered manually.
  • Trip reports include changes to the status of the target, key destinations reached, updates in estimated time of arrival, or any other detail that is deemed relevant. This information is transferred on to the requestor and may also be viewable by third party users.
  • the status of the target is verified and logged at 168, ensuring that the quality and other relevant details of the target are satisfactory to the requestor and/or to a third party buyer. If everything is satisfactory, payment is automatically wired through the system from the requestor to the driver at 170. Payment may be automatically withdrawn from the requestor's payment account 46 and into the driver's bank account. Expenses incurred during the trip would also be reimbursed through this payment.
  • the requestor and other third parties have the opportunity to assign a rating to the driver at 172.
  • This may also include assigning the driver to a "favorite" or "preferred" driver's list, if the driver is not already on such a list. Alternatively, the driver may be removed from the list for poor performance.
  • the practiced method ends at 174. [0072] As indicated above, this is a mere example of how someone may practice an embodiment of the present invention. Steps may be skipped or added in actual practice of the present invention. Necessary steps may have been omitted to simplify the disclosure of the method of practicing the present invention, but those steps would be included in the actual practice of the invention.
  • Figs. 4A and 4B demonstrate a step-by-step method of practicing an element of the present invention, namely: certifying a driver with the driver allocation system through the driver allocation service 5.
  • the certification process starts at 200 with a driver who has a mobile computer device 16 which satisfies the requirements of the driver allocation system as outlined previously at Fig. 1.
  • Step 202 indicates that a driver may be invited to use the software associated with the driver allocation system by a third party or another driver who already has access to the system.
  • the software allows a driver to interact with the driver allocation service 5 and various requestors/dealers. A driver who has access to these features may send a message to another driver who is not yet certified and registered with the driver allocation system.
  • the driver may review the invite at 204 and may also have the option of viewing a sample of the system at 206. The sample view would be the actual results of a trip performed by the third-party driver or requestor who sent the initial invitation to the driver at 202.
  • the driver Whether or not an invite has been received, the driver must download the associated application software at 208 in order to become certified within the driver allocation system 2. This requires access to a wireless network with the driver's mobile computer and downloading of the application software to the data storage element of the mobile computer. The application is then loaded onto the mobile computer device at 210, at which point the driver may set up their user profile at 212.
  • This user profile is discussed in more detail elsewhere, but generally includes the name and location of the driver, the driver's experience, the driver's preferred job types, and other relevant information about the driver.
  • the certification process is intended to ensure certainty in the quality of drivers available for hire by various requestors and other parties. Therefore, the most important features of the certification process revolve around the driver's driving history.
  • the first step in certifying the driver's history is to enter the driver's license data at 214, which may include the license number, the date of expiration, the date acquired, and the state where the license was obtained. This data is transmitted to the central server via the wireless network and a check is performed at 216 to determine whether the license data is valid. If the check comes back as "not valid," the certification process is immediately failed at 218, and the certification process ends at 220. If the driver's license data is valid, additional checks are performed for certification.
  • a credit check is performed at 222. Again, a check is performed by the central server computer to determine whether the driver passes the credit check at 224. If not, certification fails at 242 and the process ends at 248.
  • a video reaction test is accessible via the application software.
  • the driver may choose to activate this test at any time, and the test is loaded at 238.
  • the test goes through a video program on the driver's mobile computer via the GUI display, and the driver will react to various elements of the video test.
  • the results of the test will be analyzed by the central server, and a pass/fail check is taken at 240.
  • a pass/fail check is taken at 240.
  • the certification process fails at 242 and ends at 248. If each and every check is passed, then the driver is notified that they have passed certification at 244.
  • An expiration notice is provided to the driver at 246. This expiration notice tells the driver how long their certification is good for. The driver will be required to recertify at the expiration of the certification.
  • the certification process ends at 248.
  • Certification ensures that not just any one can be registered with the driver allocation service 5.
  • the certification process provides a pool of drivers which requestors, dealers, and other parties can be confident will be able to safely and reliably transport the target item, such as a vehicle, to a target destination. This process will also be necessary to insurance underwriters who are providing trip-by-trip driving insurance to the drivers and/or the requestors.
  • driver allocation system 3 may register with some version of the driver allocation system 3. These parties have contact with multiple drivers, who would also have to be individually registered and certified with the driver allocation system 3 through use of mobile computing devices linked to the driver allocation service over a wireless network.
  • Fig. 5 demonstrates a step-by-step method of practicing an element of the present invention, namely: registering third-party driving companies with the driver allocation system 3 as depicted in Fig. 1A.
  • the process starts at 260.
  • a driver, requestor, or other party who has access to these features may send a message to a third-party driving company who is not yet certified and registered with the driver allocation system. If the invite is received at 262, the driver may review the invite at 264 and may also have the option of viewing a sample of the system at 266. The sample view would be the actual results of a trip performed by the third-party driver or requestor who sent the initial invitation to the company at 262.
  • the third-party company may download the appropriate application software at 268.
  • This software may be downloaded to a mobile computing device similar to those used by the various drivers discussed above (e.g. "smart phone” devices).
  • the software may also be downloaded to a stand-alone personal computer (e.g. laptop or desktop computer).
  • the software application is loaded at 270 and a profile is set up for the third party company at 272. This includes all relevant details of the company, including the general region where the company operates, how many drivers the company has at its disposal, the company's Federal Employee Identification Number (FEIN), Dunn & Bradstat Number (D&B)], licenses, and other relevant features of the company.
  • FEIN Federal Employee Identification Number
  • D&B Dunn & Bradstat Number
  • Driver data of the individual drivers hired by the company may be input at 272. This can include a large dump of data collected by the driving company on behalf of all of its drivers which would be similar to the process discussed above and at Figs. 4A and 4B.
  • Another novel feature which goes hand- in-hand with the basic concept of the driver allocation system 2 discussed above includes a trip-by-trip specific insurance feature. This feature allows drivers, third-party companies, and requestors to apply for and receive insurance limited to a single trip as set-up through the driver allocation system. Several features come into play in order to create and obtain this insurance, so a preferred embodiment would include a method where this insurance is procured from third-party insurance underwriters through the use of the driver allocation service 5.
  • the process for obtaining single-trip or trip-by-trip insurance starts at 300.
  • the user's status is input at 302. This includes identifying the user as a driver, a dealer or otherwise a requestor, a third party company, the auction site claiming the target, or some other party.
  • the number of targets to be transported is entered at 304. If multiple targets can be driven in one vehicle, then only a single source of insurance may be necessary. However, if each target comprises a separate vehicle, multiple instances of single-trip insurance will be required.
  • the value of each target is input at 306.
  • the status of each driver to be used is input at 308 (e.g. the name and other profile data of each driver).
  • the driver's data or certification status is input at 310.
  • the region, time frame, and other trip information is input at 312. All of this data is used by the insurance underwriter to determine the risk of the particular trip and therefore formulate a cost for that insurance.
  • the data is compiled and sent at 314 and analyzed by the underwriters at 316.
  • the underwriters would come up with an estimated cost for the insurance, as well as other data relevant to the insurance for that particular trip (e.g. deductible amount). This cost is sent to the user at 318.
  • the user must accept or reject the insurance offer at 320. If the user rejects the offer at 320, the user will have the opportunity to search additional underwriters at 321 for additional insurance quotes. If the user elects to send the request to additional insurance underwriters, the data is re-compiled and sent at 314, analyzed by the new underwriter at 316, and a cost again is provided to the user at 318.
  • the insurance is activated as the trip is started at 322.
  • the trip is driven by the relevant driver(s) at 324, until the target destination is reached at 326, where the insurance deactivates automatically.
  • the process ends at 328.
  • Fig. 6A diagrammatically shows the relationship between drivers 6, requestors 4, the driver allocation service 5, and the insurance underwriter(s) 338.
  • Data including target value 330, driver status 332, location/route 334, and the requestor's status 336 are optionally sent to the central server 12, which are then relayed to the insurance underwriter 338.
  • the underwriter reviews the data and returns a quote to the requestor or driver requesting insurance.
  • other parties could also procure insurance, such as the ultimate purchaser of the target 8.
  • FIGs. 7 and 7A demonstrate two alternative embodiments of a digital license plate which may be used as part of the driver allocation systems discussed herein.
  • Fig. 7 shows a preferred embodiment digital license plate 28 which generally includes a frame 64 with mounting holes 66 which allow the frame to be mounted to a vehicle via mounting screws like a typical license plate.
  • a digital screen 68 is located in the frame, which contains information such as the license plate number, the expiration date (and time) of the digital plate, and the state, county, and other necessary information.
  • Each license plate requires a power source.
  • a preferred embodiment would use a lithium-ion battery 62 connected to a solar array 60 for powering and recharging the tag license plate.
  • the license plate battery may also be recharged by plugging it into a power outlet with a standard adapter (not shown).
  • Other options include plugging the license plate directly into the vehicle's power system, either directly or through a removable wire with a universal serial bus (USB) port or other outlet plug.
  • USB universal serial bus
  • Each license plate will also include a microcomputer 70 including a CPU, data storage element, and external connectors such as USB.
  • a Wi-Fi and/or Bluetooth antenna 72 is used to communicate data to and from a mobile computing device associated with the license plate, such as the driver's 6 mobile computer 16. This allows data to be transmitted over the wireless network to the driver's mobile computer 16, and wirelessly re-transmitted to the digital tag.
  • a digital drive-away plate code 42 sent by a requestor 4 will therefore be associated with the digital license plate 28 and the display will show the necessary information.
  • Fig. 7A shows an alternative embodiment digital license plate 428 which is affixed to the rear window of a car via four suction cups 466.
  • the display 468 shown here is a light-emitting diode (LED) board with a plurality of large 474 and small 472 LED lights for displaying simple yet informative displays. The display must at least be able to show
  • alphanumeric license plate codes and the associated city and county information.
  • This alternative embodiment also shows a toll-paying device 476 which may receive additional codes for use with automatic toll stations used around the country, such as E- ZPass provided by the E-ZPass Interagency Group of Wilmington, DE. As with the digital license plate itself, the code for these passes would be transmitted to the device via the driver's mobile computer, and would expire at the end of the trip.
  • This toll-paying communications device 476 could alternatively be included in the driver's mobile computing device 16. Charges could automatically be sent to the Requestor's account, or any other party's account, as the toll fees are paid through the toll-paying device 476.
  • the digital plate 28, 428 will tie itself to the mobile computing device 16 of the driver and will key off of digital plate codes being relayed through the mobile computing device. If signal is cut off from the mobile computing device, the digital tag may either be cut off as well or may optionally run based upon the last set of instructions it had received (e.g. when to expire).
  • license plates could be useful in several industries, including for use in test drive scenarios, rental car services, or for one-time rental by a single driver. These license plates should function interstate, and may optionally belong to any individual in the chain, including the individual drivers, the driving companies, or the purchaser of the target.
  • the display of the license plate may also show what type of drive is being performed with the vehicle associated with the plate.
  • the tag may indicate that the vehicle is currently "in transit” delivering a target or the vehicle itself to a designated location.
  • the tag may also indicate a "test-drive” for use with automobile dealers, or a "one-way delivery.”
  • Other types of trips may also be displayed, such as if the vehicle is being used as a taxi service orariesr.
  • the display can display as much detail about the trip as the requestor or driver determines is necessary, or to comply with state law.
  • the display may also feature the time remaining on the duration of the digital tag, and when the tag code expires the display will either go blank or display "EXPIRED” or a similar message across its face.
  • Figs. 8A-8G demonstrate several features of a user interface associated with the driver allocation service 5 that would be included in the software associated with a driver's mobile computer device 16, the requestor's computer 38, or any other party's computer when utilizing the features of the present invention.
  • Fig. 8A for instance shows a user interface of a driver's "dashboard.” This view would be the first view a driver would see when opening the associated software application on his or her mobile computing device. Any and all features that the driver would need to interact with the driver allocation system, including the driver allocation service 5, can be linked to from this view. For example, the driver may update his driver profile by selecting the "Profile" link on the dashboard.
  • Fig. 8B shows a user interface of a driver's itinerary, including details about upcoming trips and the option to begin a trip or to cancel a trip. Additional details about the trip, such as details about the target, can be found by selecting the "details" tab.
  • Fig. 8C shows a user interface of a driver's trip status.
  • the driver may select or deselect various options during a trip.
  • the driver may scan or manually input the VIN.
  • the license plate number may be entered manually or retrieved from a drive- away license plate code sent by a requestor.
  • the miles of the trip may be calculated using GNSS positioning or otherwise calculated.
  • the driver may even designate his vehicle as the "target car” or the "chase car,” depending on the driver's actual status.
  • Each trip request is
  • Fig. 8D shows a user interface of a requestor's trip status.
  • There are various options available for setting up a trip request such as which drivers will be asked to perform the trip and the duration for the request to stay alive before responses are needed.
  • Fig. 8E shows a user interface of a driver's "dashboard.” As with the driver, various options are available to the requestor at this point.
  • Fig. 8F shows a user interface of a driver search by a requestor. This shows even more detailed options available to a requestor than those shown in Fig. 8D, such as the ability to search directly by a known driver's name.
  • Fig. 8G shows a user interface of a driver's registration. This registration could also be submitted by a third-party driving company on behalf of its drivers. The driver can input details about what types of jobs he would be willing to perform, and may upload drivers license information, a resume, an insurance policy, and other relevant documents. Everything uploaded would be stored in the central database and be accessible by requestors searching for drivers.
  • each trip may be associated with a unique code.
  • Third parties such as the buyer or seller of the target, may access the driver allocation service 5 via their own computer or mobile smart device. These parties would need to be invited to track the trip progress by the Requestor, the Driver, or another party who is controlling the trip and delivery. These parties would only receive minimum information about the trip, such as where the driver and/or target are located at a given time, and when the target arrives at its destination. Multiple targets could also be tracked by individual or multiple third parties in this way.
  • a driver 6 or team of drivers can deliver a rental car or truck to a target location.
  • the vehicle may be packed with supplies or instructions per a trip request set up using the driver allocation system 5.
  • the target or vehicle may be upsold on a commission basis.
  • the driver or other party may e-sign contracts on a mobile computing device 16, and leave the target at the location.
  • the party receiving the target (e.g. the renting party) may e-sign using the driver's mobile device 16.
  • the requestor 4 likely a vehicle dealer, creates a trip request using the driver allocation service 5.
  • An option is available to create a "rental customer.”
  • a reservation and/or confirmation identification number is generated by the central server 12 and sent to the requestor and/or the renting party. The identification number is tied to the customer's name, delivery address, phone number, and other information.
  • An option for providing additional supplies that the renting party requests may also exist. This may require data to be sent from the renting party to the requestor prior to the transaction, or in response to the requestor's initial generation of the trip request.
  • the rental customer may access the driver allocation service 5, or an alternative service, using a desktop or mobile computing device.
  • the trip status of the vehicle may be monitored by the rental customer, and may indicate via the service when they have reached the target vehicle, or conversely, when the vehicle reaches them.
  • a check-list may pop-up on the display of the rental-party's computer. Examples of tasks to be checked off include recording the fuel level, odometer, and status of the vehicle, including damage to the vehicle. These recordings can be made by taking pictures of gauges or vehicle damage and sending them via the computer network to the allocation service and/or the requestor.
  • the rental customer may also be prompted via the allocation service to purchase supplies, insurance, and other optional features, and may designate additional authorized drivers to drive the rental vehicle.
  • the customer may e-sign accepting payment of these options using their computer and send this information to the requestor.
  • Payment may also be sent over the computer network by tying directly into the customer's payment account. The customer would likely indicate their trip status via the same allocation service as they drive the vehicle from a starting location to a target location or temporary stop. All of this information would be sent back to the dealer who may monitor the location of their vehicle at any time.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Strategic Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Development Economics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Finance (AREA)
  • Accounting & Taxation (AREA)
  • Marketing (AREA)
  • Human Resources & Organizations (AREA)
  • Game Theory and Decision Science (AREA)
  • Educational Administration (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

La présente invention concerne un système et un procédé permettant d'attribuer des conducteurs à des cibles fournies, telles que des automobiles. Ces cibles sont ensuite transportées jusqu'à une destination de livraison souhaitée. L'ensemble du système est automatisé, de telle sorte qu'un demandeur peut louer des conducteurs qui sont certifiés par le système et satisfont des exigences associées à la cible, telles qu'un permis de conduire en règle et l'emplacement du conducteur par rapport à la cible. Le système est activé par une application mobile basée sur Internet qui est conçue pour mettre en correspondance des conducteurs individuels avec des concessionnaires automobiles, des salles de vente aux enchères, des sociétés de transport routier et d'autres sociétés et individus ("demandeurs") cherchant à déplacer des automobiles, des biens, des services, des taches, etc. d'un emplacement à un autre. Le système a été conçu pour trouver, organiser, et gérer des conducteurs et tous les aspects du voyage en temps réel et pour réduire le coût du système existant.
PCT/US2014/055396 2013-11-19 2014-09-12 Système d'attribution et procédé de déploiement de ressources WO2015076915A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US14/084,380 2013-11-19
US14/084,380 US10181104B2 (en) 2013-07-31 2013-11-19 Allocation system and method of deploying resources

Publications (1)

Publication Number Publication Date
WO2015076915A1 true WO2015076915A1 (fr) 2015-05-28

Family

ID=53179991

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2014/055396 WO2015076915A1 (fr) 2013-11-19 2014-09-12 Système d'attribution et procédé de déploiement de ressources

Country Status (1)

Country Link
WO (1) WO2015076915A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017132447A1 (fr) * 2016-01-29 2017-08-03 Driverdo, Llc Système de planification de trajet
US10607192B2 (en) 2016-08-25 2020-03-31 Ford Global Technologies, Llc Methods and apparatus for autonomous vehicle scheduling

Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5122959A (en) * 1988-10-28 1992-06-16 Automated Dispatch Services, Inc. Transportation dispatch and delivery tracking system
US20030120526A1 (en) * 2001-10-16 2003-06-26 Jonathan Altman System and method for managing booking and expensing of travel products and services
US20060059023A1 (en) * 2002-08-02 2006-03-16 Alex Mashinsky Method system and apparatus for providing transportation services
US20080156869A1 (en) * 2003-10-17 2008-07-03 Carr J Scott Method and System for Monitoring and Providing Notification Regarding Identity Document Usage
US20080195428A1 (en) * 2007-02-12 2008-08-14 O'sullivan Sean Shared transport system and service network
US20080254417A1 (en) * 2007-04-12 2008-10-16 Farzan Mohamed Driver training system
US20080275819A1 (en) * 2004-10-15 2008-11-06 Paul Rifai System and Method for Transaction Payment in Multiple Languages and Currencies
WO2010062899A1 (fr) * 2008-11-26 2010-06-03 Visible Insurance Llc Customisation et adoption dynamique d’assurance
US20130066667A1 (en) * 2007-01-08 2013-03-14 Gokhan Gulec Wireless Vehicle Valet Management System
US20130179205A1 (en) * 2012-01-10 2013-07-11 Eduard SLININ Systems and methods for optimizing transportation resources
US20130317693A1 (en) * 2012-05-23 2013-11-28 Global Integrated Technologies, Inc. Rental/car-share vehicle access and management system and method

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5122959A (en) * 1988-10-28 1992-06-16 Automated Dispatch Services, Inc. Transportation dispatch and delivery tracking system
US20030120526A1 (en) * 2001-10-16 2003-06-26 Jonathan Altman System and method for managing booking and expensing of travel products and services
US20060059023A1 (en) * 2002-08-02 2006-03-16 Alex Mashinsky Method system and apparatus for providing transportation services
US20080156869A1 (en) * 2003-10-17 2008-07-03 Carr J Scott Method and System for Monitoring and Providing Notification Regarding Identity Document Usage
US20080275819A1 (en) * 2004-10-15 2008-11-06 Paul Rifai System and Method for Transaction Payment in Multiple Languages and Currencies
US20130066667A1 (en) * 2007-01-08 2013-03-14 Gokhan Gulec Wireless Vehicle Valet Management System
US20080195428A1 (en) * 2007-02-12 2008-08-14 O'sullivan Sean Shared transport system and service network
US20080254417A1 (en) * 2007-04-12 2008-10-16 Farzan Mohamed Driver training system
WO2010062899A1 (fr) * 2008-11-26 2010-06-03 Visible Insurance Llc Customisation et adoption dynamique d’assurance
US20130179205A1 (en) * 2012-01-10 2013-07-11 Eduard SLININ Systems and methods for optimizing transportation resources
US20130317693A1 (en) * 2012-05-23 2013-11-28 Global Integrated Technologies, Inc. Rental/car-share vehicle access and management system and method

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017132447A1 (fr) * 2016-01-29 2017-08-03 Driverdo, Llc Système de planification de trajet
US10304027B1 (en) 2016-01-29 2019-05-28 Driverdo Llc Trip scheduling system
US11100451B2 (en) 2016-01-29 2021-08-24 Driverdo Llc Trip scheduling system
EP3933729A1 (fr) * 2016-01-29 2022-01-05 Driverdo, LLC Système de planification de trajet
US11562316B2 (en) 2016-01-29 2023-01-24 DriveDo LLC Trip scheduling system
US11694151B2 (en) 2016-01-29 2023-07-04 Driverdo Llc Trip scheduling system
US10607192B2 (en) 2016-08-25 2020-03-31 Ford Global Technologies, Llc Methods and apparatus for autonomous vehicle scheduling
US11756004B2 (en) 2016-08-25 2023-09-12 Ford Global Technologies, Llc Methods and apparatus for autonomous vehicle scheduling

Similar Documents

Publication Publication Date Title
US11938872B2 (en) Digital vehicle tag and method of integration in vehicle allocation system
US10181104B2 (en) Allocation system and method of deploying resources
US11562316B2 (en) Trip scheduling system
US20220351136A1 (en) Predictive analytics for transport services
US11715143B2 (en) Network-based system for showing cars for sale by non-dealer vehicle owners
US20160117638A1 (en) Systems and methods for dynamic managment of object transmission
US20140188750A1 (en) Method For Shipping
US20080097663A1 (en) Client management apparatus
US20150039366A1 (en) Mobile application for automobile business to manage driver-based transporting of vehicles
US20190279142A1 (en) VinVerifEye
US20230351316A1 (en) Method and system for automated vehicle transportation
WO2016040808A1 (fr) Étiquette numérique de véhicule et procédé d'intégration dans un système d'attribution de véhicule
WO2015076915A1 (fr) Système d'attribution et procédé de déploiement de ressources
US20220277273A1 (en) Commercial roadside repair and rapid delivery staffing dispatch system

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14863826

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14863826

Country of ref document: EP

Kind code of ref document: A1