RU2744983C2 - System and method for adaptable to specific needs pre-planned dispatching of transportation services - Google Patents

Abstract

FIELD: computer technology.

SUBSTANCE: invention relates to the area of computer technology for transportation services. The clients and service providers may create lists of favorites, preference lists and blacklists based on their feedback with each other which allows the clients to receive service from their favorite providers and vice versa and to prevent servicing between clients and service providers if they are blacklisted. Clients and drivers may also agree on a price for the requested service based at least partially on supply and demand. This method enables automated planning of transportation services wherein service requests are received and are planned automatically depending on the agreement with the partner driver using a dispatching service system on a micro level without direct involvement of a dispatcher.

EFFECT: simplified pre-planning of transportation services and delivery depending on estimated readiness of drivers and compatibility thereof with specific clients.

30 cl, 10 dwg

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority under Provisional US Patent Application No. 62 / 399,129, filed September 23, 2016, US Provisional Patent Application No. 62 / 505,626, filed May 12, 2017, and is a partial continuation of Regular US Patent Application No. 15 / 239,783 (hereinafter referred to as the '783 application), filed Aug. 17, 2016, which claims priority under Provisional U.S. Patent Application No. 62 / 325,602, filed April 21, 2016, and U.S. Provisional Patent Application No. 62 / 290,778, filed 3 February 2016, the entire contents of which are incorporated herein by reference.

FIELD OF TECHNOLOGY

[0002] This invention relates generally to systems and methods for transport services, and more particularly to systems and methods for pre-scheduled transport services, in which one or more service requests are received prior to a specified departure date, are scheduled in advance, and / or are grouped depending on the driver's readiness and the driver's compatibility with specific customers.

LEVEL OF TECHNOLOGY

[0003] Transportation dispatch and scheduling software is programmed to handle a variety of variables that relate to drivers and customers, from handling service requests received from both customers and suppliers to coordinating drivers in accordance with these service requests. However, dispatch software is imperfect in terms of the types of information it collects and stores for later processing when creating schedules. Errors or conflicts can slow down processing speed and exacerbate problems, which can ultimately interfere with service. Organizing this kind of information in a database and querying it comprehensively in order to plan efficiently in advance for service requests presents many challenges, especially when systems go through one driver after another until a preliminary match is found. Once a preliminary match has been found, the driver must be contacted to see if he / she can actually provide the service. Alternatively, if a driver receives a list of previously planned trips, he / she may need to cancel one or more trips in the event of a conflict.

[0004] In conventional systems, such problems can be extremely confusing and time-consuming for the dispatcher to plan trips in advance the day before, or such problems that would require significant computing system resources. The process becomes even more complicated when cancellations of requests and changes in booking requests are taken into account, especially when there are several sections of the route for a trip (for example, taking a customer from home to a store and then back home), serving more than one customer at the same time, or when several trips are planned one after the other. Changes or cancellations of requests may require that the service request be sent back to the “dashboard” for rescheduling, often manually.

[0005] When submitting a service request, the driver may assume that he / she will be able to complete it on time, but due to an unexpected rerouting or miscalculation, it may be necessary to continue driving beyond his / her expected stopping time. Thus, dispatchers often refer drivers to service requests that are inconsistent with their timetables, and customers and drivers are sometimes forced to cancel confirmation without prior notice. Dispatchers are not always familiar with clients and may not know their preferences. Situations arise when the dispatcher directs the closest driver to the client, but this driver may not be familiar with the area or not like the client he / she is directed to. Although the driver is in the immediate vicinity and can pick up the customer quickly, the customer may be unhappy with the service. In addition, sometimes drivers who have planned the provision of a service in advance have to wait a long time for a client on the street who is not yet ready, even if the driver was directed by the dispatcher to appear at a certain time. Dispatchers cannot know, or cannot efficiently update data for a driver, as to when a customer might be ready. The provision of dispatch and transport services is a complex operation and has numerous areas for systematic improvement. Traditional service dispatch methods provide less adaptability to new service requests or service requests that change unexpectedly.

[0006] Therefore, it should be understood that improved systems and methods are needed in the art to solve these problems, optimize processes, increase driver utilization, increase efficiency, limit manual dispatch, resolve customer and driver dissatisfaction issues, provide customization options for customers and drivers with regard to pre-scheduling service requests and the use of technology enhancements for pre-planned auto-processed services.

SUMMARY OF THE INVENTION

[0007] This invention relates to various systems and methodologies of a computer-implemented planning system in advance. This summary is not intended to identify or indicate significant design features or limitations on the scope of the subject matter claimed herein. The present invention relates to methods and systems for planning in advance of transport services, in which a plurality of service requests are received in advance of a specified departure date, they are planned in advance and grouped according to the readiness of the driver and their compatibility with specific customers in order to overcome the shortcomings of the known scheduling systems and dispatching service, these methods and systems pursue at least the following objectives.

[0008] Provide a customer-tailored scheduling method and system whereby the service provider and the client are matched in the most appropriate way depending on the scheduling matrix with respect to known client preferences and known preferences and constraints of the service provider.

[0009] Provide a system capable of dynamically updating a database to display changes in preferences, settings, preferences, restrictions, customer and service provider feedback, or other information in order to provide quality services.

[0010] Provide customers with the ability to tailor parameters within the system, depending on the types of preferences available, in order to receive the best service from the most appropriate service provider.

[0011] Facilitate the development and formation of the relationship between the customer and the service provider by creating a list of favorites and a list of preferences depending on the feedback they leave in relation to each other in order to improve the quality of service and in order to provide customers with the opportunity to choose one or a select few and / or preferred service providers, with the selected service providers then receiving priority in accepting service requests from their select customers who are on their favorites lists.

[0012] Provide drivers with the ability to prioritize their favorites list in order to resolve any conflicts that arise in the planning process in advance.

[0013] Provide customers or drivers with the ability to prioritize their preference or constraint categories, as appropriate, to further resolve any conflicts that arise in the planning process in advance.

[0014] Create blacklists so that when service requests are sent from customers who put service providers on their blacklists, those service providers will be ignored.

[0015] Provide customers and service providers with an electronically embedded platform for setting or negotiating prices for requested services on their own initiative, with reference to a default price based at least in part on supply and demand.

[0016] Provide different sets of metrics to the client and / or driver to facilitate the selection of the best match for an individual service request in a convenient and efficient manner.

[0017] Simplify the micro-level dispatch system between drivers and partner drivers to significantly reduce the load on the traditional dispatch system.

[0018] Provide the ability to automatically schedule in advance a batch of service requests for one or more drivers, each of whom has set an initial setting for one or more geographic regions in which he prefers to provide services.

[0019] Facilitate the relationship between the dispatcher and drivers by displaying changes in a pre-planned service request on the dispatch web portal and in the driver's device associated with the driver to execute the service request, and dynamically updating and saving the changes to the database without any -or exchange of information in the form of a telephone call.

[0020] Provide the ability to negotiate a price for an individual service request between the customer and one or more of the best appropriate drivers.

[0021] Provide a full-service dispatching capability that includes scheduling service requests in advance, dispatching service requests, dynamically updating and facilitating changes to service requests, and providing real-time information to all parties during transport. time.

[0022] In accordance with exemplary embodiments of the invention, there is provided a computer-implemented method for custom-tailored pre-scheduling transportation dispatch. The method includes receiving from a client, via one or more computing devices, a service request for scheduling in advance, the request comprising at least one user selectable preference for the service request. A service request includes at least one of the following: pick-up time, pick-up location, drop-off time, or drop-off location. The at least one user selectable preset for a service request includes at least a driver category, which includes one of the following: favorite driver, preferred driver, or regular driver. The method further includes obtaining, through one or more computing devices, at least one driver's selectable preset preference for a service request with a selectable location or time constraint preset; automatically excluding the possibility of at least one driver from the first set of a number of drivers to receive a service request if at least one driver cannot fulfill the service request depending on at least one user selectable preset preference for a service request or depending on the client's blacklist; creating at least one indicator associated with a second set of the specified number of drivers, which corresponds to the data related to the service; transmitting at least one indicator to the client, wherein the at least one indicator corresponds to at least one user selectable preference for a service request; determining, at least one specified date or time, whether at least one user selectable preset for a service request matches at least a portion of: at least one driver selectable preset for a service request; and with at least one indicator; assigning a service request to at least one driver from a second set of a number of drivers; sending at least one notification within the dispatch service to at least one driver from a second set of a number of drivers; receiving confirmation of this service request from at least one driver from a second set of a number of drivers; and dynamically updating service related data in at least one database.

[0023] In accordance with other exemplary embodiments of the invention, there is provided a computer-implemented method for providing custom-tailored automatic pre-scheduling transportation dispatch. The method includes receiving a plurality of service requests for planning in advance, wherein each of the plurality of service requests includes at least one route leg with at least one of the following: pick-up time, pick-up location, drop-off time, or drop-off location; sorting multiple service requests according to the geographic region of one of the following: pick-up location or drop-off location; storing multiple service requests in one or more databases; retrieving, from one or more databases, (i) customer information associated with each service request from a plurality of service requests, the customer information comprising at least one of the following: selectable preset service preferences, list favorites, a preference list or blacklist, (ii) one or more driver data sets, each of the one or more driver data sets contains information about the driver, the driver information contains a geographic region of service, and at least one of the following: selectable preset service restrictions, service history, favorites, blacklist, or historical data, and (iii) for a specified geographic region on a specified date, at least one of: a service request packet from a stored plurality of service requests; a plurality of customer datasets corresponding to a plurality of customers associated with the request batch, the customer datasets including customer information; or a plurality of driver related data sets corresponding to a number of drivers assigned to the request packet, the driver related data sets including driver related information; excluding one or more drivers from the first set of drivers (i) incompatible with the service request, (ii) those that are on the specified blacklist of the specified customer, or (iii) those that include the customer in their blacklist; creating a dispatch matrix based on at least one or more sets of indicators using a service request, customer information, and one or more driver data sets from a second set of drivers, the dispatch matrix creating a priority assignment to each driver of said second set drivers. The method further comprises assigning each driver from the second set of drivers to a service request from the given packet in accordance with the assigned priority; transmitting to the user computing device a group of drivers from the second set of drivers depending on the assigned priority; obtaining from the user computing device selected from the group of drivers, one best appropriate driver; and transmitting the service request to said selected one best-matching driver.

[0024] In other embodiments, there is provided a computer-implemented method for providing a customer-adaptable automated dispatching of transport services at a micro level, which includes receiving from a client, via one or more remote computing devices, a service request for scheduling with one or more selectable preset preferences for a service request, the service request includes at least one leg; storing information related to a service request in one or more databases; selecting a driver from a subset of drivers to receive a service request based at least in part on information displayed using one or more indicators and sending a service request to the selected driver; receiving confirmation of this service request from the selected driver; identification of one or more partner drivers associated with the selected driver in the dispatch service system at the micro level, one or more partner drivers are in the mode of information exchange with the selected driver through the specified one or more remote computing devices; sending the selected driver a redirected request for the received service request to an identified driver from one or more partner drivers; sending a redirected notification to an identified partner driver; receiving confirmation of the forwarded request from the partner driver automatically notifying the customer of the identified partner driver and providing the customer with the option to accept or reject the identified partner driver; and dynamically updating the service-related data in one or more databases depending on receipt of confirmation of the forwarded request from the partner driver.

[0025] In other embodiments, a method is provided for dynamically and automatically updating service-related data exchanged between a database stored in a server computing system and at least one remote computing device. The method includes receiving from a client, at a server computing device, a service request, the service request including at least one route leg; storing service-related data related to the service request in one or more databases on the server computing device; selecting a driver from a group of drivers to fulfill a service request and automatically sending a service request to the selected driver; receiving, through one or more remote driver computing devices, confirmation of a given service request from the selected driver; identifying the first updated service-related data related to the service request, the first updated service-related data being identified on the server computing device prior to the completion of the service request; dynamically updating the database with the first updated service-related data; automatically transmitting the first updated service-related data to the driver for display using one or more remote driver computing devices; identifying second updated service-related data related to the service request, the second updated service-related data being identified by the driver using one or more remote driver computing devices after the driver confirms the service request; automatically transmitting the second updated service-related data to the server computing device; dynamically updating the database with the second updated service-related data; and displaying the second updated service-related data on the display device.

[0026] Other objects, design features and characteristics of the present invention, as well as the modes of operation and functions of the corresponding structural elements, as well as the combination of parts and savings in terms of design and processing will become more apparent upon consideration of the detailed description below with reference to the accompanying graphic materials, each of which forms part of this description.

BRIEF DESCRIPTION OF THE GRAPHIC MATERIALS

[0027] By referring to the preferred embodiment of the present invention set forth in the illustrations of the accompanying drawings, a deeper understanding of the present invention can be obtained. The drawings are not intended to limit the scope of the invention, which is particularly emphasized in the appended claims or in the subsequently amended claims, but are intended only to illustrate and illustrate the invention. Accordingly, a more complete correct perception of the present invention and many related aspects can be easily obtained as it becomes better understood with reference to the following detailed description when viewed in conjunction with the accompanying drawings, in which:

[0028] FIG. 1 is a schematic diagram of an exemplary advance scheduling system that includes a computing system and one or more computing peripherals for use with various embodiments of the present invention;

[0029] FIG. 2 is a schematic diagram of an exemplary computing device and associated components in accordance with various embodiments of the present invention;

[0030] FIG. 3 is a schematic diagram describing a scheduling operation including an exemplary scheduling matrix in accordance with various embodiments of the present invention;

[0031] FIG. 4A is a flow diagram illustrating exemplary service dispatch logic in accordance with various embodiments of the present invention;

[0032] FIG. 4B is a flow diagram illustrating an exemplary transportation methodology that includes canceling an order by a customer or driver in accordance with various embodiments of the present invention;

[0033] FIG. 5 is a flow diagram illustrating typical price negotiation between driver and customer with or without a dispatch web portal;

[0034] FIG. 6 is a flow diagram illustrating an exemplary methodology for assigning a plurality of pre-scheduled service requests in accordance with various embodiments of the present invention;

[0035] FIG. 7A and 7B are flow diagrams illustrating an exemplary methodology for assigning a plurality of pre-scheduled service requests depending on a first algorithm in accordance with various embodiments of the present invention;

[0036] FIG. 8 is a flow diagram illustrating an exemplary methodology for assigning a plurality of pre-scheduled service requests depending on a second algorithm in accordance with various embodiments of the present invention;

[0037] FIG. 9 is a flow diagram illustrating an exemplary methodology for planning in advance and rescheduling a plurality of service requests using driver-partner methodology and on-demand methodology in accordance with various embodiments of the present invention; and

[0038] FIG. 10 illustrates an exemplary electronic map interface showing unassigned service requests in different geographic regions in accordance with various embodiments of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

[0039] The invention is not intended to be limited to the specific terminology selected, and it should be understood that each particular element includes all technical equivalents that function in a similar manner. For purposes of illustration and explanation, specific embodiments of the invention are shown that may be practiced. The embodiments of the present invention have been described in sufficient detail to enable those skilled in the art to apply the embodiments of the present invention, and it should be understood that logical, mechanical, and other changes may be made without departing from the scope of the embodiments of the present invention. Therefore, the following detailed description should not be construed in a limiting sense. In describing the exemplary embodiments of the present invention illustrated in the drawings, specific terminology is used for simplicity.

[0040] This document describes systems and methods for providing dispatch and transport services. A person skilled in the art would understand that one or more of such exemplary embodiments of the invention may be implemented using various software mechanisms, software modules, or other hardware or software building blocks containing one or more standard programs or one or more subroutines that can be used singly or in combination and carried out by any suitable technological means.

[0041] It should also be understood that various modules of the systems and methods described herein may be implemented in part using an associated mobile application (application program) in the operating system of a mobile device with Internet access, such as, for example, Android, iOS or Windows Phone OS, and partly through the web portal interface, and that different categories of users can use different functionality of the system. Such users or subscribers can be, for example, one or more "driver (s)" or customers. “Customer (s)”, as used herein, may include anyone, including, for example, one or more individuals, organizations, or one or more individuals from an organization, who request or order services. A "client" can be anyone who registers in the system, both an individual and individuals from an organization, who requests or orders services, regardless of what type of service it may be, be it a transport service, a delivery service or and both. Since customers and service providers alike use the methods and systems described in this document, they can all usually be referred to as "user" or "users", in addition to the fact that they can be referred to as users of a particular type, in accordance with that type that they submit in the service request. There are at least two types of users: service provider and client.

[0042] "Services" as used herein can refer to three types of services: transportation for passengers, delivery of goods, and both transportation and delivery. These services can be planned in advance or requested on demand. “On demand”, as used herein, means an additional precise definition of when services will be provided, in real time, as requested. The term “on demand” is used as opposed to the concept that the service is “planned in advance” or provided at a certain time in the future, for example, after several hours or days. On-demand services are currently provided, while pre-scheduled services are performed at a predetermined time, date, or within a predetermined period of time. In addition, “tailored to specific needs” modifies the nature of the services and refers to the preferences of the customer or the preferences or limitations of the service provider involved in providing the services on an individual basis. Regardless of the type of service, a "service provider" in the meaning presented in this document can be an individual individual, such as a driver, a group of people or a branch of a private commercial organization, such as a car service company, which can be contacted for the provision of transport services, services delivery or both. The service provider's ability to deliver the service depends on the tools he / she has at his / her disposal. For example, in the case of a customer traveling somewhere, a vehicle is needed, while a request for a delivery service can be provided not only by means of a vehicle, but someone can provide a delivery service on foot or using a bicycle.

[0043] "Manager (s)", as used herein, may include a party that manages service request (s) and performs various scheduling and scheduling functions in advance. “Suppliers”, as used herein, can be a broker or other commercial entity, government agency, or individual that provides brokerage services on behalf of a customer or passenger. As described herein, each of these different types may be referred to specifically or by the overarching terms "user" or "users" who are registered with the system or otherwise directly or indirectly associated with the system.

[0044] Throughout this description, a request for any type of service is commonly referred to as a "service request" or "trip (s)". In accordance with exemplary embodiments of this patentable invention, a service request is directed to a driver based on customer preference (s) and driver preferences and / or restrictions, and certain drivers are given priority for certain customer journeys based on one or more characteristic features, or previous trips. As used in this document, the term "preference" refers to various factors related to a specific service that a customer would like to include in the general service provided to him / her, based on what the specific driver will be, the specific vehicle that the driver uses, and any associated with this characteristic features. These preferences can represent ideal or preferred conditions for a service request. Alternatively, such preferences may represent preconditions for the service. The client can set his preferences on a mobile device and update them at any time, which allows the client to feel comfortable and, in the end, be satisfied with the quality of the services received. A client can have one or more of these "preferences."

[0045] In accordance with exemplary embodiments of this patentable invention, the term "restrictions" can mean any type of restriction that a driver may wish to impose on a service he / she provides. These restrictions can include two broad categories: personal restrictions on when, where, how, and to whom the driver provides services. Such personal restrictions may include location restrictions based on the driver's unwillingness to provide services in certain geographic areas and time restrictions based on the driver's unwillingness to provide services within certain periods of time. Alternatively, in certain preferred embodiments of the invention, the driver may also indicate one or more predetermined location preferences depending on the driver's desire to provide services in (eg, preference to get a job within) certain geographic areas. In such embodiments, the driver may also indicate location restrictions within his / her location preferences based on the driver's unwillingness or inability to provide services in certain geographic areas within the driver's preferred geographic service area. Service restrictions may additionally or alternatively relate to times or time frames where the driver may not want to provide services to the customer. Such time values can include the time of day, days of the week, seasons, and so on. Drivers can also set "restrictions" on location and time. For example, a driver may not want to provide services in a certain area after 10 pm, but wants to provide services in another area after that time. In such embodiments, the driver may also indicate a time preference indicating a period of time during which the driver prefers to receive service requests. A driver can have one or more of these "restrictions" and / or "preferences". The terms "preferences" and "restrictions" are not intended to narrow the range of customers or drivers to only those with preferences or restrictions. Rather, they are meant to be visually contrasted.

[0046] In accordance with exemplary embodiments of the present invention, several terms are used to refer to a customer who has an established positive relationship with the driver. A “favorite customer” is one that is on the driver's “favorite customer list”. A driver who has established a positive relationship with the customer is referred to as the “favorite driver” (eg, on the customer's “favorites” list). As used herein, the term “favorites” is intended to be broad and refers to any customer or driver who has priority in assigning a service request (eg, on a “favorites list”). One of ordinary skill in the art will understand that the concept of a "favorites list" may alternatively be called, for example, "friend", "top of the list", "priority" or any other word used by drivers or customers to define the concept of such a list. Regardless of the specific terminology, the primary goal is to identify the concept of a positive driver-client relationship, which includes compatibility between driver and client.

[0047] Unlike “favorites,” a driver “blacklist” or “customer blacklist”, as used herein, refers to lists that can prevent future matchmaking between a driver and a customer (for example, when both excluded from service request processing). One of ordinary skill in the art should understand that other terms may be used to describe this concept, such as, for example, "blocked list", "ban list", "hate list" or the like. Regardless of the specific terminology, the aim is to delineate the concept of a driver, which is to exclude customers who he / she does not want to provide services or who he / she does not want to contact, and a way in which the customer can exclude drivers from whom he / she does not want receive services or do not want to contact.

[0048] Additionally or alternatively, the client may have a "preferred" driver. A preferred driver is a driver who is not on the customer's favorites list, but one whom the customer has requested directly on his / her “favorites list”, or one whom the customer has requested on his / her favorites list, but whose request has not been agreed with the driver. In any case, if the driver rejects the customer's request, then the driver will not be added to the customer's favorites or customer preferences, and vice versa. Thus, in preferred embodiments of the invention, drivers and customers are placed in each other's favorites when both parties agree, and in favorites when one or both parties directly request such placement, or when one party requests a favorites and the other does not. answers. As used in this document, the word “preferred” generally refers to a lower ranking than “favorite” for the purpose of matching customers and drivers when assigning pre-planned service requests. Driver and customers can further rank each other within these classifications, as discussed further in this document. Drop off locations can be complex, such as in hospitals or clinics, which often have confusing or unclear layouts. In such locations, it can be difficult to find the right entrance. Thus, when this type of location is involved, it may be preferable to send a service request to a driver who is familiar with the particular route. In certain embodiments of the invention, any driver that is not the customer's preferred driver or preferred driver is referred to herein as a “regular” driver. Essentially, this term means that the driver is not the preferred driver and has not been added to the favorites list. It will be understood that the specific status associated with the driver (ie the driver category), be it “favorite”, “preferred” or “normal”, is also always relative. The driver who is preferred by one customer may be chosen by another.

[0049] The term "system", as used herein, refers to an implementation through a combination of hardware and software that controls a portable computing device that includes various pre-programmed design features combined and integrated with basic building blocks, which include, but are not limited to, one or more servers, databases, applications from a mobile device, web portals, network settings, and so on. With these building blocks, the system delivers services through user interfaces such as a website or mobile application. In addition, the system can have more than one server, which can be in a distributed structure with support for data centers that can be located anywhere in the world. These implementations can be communicatively linked and cross-platform, so that a user on a mobile device (e.g. smartphone, tablet, etc.) or stationary (e.g. desktop computer, etc.) can be provided with information related to his request for service (e.g. e-map displays, indicators that display travel times, routes, price information, dataset / setting information, etc.). As used herein, the term "indicator" is a means for transmitting or displaying service-related information to a client or service provider, or both, in a simple, fast and convenient manner.

[0050] Various embodiments of the systems described herein provide transportation scheduling in advance via a computing system. Computing systems described herein can include any combination of hardware and software and can communicate with a variety of portable computing devices via, for example, a packet-switched wide area network (WAN) that allows users to access various pre-programmed functions combined and integrated with the main building blocks. Such design features and building blocks may include, but are not limited to, one or more servers, databases, mobile endpoint applications, web portals, network settings, etc. within the communication structure / network. Using these building blocks, the systems described herein provide services through user interfaces such as, for example, a website or mobile application on a portable computing device. Systems can also include more than one server, functionally located in a distributed structure with support for data centers that can be located anywhere in the world.

[0051] Some embodiments of the systems described herein are not limited to applications, which include conventional computer programs or programmable devices that run them. It is contemplated, for example, that embodiments of the present patentable invention may include an optical computer, a quantum computer, an analog computer, or the like.

[0052] Each element in the flowcharts herein depicts a step or group of steps in a computer-implemented method, and each step may comprise one or more sub-steps. For purposes of illustration, these steps (and any other steps identified and described) are presented in a specific logical order. However, it should be understood that any exemplary embodiment of the invention described herein may comprise an alternative order of steps adapted for a particular application of the method described herein, and that any changes and / or modifications fall within the scope of this patentable invention. This description and description of the steps in any particular order are not intended to exclude embodiments of the invention in which the steps are arranged in a different order unless required by a particular application, explicitly indicated, or clear from context.

[0053] The systems and methods described herein are best understood with reference to the following graphics, which are detailed below. Referring first to FIG. 1, note that illustrated is a schematic diagram of an exemplary computing system 100 and a variety of peripheral computing devices for use with various exemplary embodiments of the present invention. The combination of hardware and software operates on a plurality of computing devices 128 and computing system 100, typically with one or more wired or wireless connections to a wide area network (WAN) 124 (e.g., the Internet) connected to local devices via local interface 120 network (LAN). Computing devices 128 can be a wireless mobile hardware device with software that is capable of transmitting information to other mobile devices or computer systems, locate that device through its geolocation ability (e.g., via cellular triangulation, GPS, location specification from the user, etc.) and connect over the network to a closed computer network or to an open network such as the Internet.

[0054] Computing system 100 may include, for example, a server 102 that contains a central processing unit (CPU) 104, a storage unit 106, a database 108, an interface 110, communication means 112, an information display unit 114, one or more devices 116 information input (e.g., keyboard, mouse, etc.), a local area network (LAN) communication controller 118, a local area network (LAN) interface 120, a network controller 122, and an internal bus 138. As shown, via a wired or wireless line communication, the system may be connected to a storage device, such as, for example, a hard disk that houses one or more databases 108. Central computing system 100 may comprise one or more servers configured in the same or similar manner as server 102 shown in FIG. 1, or one or more servers configured differently, which may have different hardware or software. For example, computing system 100 may include multiple servers located in multiple spaces, such as data centers or server fleets.

[0055] Computing system 100 can be configured to communicate using a network service coordinated through communication means 112, which can include any approach for communicating over one or more networks or to one or more peripheral devices. Communication means 112 can include, but are not limited to, circuits and control systems for providing wireless connections, wired connections, cellular connections, data port connections, Bluetooth connections, or any combination thereof, and the means can include devices, able to exchange information using such information exchange approaches. One of ordinary skill in the art will understand that there are numerous approaches for exchanging information that can be used.

[0056] Server 102 and computing system 100, via communication means 112 and WAN 124, may be communicatively coupled to peripheral devices such as computing devices 128, vendor device 126, administrator device 134, and dispatcher device 136. Computing devices 128 may be configured as one or more user computing devices 130C1-130Cn or driver computing devices 132D1-132Dn. Computing devices 128 can be devices (eg, a smartphone, smart watch, etc.) that allow a user (eg, a client, driver, etc.) to interact with the computing system 100. Anything can be used in conjunction with the computing system 100. the number (for example, 1, 2, 3, ... n) of driver devices 132D1 ... 132Dn or client devices 130С1 ... 130Cn.

[0057] Computing system 100 can contain more than one server 102 in a distributed structure with support for data centers that can be located anywhere in the world. These implementations can be communicatively linked and cross-platform so that information related to a service request can be provided to a user on a mobile device, such as, for example, an electronic map display, indicators that display travel times, routes, price information, information about the dataset, setting information, etc. Features of the systems described herein can be implemented by computing devices that allow a processor to process and output method steps. In accordance with an exemplary embodiment of the present invention, the server 102 coordinates user interfaces and interacts with the database 108. Each user may be provided with different functionalities depending on their type and needs.

[0058] The server 102, via the server interface, may receive client input, location information, and service request information for configuring content, as well as information from a driver (e.g., location information, restriction information, historical information, etc.) etc.). As discussed above, the server 102 can send information to one or more computing devices through the server interfaces, and the information can be displayed on the display of the computing devices. Such content may include features that are specific to a region if there is particularly relevant regional information, especially with regard to the display or routing of a service request.

[0059] The service request information received via the server interface may be stored by the computing system 100 in the database 108 and may include, for example: the status of the service requests; the status of drivers' confirmation of service requests; reasons for refusal of service requests by drivers; stories related to assigned service requests; dispatcher operations logs; etc. The content / timestamps of notifications and confirmation statuses can also be written to system logs, and this information can be verified by the administrator of the computer system 100. It is understood that the above is not an exhaustive list of information regarding a valid service request that the system can record.

[0060] Data stored in one or more databases 108 of computing system 100 may be continuously updated with all user information discussed herein and analyzed in accordance with various methodologies discussed herein in order to provide efficient redundancy and dispatching support of pre-planned transport services. In certain embodiments, each time computing system 100 receives raw data / request from a client, driver, dispatcher, or other user, computing system 100 may first open a secure access channel to the database (s) / database center and then send search queries through the access channel to the database management module. If you are using a relational database, the data tables can have some kind of relationship with another data table (s), such as one-to-many relationships, many-to-many relationships, and one-to-one relationships. Depending on the relationships between the data tables, the database management module (s) can closely follow the search queries and find the specific data table (s) using the identifier (s), table names, and table column names with or without joining two or more data tables together. If a non-relational database with data stored in key-value pairs is used instead of data tables, the database engine can closely follow the search queries and find specific data using the keys that the search queries provide.

[0061] Computing system 100 may access all information stored in one or more databases 108. Database (s) 108 may include policy and procedure data, driver data, administrative data, group data, customer data, data in relation to the card constituent element and any other data related to the implementation of the computing system 100. Data on the rules and procedures may include the price of the system, rules and procedures for incentive settings, as well as rules and procedures for indicators, redirects, payments, requests maintenance, system management, syslog, system analysis and system optimization, etc. The data in relation to the map constituent may store map data for service requests that are identified using GPS and LBS (location-based services). GPS and LBS data can locate computing devices in a variety of ways, such as by acquiring resources based on the user's location. Driver data may include sets of driver data, such as personal data, which includes the driver's photo and length of his / her driving experience, gender, country of origin, and language skills.

[0062] The database 108 may also include data related to the driver's vehicle, such as make and model, color, capacity and accessibility for people with disabilities, insurance status, and even photographs of the vehicle. Additional information in the driver dataset may include information such as favorites and driver blacklists, restrictions related to zip codes, time, location and price, and service data and entries. Database 108 may further include administrative data containing prices and rates, system data such as contact information and FAQs, and registration details for customers and drivers. For example, database 108 may store payment information or other information related to administering on-demand service applications for computing system 100. Group data can include basic data, company data, data regarding a group of individuals, or data related to suppliers. Customer data may include datasets about a customer that include personal data, customer favorite driver lists, customer driver blacklist, customer preferences, service request data, and records. One skilled in the art will understand that database 108 can be dynamically synchronized so that whenever changes or updates are made to blocks of data, server 102 and database 108 dynamically update data with the latest changes. In addition, in order to back up and restore the information in the primary database 108 in the event of data loss in the primary database 108, at least one backup and restore database may be used. One skilled in the art will understand that the building blocks of the database 108 may differ from those depicted herein.

[0063] Alternatively, computing system 100 may utilize a set of databases or storage media to provide and maintain a pre-planned service application to guide a driver to match those preferences and needs based on customer preferences and needs. Databases 108 may contain multiple categories or groups of data. Database partitions 108 can be independent or synchronized so that information can be retrieved from both partitions at the same time. Such data may include policy and procedure data, administrative data, customer data, driver data, group data containing basic data, company data or data relating to a group of individuals, as well as other types of data, such as data related to types users. In accordance with exemplary embodiments of the present invention, all historical information can be classified and stored in database 108 and retrieved from database 108. Historical data can be partially tracked by assigning a tracking number, service ID number, or trip IDs corresponding to each service request to help the computing system 100 re-access the service request. Information classified according to such identification may include the type of service request, who requested and fulfilled the service request, where it was performed (zip code, district, county, city, state, etc.), what was the route , the cost of the given service request, when and how payment for the service occurred, and whether either party was added to the favorites list or to the blacklist. All information regarding customer preferences or restrictions, driving preferences or restrictions, prices, and other information regarding customized services can be stored in the database 108.

[0064] Such a multipurpose database 108 can store administrative data and other information. Administrative data can include any information or data that is part of a pre-planned service application and can contain system data such as contact information and FAQs, registration details for customers and drivers, such as , payment information, or other relevant information related to administration of a pre-planned service application. For example, registration details may include information about how long ago users were registered with the system or how often they use a pre-planned service application. Administrative data may include information such as pricing and fare information for routes from various organizations. Other stored information may include service policies, procedures, prices, and procedures for driver and customer settings.

[0065] In accordance with exemplary embodiments of the present invention, database 108 may also store and maintain records of completed service requests. Computing system 100 can automatically store historical data records for any service requests performed in a multipurpose database. Database 108 can be dynamically updated as services are booked and completed. The database 108 can store an index of each service request that has been requested and completed, which includes registration numbers or user credentials of customers and drivers, which can be retrieved for reference at any time if necessary.

[0066] The service request information stored in the database 108 may include, for example, the service request ID, the corresponding driver information, the corresponding customer information, the ordered pick-up location, the actual pick-up location, the ordered drop-off location, the actual drop off location, pick up time, drop off time, distance, duration, status, prices, insurance company information, etc. Even if the client does not have a smartphone or does not use an application that is in the mode of exchanging information with the system, this will not adversely affect the functioning of the system, since methods can be used in which there is no need for the client to have access to the system. For example, for such a client, the dispatcher may update information about the status of his / her service request or the location of the driver. The dispatcher can provide the client with the most up-to-date information as the functionality of the start button described above allows the driver to instantly connect to the dispatcher on the server side.

[0067] Relevant service information may include information such as fleet number, first name, last name, username, email, password, phone number, date of birth, gender, country of birth, driving experience, driver category (eg, owner -operator), name of the subsidiary, name of the subsidiary, the ability to transport pets, the ability to transport a wheelchair, language, signature and general data set. Relevant service information may also include license information such as license number, license class, license status, license issue date, license duration, FHV (For Hire Vehicle) license number for the rental car, FHV license issue date, and expiration date. FHV licenses; driver's license information, such as the date the driver's license was obtained and the date when the driver's license expires; vehicle information such as registration status, registration status, start / end date of registration, model year, make, model, VIN number, vehicle type, license plate, start / end date of FHV registration, FHV license number and FHV license ; and insurance and inspection information such as liability status, insurance status, insurance provider, insurance start date, insurance end date, vehicle inspection date, and vehicle inspection expiry date.

[0068] The multipurpose database 108 can also store details of service requests for each specific driver for future reference. Database 108 may include driver vehicle data such as vehicle type, model, color, capacity and accessibility for people with disabilities, insurance status, and even photographs of the vehicle. Additional information in the driver's dataset may include information such as the driver's favorites and blacklist, preferences and restrictions such as zip codes, time and location restrictions, and service data and records.

[0069] Any backup databases associated with database 108 may also be updated accordingly to reflect the latest changes. In certain embodiments of the invention, such information may be organized or structured in a manner that enables efficient sorting and searching. Information can be stored in a non-relational or unstructured way. One of ordinary skill in the art will understand that in accordance with the exemplary embodiments of the present invention discussed herein, numerous methods can be used to provide, store, and organize data in a database 108 or other storage medium. In addition, it should be understood that at least one backup database can be used, which often backs up the primary database in the event that any data from the primary database is lost.

[0070] The information stored in the database (s) can be used to obtain various indicators (discussed further below) in the pre-scheduled service system 100. Icons, shapes, or other images related to indicators may be stored in the database 108. Depending on the results of the exploration and analysis of the data in the database 108, and the rules for assigning icons, shapes, or other images, icons, shapes, or other images may be displayed. with other indicators for customers, drivers and dispatchers, respectively. Using the collected customer and driver information stored in the database 108, the pre-planned service system 100 can provide relevant information to any pre-planned service application operatively associated therewith. Driving information may correspond to information about the available drivers themselves, such as information about a dataset of drivers, current location or vehicle movements, and specific distances from the customer or estimated time periods before boarding.

[0071] Computing system 100 may also utilize a set of databases 108 or storage media to provide and maintain a pre-planned service application to guide a driver matching those preferences and needs based on customer preferences and needs. Database 108 may contain multiple categories or groups of data. Database partitions 108 can be independent or synchronized so that information can be retrieved from both partitions at the same time. As discussed in this document, such data may include policy and procedure data, administrative data, customer data, driver data, group data containing basic data, company data, data regarding a group of individuals, and other types of data. for example, data related to user types. In accordance with an exemplary embodiment of the present invention, all historical information in database 108 can be classified and stored, and retrieved from database 108. Historical data can be partially tracked by assigning a tracking number, service ID number, or trip ID numbers assigned to each service request to help the computing system 100 re-refer to the service request in the case of an investigation. The information stored may include the following: the type of service request that was requested or provided, who requested and who performed the service request, where the service was provided, such as zip code, district or county, city or state, which route was used, what was the cost of the service request, when and how payment for the service was made, and whether any party was added to the favorites or blacklist. All information regarding customer preferences or restrictions, driving preferences or restrictions, prices, and other information regarding customized services may be stored in the database 108 of the computing system 100.

[0072] In addition, specific data such as service request data times and service request prices can be used as a reference to determine average prices for customers so that they can receive fair prices when booking services. The data that is entered and stored in the database 108 can be subject to ongoing verification. The maintenance of a comprehensive database 108 also allows for accurate tracking of service requests that might be disputed by a customer or driver. To ensure that any complaints can be resolved in a timely manner, service request records can be efficiently retrieved from the 108 database.

[0073] Additional data may be entered into the database 108, which includes, but is not limited to, locations where customers were sent, favorites or blacklists, locations, other data and transaction details, historical data , the expiration date of the insurance policy, the date of the technical inspection, the date of the validity of the driver's license, or any combination thereof. This data may also include information regarding indicators and their display. As an example, data can include service requests that all customers or drivers have fulfilled in a specific area, such as within one or more streets, zip code, civic center, city, borough, county, state, or any other. functions of determining the region, or how many times the client and the driver were paired using the computing system 100.

[0074] It is understood that computer program instructions used by computing system 100 may include executable computer code. Representation of computer program commands is possible using various programming languages, including C, C ++, Java, JavaScript, Python, assembly language, Lisp, and so on. In order to solve the technical problems associated with providing very specific and specialized services to customers and drivers, some logical functions may need to be implemented. These logic functions can be preprogrammed to accommodate different preferences and constraints, and can be extremely complex to execute specific if-then scenarios. Rules can be established that define specific parameters. Thus, many complex conditions can be accounted for, and drivers and customers can be filtered by chaining logical functions depending on these filters. With programming languages such as Java, various language features can be used, programmed, and implemented. Such languages may include assembly languages, hardware description languages, database programming languages, functional programming languages, imperative programming languages, and so on. In some embodiments, computer program instructions may be stored, compiled, or interpreted to run on a computer, programmable data processing device, heterogeneous combination of processors or processor architectures, and so on.

[0075] Now referring to FIG. 2, shown is a schematic diagram illustrating the various building blocks of an exemplary embodiment of computing devices 128. As previously discussed, computing devices 128 can be used either by clients (eg, via devices 130C1 ... 130Cn) or by drivers (eg, via devices 132D1 ... 132Dn), or both, and can operate in a mode of information exchange with various constituent elements, tangible or intangible, of the computing system 100. Computing devices 128 may include various internal devices 200 and external devices 202 and may use devices 220 mobile communications to receive voice, text, and data for connection to computing system 100, such as via WAN 124, and a location identifier 204, such as a global positioning system (GPS) receiver, to determine the location at a given time. For specific location functions, one or more computing devices 128 may integrate an application, map item, map data, and location identifier 204, such as, for example, a GPS module or other scheme for providing location-based service data (LBS ). The location identifier 204 can identify the location of the computing devices 128 in various ways, such as by receiving resources based on the location of the user. One of ordinary skill in the art will understand that there are many approaches for implementing location determination and providing services based on location of a user. A GPS-enabled system or device allows tracking components to identify the location of computing devices 128. For example, location identifier 204 may be implemented by processing received GPS data from resources based on locating a user or geo-information resources of computing devices 128. In addition, location identifier 204 can receive GPS data from other applications or programs that run on a computing device using one or more application programming interfaces (APIs). An application can use location information to force a composite user interface element to configure the structure of the user interface.

[0076] In preferred embodiments of the invention, a client can access a client module, such as computing device 128, operatively coupled to computing system 100 to enter a service request that includes travel details such as pickup and drop-off locations. as well as the desired embarkation and disembarkation times. However, if any entity requests a service that is deemed incompatible with the system (for example, depending on the data received from the location identifier 204 regarding the location of one or more drivers and / or depending on the driver restrictions in the database 108), then the dispatcher can be notified.

[0077] Computing system 100 may be configured to generate notifications to client device 130 when a driver enters an area that spans a specified distance (eg, one or two miles) from a client's pickup location specified in a service request. Such user location-based services are facilitated by the location identifiers 204 in the driving devices 132D1 ... 132Dn, providing efficient routing of drivers depending on directions from one point on the ground to another. Each of the driver devices 132D1 ... 132Dn may include a composite interface element that provides location information collected by the location identifier 204 and transmits such location information to a composite interface element on client device 130C1 ... 130Cn via WAN 124 and server 102 Driving devices 132D1 ... 132Dn may also include radio frequency identification (RFID) technology or other similar identification device or identification means to alert the system when a driver is in his / her vehicle or away from his / her vehicle.

[0078] The location identifier 204 may include a GPS-enabled system or device whose tracking elements identify the location of customers who make service requests and drivers who want to provide the service. Computing system 100 may include an application manager that, depending on the client's current location or the location of the service, may cause a client interface component to output a region-specific client interface feature to display 212. A customer-specific region may include the location of the customer at a given time, or a location where the service is provided where the customer wishes to schedule the service in advance. The region may be identified by the postal code, city name, city area name, etc., within which the computing devices 128 are currently located, and may be an area having a certain distance or radius from the client's location at the given time (for example, one mile, five miles, etc.), or it may be an area that is specially separated from other areas. Region-specific information about a pre-planned service may be provided in part by a system that provides driver location data 324 (FIG. 3). It is understood that the use of location-related preferences or restrictions may in part depend on GPS-enabled devices. By cross-referencing these, the pre-planned service systems described in this document can identify specific locations (e.g. shops, restaurants, housing estates, event venues, street addresses, etc.) near the specified location and / or located at a specified location, and provide information about that particular location as location data (eg, as part of traffic and map data 326).

[0079] Preferably, a processor 206 is provided on computing devices 128 for executing software or instruction set. Computing devices 128 may also comprise memory 208, such as random access memory (RAM) or flash memory. Input / output (I / O) devices 210 may be used to connect computing devices 128 to other system implementations depending on the available functionality of computing devices 128. For example, a driver may use a vehicle-integrated navigation system, which may not have a camera, in while a smartphone may have a built-in camera. In this situation, the camera can be turned on as an input for a vehicle-integrated navigation system. Other I / O devices 210 may include a scanner, microphone, and / or speaker. Computing device 128 may also include a display device 212 for receiving and displaying notifications and / or other data received from the computing system 100 to a user. Display device 212 may, for example, be an electronic touch screen display configured to provide user interface 214 in accordance with various methodologies of the present invention. Computing devices 128 can also use the internal clock mechanism 216 to determine the current time value. An accelerometer or speedometer 218 may also be provided as part of computing device 128 and / or is in communication with computing devices 128 to measure speed, acceleration, direction change, etc.

[0080] The user interface 214 displays different content depending on user-selected values and preferences. It will be understood that one or more of the building blocks of computing devices 128 may be combined to provide user-specific features specific to user-selected values and user locations. These selected values can be displayed to the user and the user can use the user interface 214 to interact with displays of certain information. For example, the user interface 214 may correspond to a program downloaded to a smartphone or other portable computing device, such as a tablet computer or personal digital assistant (PDA). The user can download and install the application on one or more computing devices 128 and register with the system. In some embodiments of the invention, pre-programmed design features of computing devices 128 are used depending on certain protocols or methods of integrating basic building blocks such as servers, databases 108, mobile-side applications, web portals, network settings, and so on. Applications can be applications written for Android (a mobile platform developed by Google and the Open Handset Alliance), IOS (a mobile platform developed by Apple, Inc.), Windows Phone (a mobile platform developed by Microsoft Corporation), etc.

[0081] All types of users can be registered and entered into the system for the purpose of tracking activity. Registration can be accomplished by means such as assigning a user ID to each user so that access to system functionality can only be provided by entering the user ID. In addition, the device that the user uses to access the system can be tracked by an IP address, and system activity can be tracked using time stamps or similar and stored in a database 108. Thus, the system administrator can track more than just information about who is accessing the system, but also from which device, the location of the device and the value of the time of such access. These capabilities allow dispatchers to track activity, and if an error occurs, such as entering an incorrect address in a service request, the cause of the error can be easily diagnosed and corrected. There is a drawback in the industry at this time in that such errors cannot be detected and identified, especially when the dispatcher does not want to admit the error. It is understood that such functionality also provides a means of additional security. Any service request entered from an unauthorized computer can be ignored. If computing device 128 is not granted access permission, it cannot access certain functionality available only to registered users. Ensuring that the dispatch system operates with partial participation of dispatchers allows for increased flexibility and, if necessary, provide executive functions, as exceptional situations may arise that require logical human judgment.

[0082] In accordance with an exemplary embodiment of the present invention, the user interface 214 may be, for example, a home page, a dispatch portal access (for drivers), a service request module (for customers), a database access interface 108, or a method for users to access one or a combination of any design features described in this document. The system can retrieve user information and other data that is stored in the database 108, which can provide a local and / or remote database. One of ordinary skill in the art will understand that numerous additional user interfaces can be used and be provided for use in conjunction with or instead of user interface 214.

[0083] Each of the client devices 130C1 ... 130Cn can use the client interface to display various indicators on maps showing geographic information. Each indicator may indicate, for example, different information regarding a customer or customer input received by the computing system 100 from a customer, merchant, or any application that receives a pre-planned service request 300 from a customer. Each of the client devices 130C1 ... 130Cn may also contain application design features adapted to dynamically synchronize content based on client-selected values provided using client input.

[0084] User interfaces 214 on client computing devices 130C1 ... 130Cn may include, but are not limited to, a home page client interface, a service request panel used for clients to identify service request details, preference details etc., a consolidated client interface, a location search client interface, a confirmation page interface, or a combination of any of these design features. For example, if the customer's current location is different from the originally ordered pick-up location, the customer can manually plan ahead of time for a new pick-up location that is different from the location currently stored in computing device 128 or computing system 100.

[0085] The start button functionality may be provided as part of computing device 128, for example, on one or more driver devices 132D1 ... 132Dn. The display of one or more mobile driver devices 132D1 ... 132Dn can display relevant information to the driver about the queue for a trip, starting with the next trip in the queue, which provides details of that trip, such as the pickup location and pickup time along with destination and planned disembarkation time ... The driver can then press "Start" (for example, a physical button or through the touch screen interface on the driver's device 132D) so that the dispatcher or administrator knows that he / she has started a trip and is on the way. The display on the mobile device can also show a list of the remaining trips in the queue with abbreviated details that can be expanded or viewed later. This start button functionality helps address current communication gaps between different parties, as dispatchers can easily determine which service requests are in progress. In addition, they provide a means by which the customer who has planned the second leg of the route can inform the driver of the status of the meeting in question. In a traditional telephone-controlled dispatch system, the location of the drivers at a given time and the status of the customers of the second leg of the route may not be known. As a result, dispatchers have no choice but to work with assumptions if they cannot easily reach the driver or customer when coordinating a service request. When the driver presses the start button at the beginning of each leg of the service request route, the system can write the status to the database 108. This functionality will also facilitate tracking if the legs of the service request are processed by more than one driver.

[0086] It is understood that the systems and methodologies described herein provide functionality that provides a much smoother and more efficient overall process than those used in traditional dispatching methods. Pressing the Start button can serve as an event that initiates a series of actions that affect the server-level dispatch system, and this series of actions can be performed using a variety of software and hardware. Pressing the Start button could, for example, cause the driver's location to be shared with a third-party mapping and navigation service such as Waze ©, which can configure different routing and ETA settings for the driver on each route based on the driver's speed at that time. and the distances associated with each route. This information can be transmitted to the dispatcher, the client and back to the driver and can be provided in real time.

[0087] In some embodiments, the user interface may include a start button that initiates a series of actions in the database 108 regarding data storage, where the geolocation of the driver is tracked by the location identifier 204 as part of the records associated with the service request, by the customer, driver, etc. Without this functionality, the GPS start buttons may still determine the driver's location and course at a given time. However, when providing pre-planned services, drivers will have a long list of planned journeys, and without the driver actually confirming that he / she is on the way to pick up a specific customer, there is no way to ensure that the location where the driver is supposed to be located is located at the heading towards the location of the client's landing. As a result, the Start button is a fully functional design feature that allows dispatchers and other parties to instantly update driver status information in real time.

[0088] Other functionality may be useful in NEMT (non-emergency medical transport), which includes functionality provided to users on the clinic side. A clinic operator, such as a clinic employee, may be able to manage (e.g. search / add / delete / modify) appointments associated with the clinic and, using the functionality of the start button, notify other clinic employees and clients of any changes. For example, a clinic operator or client can notify other users that an appointment has begun by pressing the Start button at their end. If, for example, the appointment starts later than it was planned, the system can make any necessary changes, for example, reschedule the appointment or notify customers of how these changes will affect their appointment. In addition, in some embodiments of the invention, the driver who was assigned to pick up the customer at the end of the appointment may receive a real-time notification of the customer's status, for example, “Checked in”, “At the doctor's appointment”, “The visit is almost complete”, “ Visit Completed ”etc., which allows the driver to be prepared for any changes in the scheduled pickup time.

[0089] Client devices 130C1 ... 130Cn may be configured to allow a client to manually enter location inputs by entering an address (eg, street number, street name, city, state, etc.) or by maneuvering and moving the graphic. icons of the location of the provision of the service on the display of the electronic map on the part of the client interface In response to this client's choice, a pre-planned service application running on one or more client devices 130C1 ... 130Cn may provide location data to computing system 100.

[0090] Once the start button is activated, computing system 100 can calculate an estimated time of arrival (ETA). The driver can be provided with potential assignments through this interface, where requests can be displayed temporarily for the dispatcher to accompany the trip. The driver module can facilitate the provision of an interface capability on a mobile device that the driver has in the vehicle. In the event that the customer is unable to sign for the trip, the computing system 100 may depend on the driver to receive the customer's signature on his / her phone.

[0091] In preferred embodiments of the invention, the system 100 dynamically updates and stores any changes to a service request before or during its launch, or any updates to the status of a given service request, and displays these changes in real time, as in a web portal to a dispatcher. and in the driver interface on the driver device 132 associated with the driver assigned to fulfill the service request. For example, if a customer cancels a service request or needs to change the pickup time or location, the customer can enter this information into the system 100 through the client device 130. The new information is stored in the database 108. The dispatcher's web portal is updated and a change notification is immediately sent to the driver associated with the service request via the driver device 132. Preferably, the driver can then access the same service request information displayed on the dispatcher's web portal. In addition, in preferred embodiments of the invention, any new information regarding the customer (e.g., phone number, email address, preference change, etc.) entered prior to the service request may be submitted to the dispatcher's web portal and user interface. a driver's driver device 132 assigned to fulfill a service request. Preferably, only the respective driving devices are updated with new information regarding the customer (eg, driving devices associated with drivers involved in fulfilling customer service requests).

[0092] When the driver presses the start button at the beginning of each trip or at the beginning of each leg of the service request, the trip status on the dispatcher's web portal and on the client client device 130 may be updated. It is understood that, in this way, the client can preview in advance a preliminary estimate of the arrival time of his driver. This functionality will reduce or eliminate the dispatcher's workload as he / she will not need to make phone calls due to service changes and will not need to call drivers.

[0093] Those of skill in the art would understand that these functions are only examples and that other functionality of the driver's interface may be used.

[0094] External devices 202 (ie, additional mobile devices, tablets, laptops, or other computing devices) can connect to computing devices 128 via a wired or wireless connection. It is understood that these external devices 202 can include any device that can provide additional or enhanced functionality to the computing devices 128, whether the computing devices 128 are mobile devices such as a tablet or smartphone, a vehicle-integrated navigation system. , or are other types of computing devices.

[0095] It is understood that computing system 100 can integrate various functionality specific to various industries, including the NEMT industry. In the NEMT industry, it is common practice to receive service requests from brokers who request the provision of service between two locations for which addresses are listed, at very specific times. These specific terms are understandably designed to combat fraud and ensure that service requests are properly executed. However, it is not always easy for drivers in this industry to adhere to exact times and specified addresses. Unexpected traffic congestion or construction work prevents drivers from arriving at pick-up and drop-off locations on time. Customer drop-off at the exact address as requested may not be possible due to parking regulations, pick-up and drop-off rules, permanent bans or other applicable laws or fines. The driver may need to wait a certain amount of time or complete disembarkation down a block or around a corner where stopping and disembarking is appropriate and legal.

[0096] In certain embodiments of the invention, the systems and methods described herein may be used in conjunction with the systems and methods described in US patent application Ser. No. 15 / 474,685, filed March 30, 2017, entitled "Geoinformation Verification System and Method information on transportation costs ", the contents of which are fully incorporated into this application by reference. The good faith of these billing adjustments can be verified by tracking the geographic location of the driver using location ID 204 and timestamping during embarkation or disembarkation to ensure that such pickup or disembarkation location and timing are within a predetermined validity areas, for example, within 150 feet of the specified address or within fifteen (15) minutes of time. If a service request falls outside such a predetermined scope, then the request can be opened to investigate the reasons for the rejection. In this way, billing staff can save valuable time, drivers do not need to risk penalties, and brokers know that service requests they have ordered have been met in good faith.

[0097] Referring now to FIG. 3, it should be understood that dispatch systems must receive, organize, coordinate and send a large volume of service requests. Fairly and efficiently planning ahead of time to dock each driver with a customer can be challenging. When services are planned in advance, customers may require driver preference when dispatched. For example, a Spanish speaking customer may be unhappy with a driver who does not speak Spanish. The present invention can sort service requests based on customer preferences and prioritize specific drivers based on a variety of factors.

[0098] FIG. 3 is a schematic diagram illustrating an exemplary scheduling operation including an exemplary scheduling matrix in accordance with various embodiments of the present invention. The illustrated is an exemplary operation of the computing system 100 in which a service request 300 is received and a driver is directed, depending on the scheduling matrix 322, to fulfill the service request 300. Information from the received service request 300, which the client can transmit via one of the client devices 130C1 ... 130Cn (or from the supplier on behalf of the client via the supplier device 126), is included in the generated scheduling matrix 322. It is understood that the customer can also enter or send a service request 300 using a conventional telephone.

[0099] Once a particular customer or supplier submits a service request 300, the processor 104 executes instructions to retrieve the appropriate data from the database 108 pertaining to the particular customer information 302. It is preferable if the data will be stored strictly within the database 108 and dynamically updated to ensure that the most current and updated information is used in the planning process in advance.

[0100] Customer information 302 may include any information related to the customer, including, for example, customer transportation needs, one or more customer preferences, customer favorites, customer blacklist, customer contact information, information for invoicing the client, etc. The customer information 302 may also include the customer's home address, place of work, customer preferences, historical information such as information about previous locations for which the customer requested a service, questions of interest, and so on. When a client selects one of the recommended question records of interest as a current location and / or pickup location, the system can retrieve various types of historical data 324 and the driver's current location. As shown, computing system 100 can additionally retrieve dataset information 310 regarding a driver from database 108. Dataset information 310 with respect to the driver may include driver service restrictions, driver and / or service history, driver favorites list, driver blacklist, and so on. It is understood that the database 108 may store information 302 regarding a customer and dataset information 310 regarding a driver for a plurality of customers and drivers, as well as any other required data 308.

[0101] The driver may initially set various limits that are intended to limit the volume of service requests that the driver would like to provide, and which are taken into account when determining which driver is suitable to fulfill a customer service request. For example, a driver restriction, which refers to the distance from the current driver's location to the landing location, may prevent the computing system 100 from displaying a driver for a particular service request whose distance from the ordered pick-up location is greater than that driver's distance at a given time. originally set as location or distance limitation. The driver can prioritize various pre-set limits to resolve potential conflicts when they arise. In addition, the driver's initial distance limitation to the pick-up location may restrict inappropriate service requests 1010 displayed on the electronic map display 1000. Likewise, the driver may not appear as a potential option to the customer if a pre-planned service switches to an on-demand service.

[0102] Historical data retrieved by computing system 100 for each driver may include information about whether the driver was previously directed by a specific dispatcher serving the current package, or automatically directed by computing system 100, whether the driver has reserved any specific zip codes where he / she prefers to provide the service, the number of times the driver has previously processed route service requests from the sites present in the service request (directly or indirectly), and the driver's rating (e.g., user rating, the number of times that he / she canceled trips and / or was rejected or blacklisted by customers, etc.). Each of these factors can be assigned a specific weighted value by the computer system 100. Historical data may also include driver identification number or name, home address, preferred location or geographic region of service, preferred business hours, partner list, favorites list, blacklist, planned trips list, and accepted trips list. These other factors related to customer preferences, driver restrictions and other customer and driver related information can be used in assigning drivers to fulfill service requests or their route sections. Various algorithms and weights can be used to fulfill driver assignments in accordance with the systems and methodologies discussed in this document. It should also be clear that if any drivers outside of the originally retrieved potential set of drivers identified for the service request package (discussed in more detail below) are in close proximity to the pickup location as per the service request and are ready to accept the order, then computing system 100 may designate one of these drivers if that driver is compatible with the client (eg, is not on the client's blacklist, does not have a client on its blacklist, and is not excluded by any absolute discrepancy between client preferences and driver restrictions).

[0103] Depending on the information 302 regarding the client and the data set information 310 regarding the driver, a scheduling matrix 322 may be implemented to exclude one or more drivers who cannot provide the service for the service request 300 due to one or more aspects of the service request 300 and / or that do not want to provide the service to that particular customer depending on a set of "compatibility" rules. If, for example, driver restrictions (included in the driver dataset 310) conflict in some way with the service request 300 (for example, if the service request 300 includes a trip from Brooklyn to Manhattan, and dataset information 310 regarding driver indicates that the driver's choice is not to provide service in Manhattan, or if the service request 300 includes boarding at 7:00 a.m. and the driver dataset information 310 indicates that the driver wishes his / her earliest time for picking up customers was 8:00 a.m.), then such drivers can be excluded from the eligible driver set 320 generated by computing system 100.

[0104] In some embodiments, driver location data 324 and / or traffic and mapping data 326 can be retrieved by computing system 100 and taken into account when the system determines whether a particular driver is compatible enough to be included in a qualifying driver set. 320. Driver location data 324 may include an originally established location and / or a relatively current location of the driver, or a location where the driver should be at a specific time. Traffic and / or cartography data 326 may include geographic information, traffic information, and travel times associated with specific areas. It is understood that the database 108 may include driver location data 324 for a number of drivers and traffic and mapping data 326 for a wide variety of geographic areas.

[0105] In certain embodiments of the invention, computing system 100 generates a compliant driver set 320 and scheduling matrix 322 from the service request 300, customer information 302, driver data set 310, and / or driver location data 324 using the function processing in which different variables with different priorities are processed. For example, the received service request 300 may include a variety of details, such as information regarding times and locations that one or more customers wish to travel to. Additionally or alternatively, the calculations may include driver location data 324 and traffic / mapping data 326 (eg, routes, traffic information that includes traffic patterns, traffic congestion, etc.). In addition, a driver priority may be set, which includes a specific "weighted value" assigned to the driver indicating how well a particular driver matches the service request 300, customer preferences and customer favorites, and / or indicating the ability of the driver to serve this request at the place where he / she should be at the time of boarding (data 324 on the location of the driver), and the expected traffic patterns (data 326 on traffic and cartography).

[0106] For example, two of the compatible drivers 320 who are both familiar with the specific route of the service request 300 and do not have any service constraints that prevent the service request 300 from being fulfilled may be assigned the same weighted priority for these factors ... However, if one of the two drivers is in the user's favorites list and the other is not, then the driver in the favorites list may have priority over the driver not in the favorites list, and thus, he will be given a higher driving priority. Depending on the various driving priorities set in the scheduling matrix 322 for a qualified set of drivers 320, the computing system 100 generates a dispatch output 330. Dispatch output 330 may include a display of a selection of potential drivers and may be automatically sent to the client by the computing system 100, or may be viewed, for example, by a third-party administrator 134 serving the computing system 100 and then sent to the client. The dispatch output 330 may be a subset of the eligible set of drivers 320, or all of the eligible set of drivers 320, depending on how many drivers are selected for the eligible set 320 and depending on how many driver parameters the customer wants to view. The client can then select a driver from a list of drivers included in the dispatch output 330. The driver selected by the client may then be able to accept the request, or may be scheduled automatically (discussed further below with reference to FIG. 4B).

[0107] If the driver accepts service requests, he / she can see the status of the accepted service requests in his list of service requests, marked as "Accepted". The driver can then select one or more service requests for the joint launch. After the driver selects more than one service request and takes action on the first service request, a list of all selected service requests can be presented to the driver through one of the driver's devices 132D1 ... 132Dn for reference, and the driver can update the status of each request for service. For example, each service request might have buttons for Navigation, Arrived at pick-up location, Start journey, Arrived at drop-off location, and so on. If there are more than one service request, then the driver processes them at the same time, and then the driver can decide to board and disembark in sequence. A signature feature can be added to the system to electronically subscribe customers before or after completing a service request.

[0108] Each of the driving devices 132D1 ... 132Dn may also include a lock screen that locks out other functions so that the only item that appears is a notification that asks the driver whether or not to confirm the trip. Such notification may contain details of the trip, such as pick-up location, pick-up time, destination and drop-off time, but without any other interactive feature other than asking "Yes" or "No" to confirm the trip.

[0109] Pre-scheduled service requests may be displayed in a list, each with a heading "Assigned" or "Not assigned" in a status column. Drivers can be given two options: accept or reject. If the driver accepts a service request, the status column of the service request list in that service request may display “Accepted”. If the driver rejects the service request, “Rejected” may be displayed in the status column of the service request, and the name of the pre-scheduled driver may be displayed for reference. Service requests that are removed from the updated list or version depending on the entries in the database 108, or requests that are marked "Canceled" in the updated version, may be stored as canceled service requests in the computing system 100. If some canceled requests services were originally assigned to drivers and started, the system can mark or save them as "Canceled after start", and the driver's name can be additionally recorded for further reference. If new service requests are received that did not appear in previous service request scheduling updates, such new service requests may be displayed to the dispatcher and given high priority to remind dispatchers to find a driver and dispatch such requests for service as soon as possible. If dispatchers receive new service requests, such as by phone, email, text message, etc., they can be manually entered into a service request list and subsequently assigned to drivers who can either accept or reject them.

[0110] In some embodiments of the invention, the system may determine the compatibility between the client and the driver for a service request by comparing various factors related to the constraints and preferences of each user. For example, if a driver has not indicated an ability to speak Mandarin Chinese, and the customer prefers a Mandarin-speaking driver for all of their potential drivers, then all service providers who do not speak Mandarin Chinese may be counted by the system. incompatible. Regarding the time limit, the driver's time limit can be compared to the estimated travel time to fulfill a customer service request, including the time the driver can be en route from the trip to the pick-up location, to the drop-off location, to the return location. starting point, if applicable. If the estimated travel time exceeds the driver's time limit (for example, the driver will not be able to get to the place where he / she should be at a certain time), then the driver or service provider may be considered incompatible for that particular service request. The system can also compare the driver's location limit with the route of a given service request. If the driver has indicated that he / she does not intend to be in certain areas, then in situations where the client's pick-up or drop-off location includes at least one of these areas, the driver may be considered incompatible with the request. Each customer is free to choose in their sole discretion which factors or features, if any, relate to his / her compatibility preferences for matching with drivers for pre-planned services, as well as the degree / measure to which each feature applies. The system may be configured to perform a weighted value calculation based on predetermined client priority levels for various driver preferences, driver's vehicle, driver capabilities, and / or whether a particular driver has such preferences or not.

[0111] It should be understood that location constraints can greatly affect where a driver ultimately provides services, and that the exemplary embodiments discussed herein provide an efficient dispatching system that can utilize various specific geographic regions in as a factor in planning service requests. These regions can be defined by both country and smaller administrative categories such as state, county or district, city district, and even zip code. The system can be configured to identify where service requests are made, in particular start and end locations, as they are related to the time at which service requests are scheduled and can group them by region. It is understood that such grouping, using the information in the database 108, will provide increased efficiency over the standard ad-hoc dispatch practice. For example, in a large city like New York, a driver may be sent at random times to random locations. In the NEMT industry, a driver can, for example, drop a customer in the Bronx and be immediately dispatched by a dispatcher to pick up another customer in Far Rockaway, Queens. While both of these locations are within the New York City metro area, they are geographically relatively far apart. In addition, after considering the difficulties of traffic and navigation in New York City, travel times between the two points can easily exceed an hour or more. By grouping service requests according to geographic area and by tracking drivers, dispatch service can be performed more efficiently, allowing drivers to fulfill more service requests in less time. It should also be appreciated that such grouping will make it easier for dispatchers to plan ahead of service requests with much higher efficiency.

[0112] It is understood that the systems and processes described in this document will allow for planning ahead of time for service requests and driver assignments, regardless of whether such planning is intended in advance to provide the service on the same day, to provide the service just a few hours in advance. or to provide a service in days or weeks. By storing customer-specific information, driver dataset information, driver location data, and traffic and mapping data in the manner described above, computing system 100 can quickly filter out a large number of drivers in database 108 and match a service request against a selected list. drivers deemed most compatible with the customer and his / her service request, and based on the driver's location or estimated location. It is understood that such processing allows computing system 100 to operate more efficiently as it can quickly focus on more compatible and geographically close drivers.

[0113] Now referring to FIG. 4A, shown is a flowchart illustrating an exemplary dispatching operation in accordance with an embodiment of the present invention. The process begins with computing system 100 downloading or otherwise receiving service requests 300 (block 400) that may be downloaded by the provider and / or submitted by the customer. Computing system 100 can download service requests 300 automatically based on programming steps, or a dispatcher can manually download service requests, such as clicking a download link on a web portal or refreshing a pending request page. Computing system 100 may be configured to accommodate multiple ways in which service requests may be populated and updated to reflect any changes. For example, computing system 100 can be configured to access web portals from appropriate vendors or an application program interface (API) to download a list of service requests. To ensure that the list of service requests reflects the most recent changes, computing system 100 may perform such downloads periodically at specific intervals (eg, every 5 minutes, every 15 minutes, every 30 minutes, etc.). Vendors can also submit and edit service requests through a vendor module (eg, vendor device 126). In any event, computing system 100 then processes the updated list of service requests and compares them to past service requests based on historical records stored in database 108 to determine if there are similarities (block 402).

[0114] Computer system 100 then determines whether its details match any previous service requests stored in database 108 (block 404), such as, for example, matching customer name, pick-up location, and / or drop-off location. If no match is found, then a service request 300 is sent for new data processing (step 406) during dispatch. However, before sending a service request 300, the system identifies any filtering conditions (408) (e.g., route awareness, previous number of service requests made for a customer, two-door or four-door vehicle, etc.) that the request may contain. 300 for service and negotiates these filtering conditions, for example by comparing them with the corresponding parts of the driver restrictions in the database 108 and preventing certain drivers from being selected to fulfill the service request (for example, a service request requires the driver to speak a certain language fluently and the driver does not speak a particular language). If matching records are found (step 404) or after processing (steps 406/408) new service request records, computing system 100 searches for records in database 108 to determine if the selected customer driver is available for the service request to complete the request. 300 for service (block 410).

[0115] If it is determined that the selected driver is available (Yes, step 410), then the computing system 100 sends a service request 300 to the selected driver for confirmation (step 412). If it is not determined that the preferred driver is available (No, block 410), then the computing system 100 searches the database 108 to determine if the preferred driver is available (block 414). If a preferred driver is available (Yes, block 414), then computing system 100 sends a service request 300 to that preferred driver for confirmation (block 412). If no selectable or preferred driver is available (No, block 414), then computing system 100 determines if a regular driver is available (block 416). If the regular driver is available (Yes, block 416), then the computing system 100 sends a service request to the regular driver for confirmation (block 412). If none of the regular drivers are available (No, block 416), then computing system 100 continues to track all drivers in order to identify and schedule (block 420) the next available driver. Once the available driver is identified, a service request 300 can be sent to the identified available driver (block 412).

[0116] If the first normal driver to whom the request 300 is sent in step 412 does not receive the service request, then the system may repeat the process until another driver is identified (step 420). When a driver receives a service request 300 on his driver device 132D1 ... 132Dn, that driver has the option of either accepting or rejecting the request (block 418). If the driver receives the service request 300, then that driver is assigned to fulfill the service request (block 422). However, if the driver denies the service request 300, then the computing system 100 returns to block 410 and checks again if there are any of the select drivers available. If there are no favorite, preferred, or regular drivers available, then after a certain amount of time, it may be necessary to notify the dispatcher so that he / she can complete the process of identifying another driver (block 420).

[0117] After the service request is fulfilled, the driver can make additions to the driver's favorite customer list and / or to the driver's customer blacklist. For example, the driver may be asked if he / she was satisfied with the customer. If the driver was not happy with the customer, he can add the customer to the driver's customer blacklist, in which case the driver and customer will not be matched together for future service requests. If the driver is neutral in his attitude towards the customer, he does not need to take any action, and the customer will not be added to the driver's favorites list or to the driver's customer blacklist. If the driver is satisfied with the client, he can send the client a request, which will be the basis for adding the client to the driver's list of favorite clients. In such embodiments, it is up to the client to decide whether or not to accept the request. If a customer declines the request, they are not added to the driver's favorites list. If the customer accepts this request, he / she is added to the driver's favorites list. The next time a driver provides a service to a customer, he may be asked again if he was satisfied with the customer. If so, then the driver can keep the customer on his favorite customer list until the driver next serves the customer, in which case the request will reappear, and so on. Thus, the driver can be questioned regarding his / her customer satisfaction at the end of each service request. If the driver is not satisfied with the customer, he can remove the customer from the driver's favorites list.

[0118] Likewise, a customer can make an addition to his / her favorite driver list and / or his / her driver blacklist after completing a service request. The customer can be questioned as to whether he / she was satisfied with the driver. If the customer was unhappy with the driver, he / she can subsequently add the driver to the customer's driver blacklist, in which case the customer and driver will not be matched together in future service requests. If the customer is neutral in terms of his / her attitude towards the driver, they do not need to take any action and the driver will not be added to the customer's favorite driver list or the customer's driver blacklist. If the client is satisfied with the driver, he can send the driver a request, which will be the basis for adding to the client's list of favorite drivers. In such embodiments, the driver can decide whether to accept the request or not. If a driver declines this request, he is not added to the client's favorite driver list. If the driver accepts this authorized approval, he / she is subsequently added to the client's favorite driver list. The next time the driver serves a customer, the system can ask the customer again if he / she was happy with the driver. If this is the case, then the client can keep the driver in the list of favorite drivers until the driver serves the client next time, in which case the request may appear again, and so on. At the end of each service request, the customer can be questioned regarding his / her driver satisfaction. If the customer is dissatisfied with the driver, they can remove the driver from their favorite drivers list. Computing system 100 may be configured to determine which driver completed the service request the most times and attempt to add that driver to the client's favorites list. If that driver is not available, then the computing system 100 may be configured to designate another selected driver who is second after the driver who completed the service request the most times, the driver who is third, and so on.

[0119] When a client indicates that he / she wishes to add a driver or multiple drivers to his / her blacklist of drivers, the client may be prompted for a reason (s). It is understood that skipping blacklisted drivers automatically improves customer service efficiency and processing speed of the computing system 100 when the dispatch matrix 322 and dispatch output 330 are generated. It should also be understood that driver blacklists will serve as an incentive for drivers to generally improve their level of service. The driver may understand that he / she needs to improve the service in order to get more job offers.

[0120] A driver can refer a customer from his / her favorite customer list to another driver. For example, the two drivers involved in such a process might be named Driver 1 and Driver 2, and the client is named Client 1. Driver 1 may indicate that he wants to send the selected client, Client 1, to another driver, Driver 2. An authorization request is first sent Client 1 to give him / her the choice to authorize the redirect or not. If Client 1 does not authorize the redirect, then no redirection occurs. If Client 1 really authorizes the redirection, then Driver 2 is notified and gets the opportunity to accept this redirect or not. If driver 2 does not accept the redirect, then no redirection occurs. If Driver 2 accepts the redirection, then Driver 2 is given a service request to complete and Client 1 can be added to Driver 2's favorites list. Similarly, Driver 2 can be added to Client 1's favorite drivers list.

[0121] Users of the computer system 100 can make redirects to other users of the computer system 100 as long as both users are registered. For users receiving a redirect from someone on the blacklist or favorites, information such as dataset information about the person in question may be provided to the user receiving the redirect. Computing system 100 may similarly provide information to the specified party about the user they are accessing. For example, a second client receiving information about a driver can see in the data set information of that driver that he / she has been seen absent in the past, and the client may decide not to add this driver to his / her favorites list.

[0122] Clients can also send a driver from their blacklist to other clients. Referring clients can send individual drivers, groups of drivers, or complete lists of blacklisted drivers to one or more other clients. Drivers can send other drivers customers from their favorites list. Referral Drivers can send individual customers, groups of customers, or entire favorites lists to one or more other drivers. The driver can highlight one or more predefined reasons or a note describing why he / she is referring the selected customer or customers. Such a process could start, for example, with Client 1 indicating that he wants to direct Driver 1, who is in Client 1's favorite drivers list, to another client, Client 2. However, before the redirection is completed, a request is sent to Driver 1 for authorization and the choice is given - to authorize the redirection or not. If Driver 1 does not authorize the redirect, then no redirection occurs. If Driver 1 accepts the redirect, then Client 2 is given the option to accept the redirect or not. If Client 2 does not accept the redirect, then no redirection occurs. If Client 2 accepts the redirection, Driver 1 is added to the list of favorite drivers of Client 2. Similarly, Client 2 can be added to the list of favorite clients of Driver 1.

[0123] Computing system 100 may provide information to the dispatcher indicating which service requests remain unassigned. Such information can be presented using a map display with labels that identify a service request or customer number. On the same display, the dispatcher can see drivers who are near the locations of unassigned service requests. Various indicators can be used on the visual display to distinguish an available driver from an unavailable driver so that the dispatcher can immediately know which driver (s) to whom he / she should assign to fulfill a service request. For example, an available driver can be marked with an indicator that shows a white car, while an unavailable driver can be marked with an indicator that shows a black car. A person skilled in the art will understand that the indicators described herein are not intended to be limiting. Instead, they are illustrative as exemplary embodiments of the present invention.

[0124] Accordingly, the system can provide sets of indicators to better assist users, including drivers and customers, schedule a service or receive a pre-planned service. Various sets of indicators can be provided to facilitate the communication of information. Indicators can display this information using one or more letters, numbers, icons, symbols, or other graphical representations of information that can be displayed in the user interface. For example, a set of indicators may be provided to convey the estimated travel time (ETT) from the customer pick-up location to the customer drop-off location specified in the service request. A service request can contain multiple pick-up and drop-off points if the pre-planned service request contains more than one leg of the route. This set of indicators transmitting ETT combines location information associated with the customer's pickup location and the customer's disembarkation location in a pre-scheduled service request. Preferably, such indicators are displayed to inform the customer of the estimated travel time or to inform the driver of the estimated travel time for fulfilling a service request. Such indicators may be based on the estimated travel time from the embarkation location to the disembarkation location, which may be provided by a third-party mapping API such as Google® Maps. From the driver's point of view, this can be the time from the current location to the pick-up location and from the pick-up location to the drop-off location, an additional stage. This can also change if the customer's pre-planned service request contains multiple sections of the route. Such indicators may also include the time it takes for the driver to return to the origin return locations from the drop off location if the driver has set an applicable home return location constraint. From a driver's perspective, ETA also means the time it takes to complete a service request. However, from the customer's perspective, a completed service request is only the time from the pick-up location (s) to the drop-off location (s).

[0125] A set of indicators may also be provided to determine the more specific readiness of drivers. Such indicators can be shown on the electronic map to both customers and dispatchers, while the driver can be shown on the electronic map only in an active state. Such indicators may also include information about the days that the driver is ready based on the days and / or times that the driver has set in advance. For example, such indicators can represent availability and duration of the availability period, as well as the uncertainty of availability. Such indicators can be removed if the driver is shutting down or completing a service request. Alternatively, such indicators can be provided to identify whether a customer service request has been assigned to a driver. Such indicators can be shown to dispatchers on an electronic map display, thus providing a visual indication of which trips are still awaiting destination, and they can be configured to automatically disappear from the dispatcher interface if a driver is dispatched to fulfill a service request (for example, as soon as the service request is no longer unassigned).

[0126] A set of indicators may also be provided for transmitting information about the driver's geolocation at a given time and the location of the driver's return to the starting point if the driver has predetermined the location of returning to the starting point. Such indicators can be provided for the dispatcher to view on his / her touchscreen electronic map display, so that the dispatcher can assign a service request to the most compatible driver. In another embodiment of the invention, a set of indicators may be provided to convey information about the indicated pickup and drop off locations, as well as the locations of the first and second sections of the service request route, as planned in advance by the client. Such indicators can display location information associated with a service request to a dispatcher or driver on a touchscreen electronic map display. The touchscreen display allows the customer to make choices about the service request and can be equipped with touchscreen sensors that can be pressed or otherwise respond to touch. The signals that are received by the sensors on the touchscreen are what the processor can take as input, and these signals can be converted into output that prompts the system to make choices made by the customer or driver.

[0127] A set of indicators may also be provided to show the customer the driver's estimated time of arrival (ETA) at the ordered pick-up location. To generate a driver's ETA, the system, using a third-party API such as Waze®, can identify the driver's current speed in real time, such as the transport speed along a potential route from the driver's current location to a pre-planned pickup location. Alternatively, a set of indicators can be provided to show the driver the customer's estimated time of availability (ETR). Such indicators can show, for example, when a client intends to be ready to board, if the client has planned a second leg of the route during the trip. For example, a client at a doctor's appointment can enter into one or more client devices 130C1 ... 130Cn, data that he / she estimates he / she will be ready to travel in the opposite direction in thirty (30) minutes. The functionality of the ETR indicator can improve the efficiency of the provision of pre-planned services. It is clear that such advance planning and ETR estimates can help drivers reduce downtime. With the help of the ETR indicators, the driver will be informed about the current status of the customer and, if the ETR is long enough, he will be able to fulfill another service request during this time.

[0128] This functionality is especially useful in the case of multi-leg journeys. The first driver to provide service to the first customer on the first leg of the route may, depending on the ETR indicated by the first client, decide whether to wait for this first customer on the second leg of the route or accept a second, different from the first, service request. If the ETR of the first customer indicates that he / she may not be ready for some time, then the first driver may decide to take the second service request and wait for it to be completed by the time he / she is ready for the second stage. Even if the first driver is considered the preferred driver for this first customer, if the system, depending on the ETA, detects that the first driver cannot arrive on the second leg of the route in time, then the system can notify the first customer. In this situation, the first customer will be able to either agree to wait for the preferred driver to complete their second service request, or request reassignment of the second leg of the route to another driver. If the second leg of the route is transferred to another driver, a preliminary calculation of the value is sent to this other driver when it will be necessary to be at the pickup location to complete the second leg of the route, which can be transmitted by the ETR indicator.

[0129] In order to better assist the customer in selecting the best appropriate service provider for the service request, the system provides several sets of indicators. Extensive adaptation in accordance with their requirements can be allowed for both the client and the service provider. However, various information, including, but not limited to, the listed price, identification of the number of service requests completed, familiarity with the route according to the service request, etc. can be difficult for the user to navigate when making a service request. Since the client and the service provider need different information, the indicators will differ depending on what information may be required. Service providers and clients can tailor their experiences, expectations and preferences according to their requirements using different sets of indicators. Exemplary embodiments of the present invention provide at least twenty-six (26) customizable indicator sets to optimize this multipurpose information. The system will display unified indicators to avoid confusion, but users can also change some of the indicator sets. For example, users may want to replace the default symbol or icon that represents the indicator with their own symbol, such as an emoji icon or shorthand for his / her own user ID. In addition, explanations of what each indicator means can be provided, and both customers and service providers can enable or disable these explanations, or temporarily hide them. If they turn them off, they can still turn on the explanation again for any indicator or for all. For example, new users may prefer to have explanations, while those who have used the services for a while and are familiar with them may not need to explain the meanings of different sets of indicators. Customers and service providers can also change the order in which indicators are displayed if they want to prioritize one set of indicators over another.

[0130] Indicators are a means for transmitting or displaying service-related information to a client, service provider, or both, in a simple, fast and convenient manner. Several sets of indicators are used to assist in the selection of the appropriate service between them, as well as to adapt according to their requirements, both by clients and service providers. Clients and service providers may have different indicators on their respective interfaces, but they can also, if they wish, see each other's indicators. In addition, for some indicators, there may be a multi-level system that includes a range of numbers with a minimum and maximum value, and each level represents a different value for different customers and service providers. Below is a brief description of the preferred sets of indicators. A more complete description of these indicators is given in the '783 application, the contents of which are fully incorporated into this application by reference.

[0131] The first set of indicators can identify the type of user for drivers in three categories, which include, but are not limited to, favorite, preferred, and regular drivers. The second set can also identify the type of user for customers in three categories, which include, but are not limited to, favorites, preferred, and regular customers. The third set can identify the availability of service providers, which can be related to the time during which the service providers will remain available to fulfill service requests. The fourth set can identify whether the client is currently requesting a service request, which can tie in the time during which service requests from the client will remain valid. The fifth set can be based on the volume of the service request that the service provider has fulfilled, where numbers related to historical data are related. Thus, they can link numbers to reflect the total number of service requests made by the service provider over a given period of time, where the total is further divided according to a certain period of time and reflected in numbers, levels, or a combination thereof. The sixth set may show one, or more, or any combination of geographic areas depending on one, or more, or any combination of appropriate search parameters preset by the client. The seventh set can be based on the data and information provided by the sixth set of indicators to further compare the total number of potential service providers available with the total number of potential available customers. The eighth set can help to organize the pricing information of the service provider's response to a quote from a customer by linking numerical pricing data. The ninth set may display information regarding the price that was initiated by the service provider if the customer sends a service request without a specified price, and the service provider responds with a proposed price, which can be either negotiable or non-negotiable. The tenth set may associate historical data and geolocation data to display information regarding area information based on the total number of service requests performed by the service provider within the geographic area where the client indicates the landing location in the service request. And, the eleventh set may link historical data and geolocation data to display information regarding the zone information based on the total number of requests made by the service provider within the geographic area in which the customer specified the drop-off location in the service request.

[0132] The twelfth set can convey the level of familiarity of the service provider with the route of the service request, represented by at least a percentage or any other mapping, such as levels, wherein the familiarity is calculated along the route between the pick-up location and the drop-off location specified by the client in the request for service, is compared with the past one or more previous routes of service providers obtained from one or more data records for the past periods about the services of service providers stored in the database. The administrator of the computing system 100, such as a dispatcher, can use design features unique to their job functions by coordinating drivers with different clients. This coordination can be done automatically by route matching software, manually by human dispatchers making decisions about who is likely to be available to service a service request, or some combination of the two.

[0133] This set of indicators can be created by linking information about the ordered route with the service provider records for services stored in the database. For a transport request, this information may include the service provider's knowledge of the route specified in the service request; for a delivery service, this can be information such as the experience of service providers or familiarity with the route. Regardless of the type of service request, the indicator is configured to display information relevant to the situation. The percentage can be displayed as a percentage by itself, or it can be divided into levels, for example, level E indicating familiarity between 0-19 percent, level D for 20 39 percent, level C for 40-59 percent, level B for 60-79 percent and grade A for 80-100 percent. The representation of a level does not have to be limited to the letters A through E, or even letters in general, since the levels can be shown as any single image or combination of images that divide the awareness percentage into levels. Level and percentage can also be shown together. For the service provider, this can be a useful indicator in assessing where he / she has landed a large number of clients, or where he / she has landed only a few clients. This set of indicators can be used by service providers to assess where they have the most experience, or it can be the most valuable, or it can be used by the client in selecting the best appropriate service provider based on the experience he / she may have in relation to service request.

[0134] A service provider's awareness is linked to context in two ways: "direct" or "indirect" awareness, and each type is different. Direct awareness is a calculation of how well a service provider is familiar with a particular route, for example, from pick-up location to drop-off location — where everything is done in a single trip. Indirect familiarity, in contrast, is a measure of how familiar the service provider is with the route between embarkation and disembarkation locations, but this familiarity may be related to partial experience on the route. For example, two service providers are 100 percent familiar with the route; The first service provider previously provided service along the same route to the customer from the same pick-up location to the same drop-off location. This is a direct knowledge, and in addition to the 100% conformity assessment, by number or by level, it can be indicated that the service provider provided the service along the same route. The second service provider also has 100% familiarity, however, one part of the route that he / she provided to another customer in the past, and another part of the route was also included as part of the route in another service request. Although the service provider traveled the entire length of this route, the route was not from the same embarkation location to the same disembarkation location. The service provider's awareness of the route is indirect. The degree of familiarity with the ordered route, direct or indirect, will be calculated by comparing the ordered route with the routes of service requests previously performed by the same service provider, by tracking how the entire route as a whole or any part of the ordered route relates to routes previously completed service requests. The service provider's familiarity with the ordered itinerary is especially important when any part of the ordered itinerary is within an area known as one with weak or no GPS signal, or when a service request is made after dark, making it difficult to navigate. instructions.

[0135] The thirteenth set of metrics may be based on how many times the client and service provider have been matched and jointly completed the transaction. The fourteenth set may associate the service provider location information with the customer pickup location information to display the time that the service provider can pick up the customer, the estimated time of arrival (ETA). The fifteenth set may be based on the estimated travel time (ETT) from the customer pickup location to the customer drop-off location specified in the service request. The sixteenth set can link geolocation data to display at least the pickup and dropoff locations of the customer specified in the service request. The seventeenth set can convey information about the total number of service requests ordered and executed by the customer. The eighteenth set can identify one, or several, or any combination of geographic areas depending on one, or several, or any combination of search parameters predetermined by the service provider. The nineteenth set can be based on the eighteenth set of indicators to further display the number of potential service providers available versus the number of potential customers available. The twentieth set can simplify the display of customer-initiated quotations where numeric data related to pricing information is linked and displayed. The twenty-first set may contain details of the customer's bid, which is a response to the service provider's bid, where the numerical data relating to the pricing information is linked and displayed using this set of indicators. The twenty-second set can link historical data related to customer service request history and geolocation data to identify a customer based on the number of service requests he / she requested and fulfilled based on the geographic areas of the pickup location. The twenty-third set can identify the customer by the number of service requests he / she has requested and fulfilled, based on the geographic zones of the drop-off location, where geolocation data and historical data of the service request are linked. The twenty-fourth set may concatenate historical data from the service request to display how many times the service provider and client have matched each other and performed a transaction together. The twenty-fifth set can identify the estimated travel time for fulfilling the service request for the service provider. And, the twenty-sixth set may associate the geolocation data of the service provider and the geolocation data in relation to the return location predetermined by the service provider after the service request has been executed if the service provider has previously established the return location.

[0136] In addition, any indicator that is based at least in part on counting values can also be reflected in terms of levels. The levels assigned by the system can be ranges of numbers with minimum and maximum values depending on whether they apply to customers or service providers, and also depending on whether it applies to the provision of transportation services, delivery services, or both, and another. They can be displayed as letters, shapes or colors, or in any other way that shows the difference between each level. The indicators of some clients and service providers may have different meanings. Indicators show activity regarding their user type, category and subcategory. Because the system stores records of service requests in the system's database, it can quantify when they were completed or completed using timestamps, and where they were completed by requesting details. However, these records of time or other numbers can be scaled to a greater or lesser extent, where the client can divide the time frame as needed, for example, one or more days, one or more months, or one year or more years. All of these various customizable search parameters, whether they are time, time period, zone or other numeric data, are designed to be customizable so that the client and service provider can personalize and prioritize the information they want to see.

[0137] Supply and demand related to the service provider can be displayed using search parameters predefined by the client, depending on the time the client expects to land at the pickup location, at a distance from the pickup location, and the number of performers desired services with which the customer wants to negotiate a price for a service request. The time-based search parameter can create a search radius and can include identifying all service providers on all possible routes leading to the landing location, identifying real-time travel speed along each of the possible routes, multiplying the travel speed of each service provider along the possible routes for the maximum time specified by the client in order to calculate the maximum distance that service providers can travel within the maximum time specified by the client, identifying the client's landing location as the center point of the search radius and determining the limit point for the search radius that can be the farthest location of the service provider in the search parameter or some other point that is at a distance predetermined by the client. The supply and demand for a service request within the search parameter can be displayed to the customer as the number of potential service providers ready to provide the service versus the number of potential customers available for demand.

[0138] Initial setting of search parameters by the client may include initial setting and searching for the desired number of service providers, as well as creating a search radius by specifying the landing location as the center point for the search radius and determining an extreme point for the search radius, which may be the farthest location from the central point of the service providers. The search radius can be less or greater than the search radius, which is based on time or distance, and the estimated time of arrival of the service providers can be identified to the client using indicators. The number of service providers identified within the search radius can be prioritized for negotiating a price for the client.

[0139] Clients and service providers can have various indicators displayed on their own interfaces. Some of these indicators may be specific to the type of user, whether he is providing a service or requesting a service. Preferably, some indicators are more useful to clients, while some are more useful to service providers. However, the indicators are not intended to be displayed exclusively to service providers or only to customers, as indicators that are preferably displayed to one party may reflect information useful to the other party. However, if users choose, then through the system they can view their own information. If they are interested in seeing their own indicators or their service request history, to ensure that the indicators that other users see regarding their service request history are correct, they can do so using their dataset of information, or by any other means indicated by a system that shows all the indicators that relate to them. This service request history can include information that other parties can see, such as indicators regarding the total number of service requests completed or ordered. Service request history can also provide information that other parties cannot see, such as personal information about how much money they made or spent. All such indicators are intended to provide customers and service providers with customizable information that can help them select the best appropriate service provider or customer, respectively, in order to close a good deal with each other. It is understood that additional indicators can be designed and / or used to be deployed across one or more computing devices as a means for visually communicating summary data of other types of related information.

[0140] The first action a driver can take to accept a service request is to press the Accept button on the driver's device 132D1 ... 132Dn. When the driver is ready to start service, he / she can press the Start button to indicate that he / she is on the way to the pickup location. The driver can also call the customer to notify him / her that he / she is on the way. If at any time after pressing the Start button the driver needs to cancel, he / she can do so if, for example, he / she has punctured a wheel or if the driver's vehicle is experiencing a mechanical failure, or any other justified reason for canceling the order appears. In such circumstances, the driver may provide reasons for canceling the order and cancel the service request, in which case the service request may be re-sent to another driver, such as a partner driver.

[0141] Drivers can cancel service requests at any time they wish. If drivers cancel an order one day in advance, they may not need to provide a reason for canceling the request. In such cases, dispatchers can reschedule and resubmit the request to the new driver. If drivers cancel requests on the day the service requests are due, drivers can provide a justification for canceling requests by choosing from possible default reasons or by typing in the reasons. If, after canceling the request, there are no drivers willing to accept the service request, then the service request may return to the service request list on the main dispatcher web portal to be assigned to other drivers. After the dispatcher reschedules and resubmits service requests, computing system 100 may be configured to send another notification to the client, which may include the name of the previous driver, the reason the previous driver cannot provide service to the client, the name new driver, new driver's phone number, manufacturer, make and color of the vehicle, pick-up time, etc. The customer can change or cancel the service request at any time. If, when boarding the vehicle, the client wishes to change the destination, the driver can change the route for the given destination. Once the driver and customer arrive at the drop off location, the driver may ask the customer to sign a service request as confirmation that the service has been performed correctly and / or satisfactorily. Upon completion of these steps, the service request ends.

[0142] It is understood that scheduling in advance the departure of drivers gives individual drivers the freedom to choose which service requests to accept or reject. Computing system 100 can provide the driver with the functionality to select potential service requests, for example, using an electronic map showing available routes for the current day, next day, next week, etc. This takes into account driving time and location restrictions using current and / or future predicted traffic and other events that may affect travel time (e.g. construction, road closures, accidents, etc.) or location driving restrictions ... Such data can be stored in the database 108 and provided to the dispatch matrix 322 as part of the traffic and cartography data 326 (see FIG. 3).

[0143] Next, referring to FIG. 4B, depicted is a flowchart illustrating an exemplary sequence of steps for a client or driver to cancel a pre-scheduled service request after the exemplary service dispatch operation shown in FIG. 4A, and a new process for replacing the canceled driver. The driver or customer can cancel a pre-planned service request at any time. If the driver (or customer) cancels a pre-planned service request sufficiently in advance (eg, one day, one week, etc.), then the driver (or customer) does not need to communicate the reason for canceling the request. In such circumstances, dispatchers or computing system 100 simply cancels the service request if canceled by the client, or reschedules and resubmits the service request to a new driver. However, a different process can be used to replace a driver who canceled a request at short notice.

[0144] Specifically, as shown in FIG. 4B, after the service request 300 has been scheduled for the driver (block 422), the computing system 100 may send a notification to the client (block 424) indicating that the service request 300 has been scheduled. If the driver does not cancel (block 426) and the client does not cancel (block 428) the request, then the service request is executed (block 430) as scheduled and the process ends (block 432). The driver can then start the billing process. However, if the client cancels (step 428) the request, for example, through one of the client devices 130C1 ... 130Cn, then the client can be interrogated to indicate the reasons for canceling the request (for example, an appointment is canceled, another person has brought the client, the service is no longer valid and etc.) (block 434), and the process ends (block 432) without the need for billing. The designated driver can then be sent to another location. If the driver cancels (block 426) the request, then the computing system 100 must send a new driver. In one embodiment, computer system 100 sends a service request 300 based on one or more partner drivers identified by the canceling driver if the client has a predetermined permission to enable partner drivers (block 435). If so, then the notification is sent to the partner driver for confirmation (step 437). If the client does not have a predetermined permission to use partner drivers, then the service request can be sent for processing (block 439) as part of the dispatch escort. The classification of the partner drivers can be stored in the database 108 for quick access by the computing system 100. In this case, the service request 300 can be sent to the partner driver (block 436) to complete the service request 300. Optionally, the service request 300 can be sent to more than one potential driver partner, and a list of these best-matched driver partners can be displayed for customer selection. If the partner driver selected by the customer receives the service request (block 437), then that partner driver services the service request (block 438).

[0145] The method used to select a partner driver to provide a service for a service request (or a list of partner drivers who can provide a service for a service request) may be similar to methodologies for creating a compliant driver set and dispatch matrix discussed above with respect to FIG. 3. In other words, it can include assigning a specific driver priority to a potential partner driver, assessing availability, restrictions, etc., and the client can use these considerations to make a choice of their own. Alternatively, one partner driver can be associated with each driver in such a way that the partner driver, if available and not on the customer's blacklist, is automatically assigned to a service request at the time the previously assigned driver's request is canceled. After confirming the partner driver as a substitute for the canceled driver, the partner driver ends the service (step 438) and the process ends (step 432). The partner driver can then initiate the billing process.

[0146] If the customer cancels the service request 300 sufficiently in advance (eg, the limit is half an hour), then the service request 300 can be marked "Canceled" and the computing system 100 can immediately notify the driver. Once the driver receives such a cancellation notice, the system can be configured to require the driver to acknowledge receipt of the cancellation of the request. Otherwise, if the driver does not confirm receipt of the cancellation of the request, then the application running on the corresponding one of the driver's devices 132D1 ... 132n may be blocked, so that the driver cannot perform any operations in the application until he confirms receipt cancellation notices. However, if a customer cancels a service request within a short time frame (for example, less than half an hour before boarding time), the customer may be notified by means of identification that he / she canceled the service request in the last minutes, for example, the indication “Canceled for 5 minutes before boarding. ”After a predetermined number of last minute cancellations and / or total cancellations, a client may be added to the system blacklist so that computing system 100 will not schedule any service requests for that client in advance for a certain period of time. The computing system 100 may be configured to send notifications to the client as a warning that after two more cancellations within half an hour, he / she may be blacklisted by the system. The computing system 100 may also provide contact information should the client have any -or questions.

[0147] If the customer service request is canceled by the driver at the last minute, then the service request is immediately resubmitted. The first step in this process is to notify the client that the request is canceled, which may include details about the redirection. In such scenarios, computing system 100 may first determine, for example, the compatibility of a given service request with a driver on the customer's favorites list. If several of them are compatible, then the system can notify these drivers of an available service request, and any of the selected drivers who first accepts the service request is assigned a service request.

[0148] Computing system 100 may be configured to provide drivers with the ability to add clients to their predefined blacklists. Once a driver has added a customer to the driver's customer blacklist, it is skipped by the computing system 100 when looking for suitable drivers to request service for the same customer. To avoid confrontation, the system can be configured so that upon receiving a service request from a customer that has been placed on the driver's blacklist of customers, the computing system 100 will automatically send the request to the other driver and let any drivers that have added the customer to their respective blacklists through. ...

[0149] When a driver blacklists a customer, this prevents the same blacklisted user from being added to the driver's favorite customer list. In other words, a blacklisted user cannot be on the driver's blacklist and on the favorites list of the same driver at the same time. Dispatchers can also receive notifications from the computing system 100 when certain drivers are blacklisted by certain clients, and vice versa, so that they know which drivers not to send for specific service requests if they want to overcome the computer system 100's automatic controls for any reason. because they have a driver in mind who seems better or closer. The Blacklist is mainly for “difficult” clients or drivers who “can't handle”. However, it should be understood that a driver or customer can be blacklisted for any reason. Clients and blacklisted drivers may not automatically be matched to certain relevant drivers or clients, or may be excluded from dispatch escort altogether.

[0150] Predefined "preferences" for the client, stored and dynamically updated in the database 108, may include, but are not limited to, preferences related to pickup locations, drop-off locations, make, model and type of vehicle, a quantitative measure of driving experience expressed in years, vehicle capacity, gender, spoken language, availability of services, availability of medical equipment, accommodation with pets, and availability of a child seat. The pick-up location preference allows the client to determine his / her pick-up location. Preferring the drop-off location allows the client to identify his / her drop-off location. The make, model and type of vehicle allows the customer to indicate the make, model and type of vehicle he / she prefers for his / her service request. The "Years of Driving Experience" parameter allows the customer to pre-specify the number of years of experience that his / her driver should preferably have. Seating Preference allows the customer to specify the number of passengers for his / her service request. Tender preferences allow the client to select a driver of a specific gender. The Spoken Language preference allows the customer to select a driver who speaks a specific language. “Disabled Preference” allows the customer to pre-set a preference for drivers whose vehicle is equipped to serve people with a disability. The Medical Capability Readiness setting allows the customer to ensure that the vehicle has certain equipment, such as oxygen cylinders or other medical devices. Pet Accommodation allows the customer to pre-set a preference for service requests that can accommodate pets. The Child Seat Availability option allows the customer to request a driver who can provide a child seat.

[0151] The customer may also have a preference in terms of how familiar the driver is with the particular route of a given service request. Driver awareness can be "direct" or "indirect" awareness, and both can be communicated to the client via the client interface on the corresponding one of the client devices 130C1 ... 130Cn. Direct familiarity can be, for example, calculating how familiar the driver is with the route from the pick-up location to the drop-off location. Indirect awareness can be a calculation of how familiar the driver is with the route between pick-up and drop-off locations, but from partial experience with the route. For example, two drivers may have one hundred percent (100%) familiarity with a given route, but have different experiences. The first driver may have provided the service along the same route, from the same pick-up location to the same drop-off location. Such experience will represent direct awareness and will be indicated, in addition to a 100% rating for matching routes, with a number or level indicating that the driver has provided service on the same route. In the past, a second driver could serve one part of the route for another customer and another part of the route for another service request. Although this second driver went through the entire route of this service request, the route was not from the same pick-up location to the same drop-off location. Thus, this second driver has an indirect idea of the route of this service request.

[0152] The degree of familiarity with the ordered itinerary, direct or indirect, will be calculated by comparing the ordered itinerary with the service request routes previously performed by the same driver and by tracking how much the entire route or any part of the ordered itinerary relates to to routes previously taken by the driver. It is understood that the driver's familiarity with the ordered itinerary is especially important in cases where any part of the ordered itinerary is within an area known as one where the GPS signal is weak or absent, and / or when a service request is made after dark. making it difficult to follow the navigation directions. It should also be understood that the automatic tracking of GPS data for each driver and the persistent storage and updating of such data in the database 108 can be used to check the driver's level of familiarity with a given route.

[0153] System customization is based in part on customer preferences and driver restrictions. The concept of preferences discussed in this document refers to providing customers with options to impose specific conditions on service requests. Those of skill in the art will understand that the term "preference" is not intended to limit this concept in any way. Other terms such as "condition", "filter condition (s)" or "qualification" may be used instead. The term "restriction" is also in no way intended to limit the concept of allowing a driver to set restrictions on the receipt of service requests. Terms such as "restrictive measures" or "border" can be used instead of "restriction". In addition, the terms "preference" and "restriction" can be used in opposition to each other, and this contrast is intended to convey differences in user types between customers and drivers, rather than for "preferences" and "restrictions" to be fundamentally opposite concepts. ... It is understood that a customer who has preferences may also have limitations, or that a driver who has limitations may also have certain preferences.

[0154] Restrictions on driver services may include, but are not limited to, restrictions related to service times, location and time of return to departure, service area, handicapped service, number of passengers, allergies, child seat restrictions and any other applicable restrictions. Service time limits allow the driver to pre-set a time at which he / she cannot provide the service. Location and return time constraints allow the driver to set specific locations where he / she wants to be at a specific time. Service area restrictions allow the driver to set one or more geographic areas in which he / she does not want to provide services, for example, depending on the zip code, district, city, state, etc. The driver can set limits for geographic areas using an interactive map on the driver's interface of the corresponding driver's device 132D1 ... 132Dn. The driver can “click” the zip code on the map to locate the location where he or she does not want to provide services. Such geographic location constraints for drivers may be required in embodiments of the invention where service requests are grouped and assigned to drivers in groups, as described below with reference to FIG. 6-9.

[0155] For example, a driver in Brooklyn may see a map of the area divided into subsections that display postal codes within Brooklyn. The driver can “click” each to indicate specific service areas. An activatable map interface (i.e., an interactive map interface) allows the driver to quickly and efficiently set his / her restrictions on his / her own conditions (e.g., allows the driver to select the geographic region in which he / she wants to operate). In accordance with exemplary embodiments of the present invention, an interactive map of one driver may be additionally or alternatively integrated with an interactive map of another driver, such as a partner driver. By combining the service areas of the driver and the driver partner, the computing system 100 can potentially generate and display to the dispatcher an area in which the driver and driver partners of the driver can provide services. In addition to personal location restrictions, the driver can pre-set personal time restrictions associated with his / her work shift. Computing system 100 may group postal codes within a district or county, administrative center, city, or state in map data in database 108. After computing system 100 identifies postal codes or other location restriction information, it may skip a driver with appropriate location constraints when creating the dispatch matrix 322 and dispatch output 330 such that no service request that includes areas within that driver's constraints is sent to that driver. One skilled in the art will understand that the list of driver service restrictions described herein is not exclusive and that the driver may have other restrictions related to his / her service.

[0156] Location restrictions can greatly affect where a driver ultimately provides services. It is understood that exemplary embodiments of the present invention provide an efficient dispatch system using various defined areas for scheduling service requests. The computing system 100 can identify which service requests will be executed, where, especially the starting and ending locations, depending on the time they are scheduled for, and can group them by region. In current industry practice, dispatch service is performed in an almost random manner. In a large city like New York, the driver can be sent at random times to random locations. By grouping service requests by geographic region and tracking drivers, dispatchers can more efficiently plan ahead for service requests, and drivers can complete service requests in less time.

[0157] Referring now to FIG. 5 shows a typical workflow for price negotiation between a service provider (eg, a driver) and a customer. In this exemplary embodiment of the present invention, the customer may submit his bid for a service request to the system (step 501). The customer's suggested price can be based on the default price, and one or more processors can determine when the offered price is higher, lower, or equal to the default price. The default price for transport services may differ from the price of the delivery service. When a customer requests a combination of services, the default price can be derived from the default price for each of the transport service and the delivery service.

[0158] For simplicity, FIG. 5 only describes the scenario in which the client bids for the transport service. The system asks the customer as to who the customer would like to send the bid to, depending on whether the customer has any select service providers (or whether there are any select service providers available) (Resolution 502). If there are available select service providers, then the customer can decide if he / she wants to submit a quote to one or more of these available select service providers (Solution 503). If the client wishes to send a quote to any of these selected service providers, he / she additionally decides whether his / her proposed price will be negotiable or not negotiable with the selected service providers (Resolution 504). If there are no Featured Service Providers, there are no Featured Service Providers available, or if the client does not want to send his / her Bid to any of the Select Service Providers, then the Client can decide whether his / her Bid Price is negotiable or not negotiable with any preferred or common service provider (s) (Resolution 505). Once it has been established whether a customer will negotiate with one or more service providers or not, the process is the same regardless of whether the service provider is a chosen service provider or a regular service provider.

[0159] When the customer sets a price that he / she considers to be negotiable, the service providers will be notified (block 506). In this case, the service provider decides to negotiate (Decision 507). The service provider has three options, depending on the contractual price offer. If the service provider does not want to accept the service request at all, he / she rejects both the negotiation and the request, and the request expires (step 508). If the service provider does not want to negotiate, but still wants to fulfill the service request, he / she accepts the original contract price as it is (step 513) and is then directed to fulfill the request (step 514). The third option available to the service provider is to negotiate a price. The service provider calculates the counter price (step 509) and sends it to the customer. The customer can then choose whether he / she accepts the counter price (Decision 510). If the customer accepts the counter price, the system directs the service provider (block 514). If the customer does not accept the counter price, then the customer proposes his counter price (step 511) and the agreement is returned to the service provider. The service provider is then left to decide whether to accept the counter price (Decision 512). If the service provider accepts the counter price, then the service provider is directed to fulfill the request (block 514). If the service provider does not accept the counter price, then he / she bills the client with the counter price (step 509). The process is repeated until both the service provider and the customer agree on a price, after which the service provider is directed to fulfill the request (block 514).

[0160] When a customer sets a price that he / she considers non-negotiable, the request is forwarded to the customer's select service providers (or any other service providers if the customer does not have available service providers on his / her favorites list) who either accept or do not accept a non-negotiable price (Decision 515). If the service provider accepts the non-negotiable price, then he / she is directed to fulfill the request (block 514). If the service provider does not accept the request, then the client is notified that the service request was not accepted at the price he / she was offering (block 516). The customer may then, upon notification, revise the original service request and resubmit a new quote (block 501).

[0161] A person skilled in the art will understand that in FIG. 5 depicts only one of many possible scenarios for price negotiation between the service provider and the client, and that the system can receive an initial price offer from either the service provider or the client. Accordingly, the initial quote may be rejected by both the client and the service provider. In addition, one skilled in the art will understand that the process described herein is not exclusive and does not require the particular order shown to achieve the desired results.

[0162] Now referring to FIG. 6, shown is a flow diagram illustrating an exemplary methodology for scheduling a packet (ie, a plurality) of unassigned service requests in advance. A plurality of service requests can be received by the computing system 100 (e.g., loaded by customers / passengers and / or a third party provider such as an insurance company on behalf of their customers who will need transportation services) and assigned corresponding identification numbers (Identifiers) (block 600). Such downloads may be performed by a client using one or more client computing devices 130C1 ... 130Cn, performed electronically by a client or a third-party vendor using a vendor's device 126 via a web interface, and / or manually by a dispatcher using a dispatching device 136 after receiving a request ( service requests and related schedules by phone, text message, email, or paper copy. Alternatively, the system can use interactive voice recognition (IVR) and / or voice-to-text technology to automatically receive service requests through traditional telephone systems.

[0163] If necessary, each service request 300 is split into route sections corresponding to each part of the trip (eg, pickup location (s), drop-off location (s), etc.) (block 620). A service request may consist of boarding at Location A and disembarking at Location B, and later boarding at Location B and disembarking at Location A. / or different pick-up and drop-off locations, and may last longer than a day. For example, a service request 300 may include a customer's home (location A), a hospital (location B), and a place of work (location C), and have three route legs, A to B, B to C, and C to A. Three sections of the route will run in chronological order, but with different periods of time between them. The service request, its route legs and all associated information, including postal codes corresponding to the pickup and dropoff locations at each segment, and any embarkation and / or disembarkation times required, may be stored in database 108.

[0164] The dispatcher can use the dispatcher 136 to indicate a specific geographic region (for example, one of the five boroughs of New York) and a specific date (for example, the same day, the next day, several days from a given day, a week from a given day, etc.) etc.) where he / she desires to assign drivers for unassigned service requests on computing system 100 (block 610). Alternatively, computer system 100 can be pre-configured to automatically batch and schedule service requests for a predetermined number of days prior to an ordered service date. For example, computer system 100 may be pre-configured to perform a August 17 batch assignment process for service requests scheduled for August 18. The dispatcher can view, via an interface on the dispatching device 136, a list of received unassigned service requests in the computing system 100 in chronological or other order by their respective service request dates. The dispatcher or computer system 100 may simply start at the earliest date in the future for which unassigned service requests remain on the computer system 100. Computing system 100 may also be configured to automatically select a specific date (e.g., the earliest date for which any unassigned service requests remain in the system) and a first geographic region for scheduling (e.g., Manhattan, Queens, etc.) to this date.

[0165] Upon receiving a specific date and a specific geographic region, computing system 100 retrieves a packet of unassigned service requests from a stored set of loaded unassigned service requests (block 630). The retrieved unassigned service request packet preferably has route legs with embarkation and disembarkation locations that fall within a specific specified geographic region (or at least one of the corresponding embarkation and disembarkation locations that fall within a specific specified geographic region) and have an ordered embarkation time and / or disembark on a specific date (specified date) (block 620). Computing system 100 may also retrieve customer-specific information corresponding to a plurality of customers associated with a batch of unassigned service requests and driver data sets corresponding to a potential set of drivers to be assigned to a package, depending on a particular geographic region and specified date. Customer information may include customer identification number or name, service preferences, favorites, favorites, and blacklists. Driver data sets may include driver information containing one or more service restrictions, service history, favorites, blacklist, and historical data.

[0166] Computing system 100 may identify the readiness and compatibility of a potential driver set for unassigned service requests from a given package (block 640) and assign drivers to execute a plurality of unassigned service requests from a given package (block 650). It is understood that the system may execute steps 640 and 650 prior to receiving the departure date, whereby drivers are pre-assigned for service requests and dynamically updated using an algorithm (step 650) until a specific departure date is received from the dispatcher, at which point the system prints out the proposed schedule for the specified departure date. As shown, computing system 100 cycles between determining available and compatible drivers and assigning drivers, as each assignment can likely change the availability of a particular driver with respect to the next pre-scheduled service request (blocks 640, 650). Driver availability can be assessed based on preset driver restrictions and the expected location of the driver at the time of boarding an unassigned service request (for example, the driver may already be assigned to an earlier leg of the service request route stored in database 108) and the location and time disembarkations will make it feasible / impracticable for the driver to provide service for an unassigned service request.

[0167] For example, if the last leg of the previous assigned service request has a request to disembark at location X ₁ at approximately time T ₁ , and the first leg of the route as requested involves landing at location X ₂ at approximately time T ₂ , then if the locations X ₁ and X ₂ are relatively close to each other (for example, within the same zip code), and times T ₁ and T _{2 are} relatively close in time, so the driver will have time to get from X ₁ at time T ₁ at X ₂ at time T ₂ (eg, depending on the estimated travel time using stored traffic and mapping data 326), the computing system 100 may consider this driver available with respect to an unassigned service request. Likewise, after considering customer and driver preferences / constraints, computing system 100 can efficiently assign service requests to drivers.

[0168] The compatibility of a potential driver set for unassigned service requests from a given package is assessed according to one or more algorithms or criteria based, for example, on blacklists, favorites, or preferred customer lists as discussed herein. In preferred embodiments of the invention, the available drivers in the customer's favorites list have the highest priority, followed by the available drivers in the customer's favorites list. Available drivers on the customer blacklist are not assigned for this customer service request. All available drivers in the client's favorites list and, if necessary, in the favorites list, can be viewed and accounted for by the computing system 100 for possible assignment.

[0169] Computing system 100 assigns drivers in accordance with a predetermined algorithm (block 650). Computing system 100 can start with the first service request, check driver restrictions regarding locations, times, conflicts, blacklists, trip conflicts, and so on. and exclude any drivers who are unable to service an unassigned service request due to unavailability, blacklisting, expected geographic location at the time of boarding, expected lunch breaks or stops, or any other reason. The computing system 100 can then check to determine if any non-excluded drivers (eg, that should be available and close enough to the pickup location for the pickup time and date) are on the customer's favorite list or the customer's preference list. If this is the case, then such a driver can be assigned a high priority.

[0170] Optionally, the same driver can be assigned to all legs of the service request route at 650 using compatibility as a leading criterion for maximum customer satisfaction. However, it should be understood that the second leg of the route (eg, the reverse leg) of the service request could potentially be served by a different driver than the one assigned to the first leg. Alternatively, the computing system 100 may assign the first driver to the second leg of the first service request while maintaining the status of the first driver for several hours between the two legs as "available" and subsequently assign the first driver to another leg of another service request. for which the first driver is compatible and consistent as computing system 100 processes service requests from a given package during this emerging available time period. Computing system 100 may be configured to book one or more drivers for various stages of a service request, as well as taking into account the preferences and constraints of the client and driver.

[0171] It is understood that the total time during a shift when the driver is carrying a passenger minimizes the waiting time for the driver, and the amount of work planned in advance in the automatic mode can be increased. It should also be understood that dispatch service and driver workflow can be dynamically updated as situations arise due to cancellations, delays, or other issues. Since service requests are received, grouped, and sent ahead of time, drivers' work schedules will be filled in advance, and computing system 100 can maximize efficiency by dynamically updating the schedule as driver availability changes (e.g., when drivers take sick leave, change opening hours, etc.) while meeting the needs of customers and drivers.

[0172] Computing system 100 may be configured to store any remaining service requests from a given package that are not assigned to a driver, in accordance with the algorithms / criteria used in block 650, in a work proposal pool (block 660) that has access multiple available drivers via remote driver computing devices 132D1 ... 132Dn so that drivers can select at least one of the remaining unassigned service requests. Computing system 100 can limit the number of unassigned service requests in the job offer pool that a single driver can select.

[0173] As illustrated in FIG. 10, unassigned service requests for the job offer may be displayed on an interactive electronic map display 1000 accessible to drivers via driver devices 132D1 ... 132Dn. The e-map display 1000 can display different geographic regions, as indicated by six sections (i.e., I, II, III, IV, V, and VI), corresponding, for example, to the plurality of local geographic regions where the pick-up and drop-off locations of unassigned service requests are located. ... Unassigned service requests can be displayed as interactive indicators 1010. While asterisks are displayed, it should be understood that any type of shape, icon, symbol, or image can be used, and that more than one type of indicator can be used to refer to different objects or features. Drivers may select (eg, “click”) through the appropriate one of the driver devices 132D1 ... 132Dn one of a plurality of sections I-VI and / or select one or more interactive indicators 1010 to request a destination area, or select a corresponding unassigned service request. The driver can also indicate his / her initial limits or other presets for service using such a 1000 card display. For example, a driver can designate in computing system 100 as a default setting, or for one or more days, a preferred work area by selecting one of six sections I-VI. The default driver's preferred work zone can be set to the zone corresponding to the driver's home address.

[0174] Referring again to FIG. 6, once a sufficient number of service requests have been assigned to a particular driver and he / she has the minimum availability remaining at the specified date, the computing system 100 may send a review of the driver's planned trips for review and approval (block 670). The driver can accept or reject each service request in the schedule. Although such notification and approval by the driver may be made, for example, several days or even weeks before the specified date when the services are to be rendered according to the service requests, such notification may be provided immediately before or even at the beginning of the scheduled date.

[0175] The customer can also add the driver to his favorites, preference or blacklist at any time, and the driver can similarly add the customer to the blacklist or driver's favorites list (provided that if the request is to add to favorites, the customer confirms the request). Such additions may occur, for example, after the completion of a pre-planned service request from a given package. Users can view datasets of previous drivers and customers, and send requests to be on each other's favorites. A search function can be provided to search for customer and driver accounts. Adding a client to the driver blacklist or adding a driver to the client's blacklist may or may not occur with mutual notification or approval. It is clear that such one-way authorization for blacklists without notifying the other party will help avoid confrontation or awkwardness between customers and drivers. A driver can add a partner driver at any time as long as both drivers approve the addition.

[0176] When a driver rejects (or cancels) a pre-planned service request (block 670), computing system 100 may be configured to invoke a micro-dispatch system and / or process, with the canceled driver sending a canceled pre-scheduled service request driver-partner. If such a partner driver is available and accepts the request, then the computing system 100 can designate a partner driver, provided that the partner driver is not on the customer's blacklist, or vice versa. Such partner drivers can also be used if, for example, the driver accepts a service request but cannot fulfill it in time due to the pickup location. The driver may send a portion of the route of the service request to his partner driver, provided that the computing system 100 allows this, depending on the compatibility of the partner driver with the client. Each driver can have several partner drivers in the system and the dispatch service process at the micro level. A driver may be given the option to forward a pre-scheduled service request that he / she is canceling to another non-partner driver, and the computing system 100 can assign the canceled pre-scheduled request to another driver if the other driver accepts the request, is available and deemed compliant. by the client (for example, not on the client's blacklist).

[0177] If the driver rejects any pre-scheduled assignments (block 670), then computing system 100 can switch both the driver's status during the canceled time period and the service request status from “assigned” to “unassigned”, identify and assign an alternative driver to fulfill the service request using the same criteria / algorithms discussed above (block 680). The pre-planned driver assignments stored in the database 108 can be dynamically updated and the drivers are reassigned (block 680). If the driver denies a particular service request in his schedule, then computing system 100 may add the denied service request to the job offer pool (block 660), or may automatically reassign the service request to the partner driver if such a partner driver is available. The pool of job offers can be dynamically updated continuously as drivers approve or reject the schedule of service requests sent to them, in whole or in part. Such updates can be stored in the database 108.

[0178] In certain embodiments of the invention, computing system 100 may be configured such that if a driver rejects any pre-planned service requests or portions of the route, that driver may lose priority. It will be appreciated that, depending on customer preferences and driving restrictions, computing system 100 can quickly identify compatible drivers for an unassigned service request. For example, an unrestricted driver and a client without preference can be identified as compatible and therefore matched. Alternatively, if any settings (eg, driver restrictions, customer preferences, etc.) conflict with each other, then the driver and customer may be considered incompatible and cannot be matched. It should also be understood that full disclosure in relation to details of service requests, driver restrictions and customer preferences will improve the experience of both customers and drivers.

[0179] Now referring to FIG. 7A-7B, shown is a flow diagram illustrating a first exemplary algorithm for assigning a plurality (or packet) of pre-scheduled service requests in accordance with an exemplary embodiment of the present invention. After computing system 100 has received a candidate set of drivers and a batch of unassigned service requests for a specified date and geographic location (eg, at block 630 shown in FIG. 6), the process of looping through the unassigned service requests in the batch and assigning drivers begins. as many of them as possible (block 700). It is preferable if the drivers in the potential set of drivers considered for batch service requests have a predetermined limit for the geographic region in which he / she will accept orders.

[0180] The first unassigned service request from this package is identified, as well as its corresponding client, as well as any pickup and / or drop-off locations and / or time requirements on the specified date (block 710). A potential set of drivers (initially obtained based on the specified date and geographic region specified by the dispatcher or system) is considered and any potential set of drivers that are on the client's blacklist is excluded, as well as anyone who added the client to his / her blacklist is excluded (block 712). It is then determined if any of the remaining potential driver set is available to service the unassigned service request (block 714). Availability can be assessed based on both the driver's pre-set restrictions and the intended location the driver will be in prior to the pickup time of the unassigned service request, as discussed earlier. For example, a driver who needs to travel from location X ₁ to location X ₂ in time T may do so based on historical traffic and mapping data 326 stored in database 108, but may have a predetermined limit on how far he / she is willing to travel between the different legs of the respective service requests. If a driver is considered unavailable, then his / her status is set to "unavailable" and he / she is excluded from the potential driver set for that particular non-assigned service request. If none of the drivers in the potential recruitment is considered available, then a service request is sent to the job offer pool 716 where it can be viewed and potentially selected by other available drivers as discussed in this document. The assignment process starts over again (block 700) and identifies a second unassigned service request from the packet, as well as new client, location and time information associated with the second service request (block 710).

[0181] If computing system 100 determines that drivers are available (block 714), it is determined if any of the available drivers are on the particular client's favorites list (block 716). It is then determined whether only one selected driver or a plurality of selected drivers is available (block 718). If only one select driver is available, then the only select driver is assigned to an unassigned service request (block 720). The next unassigned service request is processed (block 710). If the driver, while fulfilling the previously assigned service request, receives a second service request assignment, the driver may accept the second service request, depending on the preference of the customer. For example, a driver who has predetermined the location of the return home point may decide to wait for the second service request, since the drop off location and time of the drop off of that service request are compatible with the location and time of the driver return to the home point. Preferably, the computing system 100 can be configured to avoid empty sections of the route, if possible, and be able to designate a driver whose predetermined location and time of return to the starting point are coordinated with the client's request for service, is beneficial to the driver because he / she can profit from a portion of the service request route that might otherwise be empty.

[0182] If a plurality of favorite drivers are available, then the computing system 100 may look at the plurality of favorite drivers (block 722) to determine which one is most experienced (for example, with this client, in terms of the total number of previously completed service requests for this client, etc.) (block 724), as indicated in the historical data obtained at block 630. It is understood that such historical data and other data stored in the database 108 may be obtained at various stages of the process described in this document. The most experienced selected driver is assigned to an unassigned service request (block 726).

[0183] If the set of the most experienced selected drivers is determined (block 724), then the computing system 100 can determine which of these drivers will be the nearest, depending on the shortest estimated time period that it takes to get from the proposed location to the specified the date at the time of landing to the specified landing location of the unassigned service request (eg, as discussed in the above example with respect to locations X ₁ , X ₂ and times T ₁ and T ₂ ). The closest experienced select driver is then assigned to the unassigned service request. Once the driver has been assigned to the request (block 726), the next unassigned service request is processed (block 710).

[0184] If none of the remaining potential driver set is in the client's favorites list, then it is determined if any of the remaining candidate driver set is in the client's list of favorites (block 732). If only one preferred driver is available (block 734), then that single preferred driver is assigned to an unassigned service request (block 736). If multiple preferred drivers are available (block 738), then computing system 100 may determine the most compatible or most experienced preferred driver and select him / her based on the number of matches between predetermined customer preferences and various attributes or constraints of the driver and his / her transportation. means (block 740). This most compatible or most experienced preferred driver can be assigned to an unassigned service request (block 742). Historical data can be used to determine which of these preferred drivers is the most experienced for the customer, based on the total number of service requests previously made for the customer.

[0185] A feature mapping between specified customer preferences and specified driver preferences / constraints may include, for example, vehicle type, vehicle size, color, make, model, year, two-door, four-door, nationality, quantity years of driving, type of vehicle, make and model of vehicle, number of vehicle seats, vehicle capacity, vehicle carrying capacity, readiness to transport a wheelchair, availability of a child seat, ability to accommodate pets, driver's language ability, driver's gender, driving experience the driver's familiarity with the route, the driver's experience with certain types of goods or experience with fragile goods or goods requiring other special packaging or delivery methods, or any other characteristic or preference. The number of comparisons of these signatures can serve as a basis for assigning a preferred driver to an unassigned service request, more than the number of previous trips that the preferred driver has made for the customer. It should also be understood that the criteria or algorithm used to select one of the many available preferred drivers may use a combination of these concepts. For example, the preferred driver with the most preferences matches the customer may be prioritized, then the one with the most previous rides in the customer's best interest, and then if two or more preferred drivers are considered equally compatible based on those criteria, it may be the one that is estimated to be the closest based on location and time is assigned.

[0186] If none of the favorite or preferred drivers is available, an unassigned service request may be assigned to a driver classified as a regular driver (block 744). Computing system 100 first judges whether only one driver is available or multiple drivers are available (block 746). If only one regular driver is available (block 746), then that single regular driver is assigned to an unassigned service request (block 748). If multiple regular drivers are available (block 746), then computing system 100 may browse the available regular drivers (block 750) and determine the most compatible or most experienced regular driver (block 752) and select him / her based on the number of matches between predetermined preferences. customer and various characteristics or limitations of the driver and his / her vehicle. This most compatible or most experienced regular driver can be assigned to an unassigned service request (block 754). Historical data can be used to determine which of these common drivers is the most experienced for a customer, based on the total number of service requests previously made for the customer or within a specific area. It is understood that one of the predefined driver restrictions (or customer preferences) may prevent the driver from being assigned to a specific service request at any stage. If for any reason there are no regular drivers available (block 744), then computing system 100 may place the unassigned service request into the job offer pool (block 716).

[0187] If two or more of the remaining plurality of regular drivers previously performed an equal number of service requests for a client, then the computing system 100 can determine the closest driver, depending on which of the regular drivers has the shortest estimated time to get from his / its intended location to the landing location of this service request. Computer system 100 can then designate the closest and most experienced regular driver for the unassigned service request (block 754). Once the driver has been assigned to the request (block 748 or 754), the next unassigned service request is processed (block 710).

[0188] In preferred embodiments of the invention, the client pre-sets its favorite and preferred drivers and a specific ranking for each preferred driver and each preferred driver if the client has multiple favorite drivers and / or multiple preferred drivers. Drivers can similarly assign specific ratings to select or preferred customers. For example, if a customer has four favorite drivers in his / her favorites list, he / she can preset the ranks 1, 2, 3 and 4 corresponding to each of his / her four favorite drivers. The client can also preset two or more drivers with the same rating in the favorites or with the same rating in the preferred ones. It is clear that in this way a number of ranking scenarios are possible. In the first scenario, the classifications (favorites, preferred) are set without any ranking among the classified favorites and preferred drivers / customers. In the second scenario, driver / customer classifications and ratings are predefined. In the third scenario, the classification and ranking of both driver / customer categories are predetermined and two or more drivers / customers within the classification receive the same ranking. In the fourth scenario, the customer assigns classifications and ratings to drivers, but only one or more drivers assign classifications to customers without ranking, and so on. If more than one preferred or preferred driver with the same rating is available, then the system may randomly assign a service request to one of those drivers with the same rating, or use additional criteria, as described in various embodiments herein, such as the number of previous service requests made for the customer, the level of familiarity with the itinerary, etc. Thus, the system can be configured to first view the available favorite drivers of a customer when assigning a service request, and then assign by rank the favorite driver (if the system identifies multiple favorite drivers), regardless of which of the favorite drivers is the most experienced or closest. ... If there are no favorite drivers available, the system can similarly rank the preferred driver. In this way, the client leaves no doubt about the hierarchy of driver assignments he / she desires.

[0189] The system may also be configured to take into account driver classification and customer ranking in driver favorites or preferred customer lists when making assignments. In other words, customer driver ranking and customer driver ranking can be used as part of the match criteria when matching drivers to customer service requests. However, since drivers generally require as much business as possible, it should be understood that in preferred embodiments of the invention, customer preferences will take precedence. The system can use all the preset information when assigning customer service requests to drivers. All preset data can be transmitted through one or more web portals or computing devices (eg 130 _C1 -130 _Cn , 132 _D1 -132 _Dn ). Alternatively or additionally, the default settings can be used if the settings are not made by the customer or driver.

[0190] The client can further pre-set whether he / she wants to allow the assignment of partner drivers to his / her service request (s) if specific selected or preferred drivers are not available or made a cancellation on a specified departure date. Partner drivers are discussed further below with reference to FIG. 9. If the customer does not want any partner drivers to process his / her requests and pre-configure this in the system, then the system can switch between Favorite and Preferred drivers using ranking as a priority and / or using the algorithms discussed in herein with reference to FIG. 7A-9. If a customer wants a partner driver to handle his / her service requests in the event that a designated pre-planned driver (e.g., a featured or preferred) cancels the request or becomes unavailable, then the system can designate a partner driver, provided that the partner driver is not excluded from being assigned to a client because he is on the client's blacklist or fails to comply with any other requirement of the client's request or service preference. The hierarchy by which partner drivers can be entered into the assignments of pre-planned service requests (for example, whether the system should contact the next highest rated featured driver or the partner driver of a selected driver of a certain ranking) can be predetermined by each customer. If the client has not predefined certain criteria, the default settings for such algorithms can be used. Thus, the partner driver methodologies described herein may not only be used in pre-scheduling embodiments where a driver assigned in advance scheduling cancels a request, denies a request, or becomes unavailable to fulfill a service request, or when a customer changes a service request, as discussed with reference to FIG. 9, but also in the initial planning in advance of one service request or multiple service requests in a given package.

[0191] When more than two or more drivers cooperate with each other, as described herein, such a grouping creates a micro-level dispatch system that reduces or eliminates the traditional manual dispatch service. This micro-level dispatch system dynamically connects and updates the overall dispatch system 100 via computing devices (e.g., driver devices 132 and dispatcher device 136) via server 102 and network 124. When service requests are passed between partner drivers, still apply all preferences and limitations of customers and drivers, however, when service requests cannot be transferred between driver partners, service requests can be directed to the fund of job offers or processed in accordance with any other methodology described in this document.

[0192] Referring to FIG. 8, a flowchart is shown that depicts a second algorithm for assigning a plurality of pre-scheduled service requests in accordance with various exemplary embodiments of the present invention. As illustrated, an algorithm that prioritizes the matching of customer preferences and driver restrictions before the customer's favorites and preferences can be used. Once a potential set of drivers and a batch of unassigned service requests for a specified date and geographic location have been found (see FIG. 6, step 630), computing system 100 is ready to start cycling the unassigned service requests in the batch to as much as possible. assign drivers to a number of them. It is understood that, as an alternative to the chosen and preferred classifications, weighted ranking values can be assigned on their own, in addition to the other compatibility criteria used, for example, instead of first considering classification and rank and then other signatures of compatibility, in some variations In the embodiment of the invention, the system may be preset to give the compatibility classifications a weighted value in calculating the compatibility criteria in order to determine the best suitable drivers.

[0193] Computing system 100 identifies the first unassigned service request from the given packet, including any customer-related information, any pickup / drop-off locations and times, and so on. (block 810). The first candidate set of drivers is checked against the set date and geographic region specified in the driver restrictions, so that some drivers may be excluded for being blacklisted by a client or for adding a client to their blacklist (block 812). Next, it is checked if any of the remaining potential driver set (eg, depending on time, location, etc. (see FIGS. 7A-7B)) is available to serve an unassigned service request (block 814). If a driver is deemed unavailable, his / her status can be set to “unavailable” and he / she will be excluded from the first potential driver recruitment for that particular service request. If none of the drivers in the first candidate set is considered available, then the service request can be submitted to the job offer pool (block 816), where it can be viewed and selected by other available drivers. The second service request from this package is then identified, along with the new customer, location and time information associated with the second service request, and the process continues until all service requests from this package have been assigned and any unassigned requests are sent to the job offer fund.

[0194] If it is determined that potential drivers are available, then computing system 100 may query whether such drivers can also be assigned (block 815) (eg, whether any customer preferences or driver restrictions preclude the assignment of a given service request to such drivers) ... If it is determined that at least one driver can be assigned, computing system 100 asks if there is only one or a plurality of available and those that can be assigned (block 818). If only one driver is available and is one that can be assigned, then that driver is assigned for the service request (block 820). The next unassigned service request has been identified for processing.

[0195] If more than one driver is determined that are available and can be assigned, then computing system 100 may determine the compatibility factor for each such driver, depending on the comparison of the characteristic with the preferences of the client (block 822). In some embodiments, such compatibility factors may take precedence over whether any drivers are on the client's favorites or preferences. Depending on the information regarding the customer and the dataset information regarding the driver, the system 100 may exclude one or more drivers that are deemed insufficiently compatible with the customer due to one or more aspects of a given service request, customer preference and / or driver restrictions. The client may prioritize such aspects or compatibility factors in the order in which the client wishes to prioritize. A processing function may be used in which different variables / features related to such preferences, constraints and / or service request requirements are assigned different priorities and processed. Such compatibility criteria may be used in accordance with the embodiments of the invention contemplated in relation to any of the embodiments described in US patent application Ser. No. 15 / 239,783, entitled "Method and System for Customizable On Demand Services." ("The '783 application"), the contents of which are incorporated herein in their entirety by reference.

[0196] Computing system 100 determines if the most compatible driver exists (eg, the driver with the highest compatibility factor (block 824) and assigns a service request to the most compatible driver that can be assigned (block 826). Then a new service request is identified for processing (block 810). If it is determined that multiple compatible drivers have the highest compatibility rates equal or substantially equal, then the computing system 100 can estimate which of these drivers will be the closest to the pickup location from the given service request, depending on location and time (block 828). Computer system 100 then assigns the service request to the closest of the plurality of remaining compatible drivers with the highest compatibility rates (block 830), and the next unassigned service request is identified for processing (block 810).

[0197] Now referring to FIG. 9, shown is a flow diagram illustrating an exemplary methodology for planning in advance and rescheduling a plurality of service requests from a received packet using driver-partner methodology and on-demand methodology in accordance with various embodiments of the present invention. Computing system 100 may pre-schedule a batch of service requests (block 900), for example, August 15, 2017, for a specific specified date, for example, August 18, 2017, with drivers using one of the algorithms or criteria discussed in this document ( for example, the algorithms shown and discussed in relation to Figures 7A, 7B and 8). In this example, between August 15, 2017 and August 17, 2017, computing system 100 will preferably dynamically update and complete driver assignments for the package because drivers accept / deny their assigned service requests and computing system 100 reassigns service requests to match with various embodiments of the invention discussed herein (block 902). Then, on the specified departure date (for example, August 18, 2017) _{, a notification is received from the customer matching the specific service request, X C} , from this package, indicating that the customer needs to change the boarding time of this service request from 2:00 pm to 5:00 pm (block 904). It is understood that, alternatively, the customer may want other changes such as, for example, the pickup location or any other characteristic of a given service request or associated customer preferences.

[0198] Upon receipt of the ordered change (s) from the client, the computing system 100 notifies the pre-scheduled driver for a service request, X _C (block 906). The client may be able to directly communicate with the designated driver to request a change (s). Such communication can occur, for example, directly from the corresponding client device 130C1 ... 130Cn to the driver device 132D1 ... 132Dn, the vendor device 126, the administrator device 134, the dispatcher device 136, or some combination thereof. The designated driver is prompted to indicate whether he / she accepts (change) changes to the service request (block 908). It is understood that accepting a change in a service request may conflict with others of the designated driver's service requests, and that computing system 100 can be configured so that the designated driver can accept the change, regardless of how the change affects subsequent service requests. , or may be configured to prevent the driver from accepting the changes and reassign a new driver for a service request, such as a partner driver. Alternatively, the driver may be allowed to accept the change if it is expected to cause only some disruption in subsequent service requests. If the designated driver accepts the change (block 908), then the computing system 100 stores the same designated driver assigned for the service request (block 910).

[0199] If the designated driver does not accept the change (block 908), then computing system 100 may identify if the designated driver has any partner drivers (block 912). If so, the computing system 100 can determine if any of the partner drivers are available to fulfill the service request X _C based on their current location or their intended location, any potential conflicts such as blacklists, etc. or any conflicts between their constraints and client preferences that preclude an assignment (block 914). In the event that one or more partner drivers are available, computing system 100 sends a request to the most compatible or closest partner driver that is available (block 916). Proximity can be determined based on estimates of location and time using both historical data and up-to-date traffic and mapping data 326. Compatibility may be set based on favorites, preference lists, or match criteria for customer preferences and driver restrictions as discussed in this document. The partner driver responds by confirming or rejecting the request (block 918). If the request is accepted, the computing system 100 reassigns the service request X _C to the partner driver (block 920). If rejected, computer system 100 may automatically switch the status of the partner driver (block 922) from "available" to "unavailable" and again check for any other available driver partners (block 914).

[0200] When there are no partner drivers available (blocks 912, 914), computing system 100 may identify at least one best matching available driver (block 924) using client preferences, driver restrictions, and other matching criteria. As the boarding time for a pre-scheduled service request approaches, if problems arise (eg, a driver cancellation at the last minute or a customer change, or a service request remains unassigned), computing system 100 can operate in accordance with various embodiments of the invention. " on Demand "illustrated and described in the '783 application.

[0201] The best appropriate available drivers can be determined based on the correspondence between customer preferences and driver restrictions, as well as the willingness of drivers based on location, time and preset restrictions, if any. Computing system 100 can automatically and periodically track geographic locations that change over time, such as client devices 130C1 ... 130Cn and driver devices 132D1 ... 132Dn, and in combination with traffic and mapping data 326 and driver location data 324 can identify drivers, that may be available to fulfill a service request. The geographic location of client devices 130C1 ... 130Cn, driver devices 132D1 ... 132Dn, fund 716/816 job offers, display 1000 of the electronic map can be dynamically updated in the database 108 to indicate changes in the initial settings of the client and driver, settings, preferences, restrictions, reverse links or other information to provide quality services. During this on-demand process of identifying at least one best matching available driver, the service provider (eg, driver) and the customer can be matched appropriately depending on the matrix of customer preferences and driver constraints so that appointments can be efficiently provided to customers. at the last minute, while continuing to satisfy the client's personal preferences. By taking into account both customer preferences and driver constraints, a more tailored application experience can be offered that takes both parties into account when planning services in advance and providing on-demand services.

[0202] Feedback can include positive, neutral, or negative feedback. Positive and negative reviews can be provided in the form of predetermined positive / negative reasons, respectively, depending on the assessment of the work of the performer. The rating can be provided either by the client or by the best suited service provider, who can optionally choose to add the relevant party to the favorites list or to the blacklist. Neutral feedback or lack of feedback may not affect the alignment between customers and service provider when assigning future service requests. Service providers and customers can mutually be in each other's lists of favorites or in black lists, but they cannot be simultaneously in the black list and in the list of favorites. The client can add one or more objects to his blacklist, and all service providers associated with such objects can also be added to the blacklist.

[0203] Alternatively, negative feedback can be provided for predetermined negative reasons to anonymously rate the customer by blacklisting the service provider. Negative reasons may include dishonesty, absence from work, overly loud behavior, verbal or physical abuse, refusal to pay, or other similar reasons. Likewise, negative feedback can be provided to anonymously evaluate the service provider by blacklisting the client's second service provider. In this case, negative reasons may include rudeness, verbal or physical abuse, a dirty vehicle, poor driving skills, lack of familiarity with street conditions, failure to follow customer instructions, improper handling of goods, breakdown or loss of goods, late delivery, or the like. causes. Notice may be provided to the client and service provider at a specified time after any negative feedback has been submitted to inform them that they have received negative feedback and / or why. Based on negative feedback, the client and / or service provider may be temporarily suspended from service.

[0204] Once identified, the computing system 100 may show the client a group of best matching drivers (e.g., Driver 1, Driver 2, Driver 3, Driver 4, etc.) with details of each driver expressed in terms of indicators (block 926 ). Such details may include distance or time from the customer, route information, route familiarity, etc. Indicator sets can also be used to make it easier for the customer to select a driver from a suggested group of the best suitable drivers for his / her service request, in a convenient and efficient manner. A client selection is received that identifies one of the best matching drivers (block 928), which is then notified (block 930). The best selected appropriate driver is asked if he / she would like to accept the service request (block 932). If the selected driver does not accept the service request, then computing system 100 identifies the other best matching available driver (block 924) using customer preferences, driver restrictions, and other matching criteria. If the selected driver receives the service request, computing system 100 reassigns the service request X _{C to the} selected driver (block 934).

[0205] It is understood that, in some preferred embodiments, the concepts presented herein may be used in various combinations as required to tailor pre-planned customer and driver services to one pre-scheduled service request for one customer, for multiple service requests for one customer, or for multiple service requests for multiple customers, directed to one or more drivers prior to a specified departure date or on a specified departure date, and that different matching algorithms may be used. It should also be understood that the advance scheduling techniques described herein can be used in conjunction with on-demand scheduling methods, and that the system can switch between advance scheduling and on-demand scheduling, or vice versa, as appropriate. For example, a customer can enter one service request into the system for planning ahead of time and receive a list of best matching drivers with a set of indicators that match each best matching driver, depending on the specific information about each driver that the customer is interested in viewing (e.g. indicators, representing characteristic features of driver compatibility, level of familiarity or experience with a particular route, etc.), and select one or more of these best-suited drivers to fulfill the service request. Alternatively, the customer can be notified at the last minute by the pre-scheduled driver of the cancellation and given the opportunity to select from a list of the most appropriate drivers. Likewise, the system can switch from on-demand planning to advance planning if, for example, a customer who has selected a driver for on-demand services suddenly learns that his / her doctor is late and that he / she is now you must cancel your On Demand Service request and board instead a few hours later or on a different day.

[0206] It is understood that the more information about customers and drivers is predefined in the system, the better the system can adapt to the specific needs of the assignment, reduce or eliminate manual dispatching support (for example, provide automatic, tailored dispatch service) and provide all users of the system with more complete information and capabilities. The customer may optionally pre-set one or more aspects of the compatibility criteria used to designate a driver for his / her service request (s), or may simply not set any criteria at all other than the conditions of the service request itself (e.g. pick-up time, time disembarkation, day and location).

[0207] It should also be understood that partner drivers may or may not have preferred geographic regions in the same regions as the drivers from which they are requested or sent requests, since the partner driver system is designed to minimize dispatch service. For example, if a driver cancels a service request, he can click a button and see the status of his partner drivers and their respective locations at that time, send a recommendation or notification to one of these driver partners. Then the partner driver can accept the request if the system allows it (for example, if the system determines that the partner driver and the customer of this service request are not blacklisted or blacklisted by each other, or are excluded due to some other specified criteria or reasons). This functionality can enable drivers to protect their businesses and keep their customers happy in the event they have to opt out at the last moment.

[0208] While “available” and “unavailable” have been discussed herein in relation to whether a driver is operating on a specific date and whether that driver will be able to reach a specific specified pickup location at a specified specified pickup time depending on (1) expected the location of that driver on that day and at this time, and (2) the expected time it takes for the driver to reach the landing location, taking into account traffic and map data, it will be understood that the system can be configured to be flexible in determining whether the driver is "approachable" as the driver may have the ability to make adjustments to fulfill the service request and may work with the customer to agree on slightly different pickup times or locations. This flexibility can be predefined by the client in the system (for example, it can be acceptable if the chosen driver can deliver the car to the client half an hour later than the ordered pick-up time).

[0209] In embodiments in which the system schedules a plurality of service requests in advance on a specified date, the preferences of each driver with respect to the geographic region (s) for getting the job and the time period (s) for getting the job are preferably set in advance along with any restrictions that the driver has in relation to a geographic location within the preferred geographic region (s), or restrictions on time periods within the driver's preferred time period (s). For example, if a driver pre-sets a specific geographic region (s) in the system (for example, by "clicking" and / or highlighting a specific geographic region of the map on the map interface), then he / she can receive many pre-planned service requests, each of which has a pick-up time and drop-off location within a given geographic region. If there are certain postal codes or locations within that geographic region that the driver does not want to serve, he / she can indicate such restrictions in the system by entering them manually or by "clicking" on the map display interface. If there are specific time periods during which the driver prefers to receive work within his / her predetermined geographic region, then the driver may similarly pre-set such specific preferred time periods in the system. If there are certain periods of time during which the driver does not wish to receive work during such a preferred period of time (for example, during his / her lunch break or during a personal meeting during the day), then the driver can also set such restrictions in the system in advance. period of time. In this way, the system can accurately and efficiently plan in advance a plurality of service requests. It will be understood that for single, pre-planned service requests, customer and driver preferences in terms of time and location are not required as there is great scheduling flexibility - drivers can be individually notified and / or selected by the customer. Thus, driver preferences for a geographic region and time may optionally be preset, but some embodiments of the invention require to be considered assigned to multiple requests on a specified date. When the system contains predefined data about which geographic regions each driver prefers, it can more efficiently assign multiple service requests since most service requests will fall within specific geographic regions specified by drivers (e.g. within Manhattan, Queens, Brooklyn, between 30th Street and 90th Street, etc.), as opposed to the designated geographic regions.

[0210] In some embodiments, the system may recommend or notify different drivers of service requests that have been sent or are already in the job offer pool 660, 716 when the system considers such drivers to be in good agreement based on predefined data and algorithms that the system is configured to execute. For example, the system may recommend a service request that is in a pool of job offers to a driver who is suddenly available and / or in a specific geographic region and / or meets customer eligibility criteria. The system can provide the driver with a predetermined time period for confirmation. If the driver does not accept the request, then the system can notify the other driver of an available service request, etc. In other embodiments of the invention, the system may notify available drivers of service requests directed to the job offer pool (either because the designated driver canceled the request or because the system was unable to schedule a service request in advance based on predetermined driver preferences. ), and enable such drivers to select a service request before it is placed in the job offer pool and / or to change their predefined preferences and restrictions. Drivers may be inclined to accept such a recommended service request because once it is placed in the job offer pool, a previously granted exclusive driver may lose the request if another driver chooses it. In some embodiments of the invention, the system may be configured to implement a more inclusive or less restrictive algorithm (e.g., eliminate one or more criteria or reduce their weighted value) for service requests in the job offer pool to identify potential drivers not previously identified with using a stricter algorithm. A more inclusive algorithm might be less restrictive about, for example, any accessibility presets. For example, drivers who are familiar with the geographic region can process a service request in less time than the system calculates and / or can communicate with the customer and negotiate different pick up times. This sharing of information can help resolve dispatch issues and allow more service requests to be removed from the job offer pool.

[0211] It is understood that new customers in the system, or existing customers who now want to receive services in a new geographic region, may not have a favorite or preferred driver in the new region (s). Thus, in certain embodiments of the invention, the system may recommend drivers to the customer, and vice versa, based, for example, on the driver's level of familiarity with a given route and / or on the number of service requests that a driver typically makes in a geographic area. As soon as customers and drivers change their presets, as well as during and after the completion of service requests, all data can be retrieved and analyzed from the database 108 and dynamically updated through the system.

[0212] In preferred embodiments, the database 108 may be dynamically updated with new driver location data 324, traffic and mapping data 326, job offer data 660, 716, data from map display 1000, and any custom the interfaces on client devices 130 _C1 -130 _Cn and driver devices 132 _D1 -132 _Dn can be dynamically updated in real time when service requests are started, completed, modified, selected, canceled, assigned, etc.

[0213] In some embodiments, the best fit driver steps discussed herein may additionally or alternatively be used to schedule a separate service request for a customer in advance in conjunction with, for example, the price negotiation steps discussed with respect to FIG. 5. The client can view a list of the best matching drivers with corresponding indicators showing a summary of information related to a particular driver and select one or more to negotiate a price.

[0214] It is understood that the sets of indicators described in this document can help the client assess supply and demand factors, which can be critical in setting prices for negotiations, as the client may offer lower prices during a lower level of demand or higher prices during a higher level of demand. The number of available service providers who can provide the service and the number of customers currently requesting a service in a particular region can be dynamically updated in the database 108. Any service provider that provides the same type of service as the type of service as requested by the client for service can be included in the pool of potential available service providers if the service provider is located in a geographic area and is available. The indicator sets displayed to the client can be turned on or off by the client through the client device 130. If the client has disabled the indicator set, he / she will not see it on his / her display. However, customer service requests may still be considered when the system investigates all available requests in the corresponding subcategory.

[0215] Different sets of indicators may be displayed to service providers (eg, drivers) through the driving device 132 and may be useful to drivers for setting a price for a service request, for example, depending on different types of customer information. In certain embodiments of the invention, the service provider may want to access and receive the same search results or supply and demand information displayed to the customer. In some embodiments of the invention, the system may allow the client and the service provider to exchange with each other, in whole or in part, the information displayed to them, which provides a more transparent negotiation process. It will be understood that drivers may be provided with indicators that represent the characteristic of the customer, not only for price negotiation, but also for various other embodiments of the invention discussed herein. For example, when a driver is evaluating whether to select a job from a pool of job offers, or to accept a new or available service request that the system notifies him / her of, the system may be configured to provide the driver with access to information regarding a customer associated with the service request. , and a review of indicators related to the desired information in relation to the client. Thus, the driver can make an informed decision as to whether to accept a pre-planned service request.

[0216] In accordance with an exemplary embodiment of the present invention, a system may use a set of indicators to help simplify pricing information regarding the response of one or more service providers to a quote from a customer, whereby the customer can negotiate a price simultaneously with several of the best matching drivers. ... In some embodiments of the invention, when a customer submits a service request without a specified price, and the service provider responds with a suggested price, which can be either negotiable or non-negotiable, the system may display numeric price data initiated by the driver (s) to the customer. with a set of indicators. If the offered prices are negotiable, then the offers can be made alternately in one direction and the other, until a final deal is concluded or the deal is canceled.

[0217] In accordance with some embodiments of the invention, different sets of indicators may be used for different situations depending on which party initiates the bid. The indicators themselves can indicate whether the quote is above, below, or equal to the default price provided by the system. For example, the system might display a green indicator or upward arrow for an triggered price above the default price, or a red indicator or downward arrow for a price that is below the default price. Prices that exactly match the default price can be displayed as a yellow indicator or as a dot. These three different colors convey the difference in each of the three situations and illustrate a clear difference that allows users to sort faster based on the visual representation that would otherwise take longer. For example, the view includes the actual bid, along with information that compares the difference between the bid and the default price as a dollar amount or as a percentage. This set of indicators can be disabled or can optionally display one or any portions at the discretion of the user. During such a pre-planned service request, the system may be configured to time-out negotiations if no final price has been agreed, or may allow the customer to continue negotiations up to the date and time of the service request. Users can also set limits on which bids are automatically rejected by initially setting a price threshold higher or lower than the default price. Preferably, these sets of indicators are displayed to both the client and the service provider. The system can display different sets of indicators for any type of user. A client who requests quotations from a service provider can pre-set in the settings so as not to see any quotations that are higher than or equal to the price exceeding the default by 50 percent. Otherwise, quotations may be automatically rejected. The client can, at his own discretion, choose which price indicators to see depending on the price difference.

[0218] An indicator may also be displayed to the client, reflecting information regarding the area information based on the total number of service requests made by the service provider within the geographic area in which the client indicates the landing location in the service request. Such an indicator may be representative of the historical data obtained from the database 108. It is understood that this indicator can provide the client with a visual representation that quickly conveys the experience or familiarity of the service provider at the landing site. Such information can help inform the client about which service provider might be better suited to their service request due to their greater experience in this area.

[0219] A set of indicators can display the number of potential available service providers versus the number of potential available customers within each geographic area, the pool of potential available service providers and the pool of potential available customers, as well as geographic areas depending on search parameters, including number, time and distance or any combination thereof. This set of indicators can provide information on supply and demand within each geographic area, depending on the search parameters that can be taken into account when setting prices. In certain embodiments of the invention, service providers may also set restrictions on their displays to show only requests from select clients, preferred clients, or from select, preferred, regular and new clients.

[0220] It is understood that various embodiments of the systems and methods described herein substantially reduce or eliminate manual dispatching services by providing automatic dispatching services through computing devices allowing for more complete communication between clients, drivers and dispatchers through dynamic deployment. information through one or more remote computing devices, and provide a full range of dispatch services, including scheduling service requests in advance, sending service requests, dynamically updating and facilitating changes in service requests, and providing real-time information to all parties customer transportation time.

[0221] It should be understood that the phrases or terminology used in this document are intended for purposes of description and not limitation. Although the invention has been shown and described with reference to various preferred embodiments of the invention, those skilled in the art will readily understand that various changes and / or modifications can be made without departing from the spirit and scope of the invention as defined by the claims. Any exemplary embodiments of the invention described herein are illustrative only, and a large number of variations may be presented without departing from the spirit of the invention or the scope of the appended claims. For example, elements and / or design features of various exemplary embodiments of the present invention may be combined with one another and / or substituted for one another. Therefore, the scope of the present invention will be determined solely by the following claims, and it will be apparent to those skilled in the art that numerous changes can be made to such elements without departing from the spirit and principles of the present invention.

Claims (94)

1. A computer-implemented method of providing adaptable to specific needs, automated, pre-planned dispatching services for transportation, including: receiving, by the server, area data associated with a plurality of predetermined driver service areas, each predetermined driver service area being defined by one or more geographic regions; receiving by the server a plurality of predetermined preferences or restrictions of a certain number of drivers; a server receiving a plurality of client selectable presets provided by a plurality of clients; storing in the database a plurality of predetermined driving service areas, a plurality of predetermined driving preferences or restrictions, and a plurality of client-selectable preset preferences; the server receiving a plurality of service requests for scheduling in advance, each service request corresponding to one of the plurality of clients and containing location and time specific data associated with at least a pick-up location and a drop-off location; the analysis server performs a plurality of service requests collected in one or more packets, each packet corresponding to a corresponding predetermined driver service area and includes one or more of a plurality of service requests with pickup and drop-off locations that are both within corresponding to a predetermined driving service area; scheduling in advance multiple service requests for each of one or more packages: (i) retrieving from the database a set of a number of drivers associated with the corresponding predetermined driver coverage area corresponding to the package; (ii) automatically establishing by the server, in accordance with one or more predefined rules for each corresponding service request from the given packet, a weighted priority for each driver in the set, the weighted priority based on the assigned weights for at least one factor, related to a service associated with a corresponding service request, and wherein the at least one factor related to the service includes at least one of a plurality of predetermined driving preferences or restrictions, or at least one of a client selectable preset preferences, matching the service request; and (iii) applying one or more predetermined rules by the server to assign a driver from the set to the corresponding service request based on the weighted driver priority; sending, by the server, to the computing device of the particular driver, a dispatch notification that includes one or more assigned service requests; and receiving by the server from the computing device of a particular driver confirmation of at least one of the assigned service requests. 2. A method according to claim 1, wherein each of the one or more predefined rules comprises rule criteria and a rule function. 3. A method according to claim 2, characterized in that one or more predefined rules contain default rules and preferential rules, wherein the preferential rules are predefined by at least either the client or the driver and have priority over the default rules, and when Thereby, the default or preferential rules define assigned weights for each of the at least one factor related to the service. 4. The method of claim 1, wherein the server receives from the plurality of driver computing devices a plurality of predetermined driver service areas, and the plurality of driver computing devices are configured to allow a number of drivers to select a predetermined driver service area to which it is assigned. driver. 5. The method according to claim 1, further comprising: receiving input data from one or more computing devices of a certain number of drivers, the input data comprising a plurality of predetermined driver service areas or a plurality of predetermined driving preferences or restrictions, wherein the plurality of predetermined driving preferences or restrictions comprise at least one or more personal restrictions or one or more regulatory restrictions; and storing input data by dynamically updating the database based on a plurality of predetermined driving preferences or restrictions. 6. The method according to claim. 1, characterized in that at least one predetermined area of the driver's service is determined by a geographic region of service, which is selected through at least one of the plurality of computing devices of the driver, at least one of: one or more streets, one or more boroughs of a city, one or more zip codes, one or more administrative centers or townships, one or more cities, one or more boroughs, one or more counties, or one or more states. 7. The method according to claim 6, further comprising: displaying, on at least one of the plurality of driver computing devices, an electronic map display divided into a plurality of interactive geographic regions corresponding to a plurality of predetermined driver service areas, each interactive geographic region being selected by the driver to enter a predetermined driver service area. 8. The method according to claim 1, further comprising: displaying, on one or more client computing devices, an interactive electronic interface; and encouraging one or more customers to provide one or more of the customer selectable presets as desired customer preferences, wherein the customer selectable presets include preferences associated with at least one of: driver category, vehicle type, vehicle make and model, number of vehicle seats, vehicle capacity, vehicle carrying capacity, readiness to transport a wheelchair, availability of a child seat, ability to accommodate pets, language skills, gender, driving experience, familiarity with the route, experience with certain types of goods, placement of fragile goods or goods requiring special packaging, delivery method or one or more other characteristic features of the driver category or vehicle type. 9. The method according to claim 1, further comprising: creation by the server of a data table for a specific package, while the data table includes, for each service request for a specific package, in accordance with one or more predetermined rules, the ranked compatibility of each of a set of a certain number of drivers, depending on the weighted priority of each driver from a set and another factor containing at least one of: the availability of each driver from the set to accept a service request, a driver category, one or more sets of indicators defining factors related to a service, or a customer category. 10. The method of claim 9, wherein the driver category includes a select driver, preferred driver, or regular driver, and wherein the customer category includes a select customer, preferred customer, or regular customer. 11. The method according to claim 10, further comprising: determining, depending on the weighted priority of each driver in the set for a particular service request, the selected driver with the highest priority or the preferred driver with the highest priority and the subsequent select driver or the subsequent preferred driver; and assigning a service request to a subsequent select driver or a subsequent preferred driver in a situation where the highest priority preferred driver or the highest priority preferred driver is not available, with the preferred driver assigned a higher weighted value than the preferred driver and the preferred driver assigned a higher weighted value than a regular driver. 12. The method according to claim 11, further comprising: retrieving from a database a set of historical positioning data obtained using a global positioning system (GPS) associated with at least a portion of historical service data for one or more of a number of drivers, whereby GPS position data is received from a GPS receiver associated with one or more driving computing devices of a number of drivers; and calculating the route familiarity level of at least one of the respective service requests for at least one driver out of a number of drivers, by (i) comparing the GPS location dataset for the route of the corresponding service request with the GPS historical location dataset , and (ii) determining compatibility between the GPS location dataset for the route of the corresponding service request and the GPS historical location dataset, the familiarity level being calculated by determining the degree of overlap between the route of the corresponding service request and the route data associated with with at least one of many drivers; and displaying, on at least one client computing device, a total value in the form of at least one of: level, range of levels, degree, range of degrees, rating, range of ratings, percentage, range of percent, or an image or illustration, wherein at least At least one of the factors related to the service includes the level of familiarity. 13. The method of claim 11, further comprising: storing one or more unassigned or unaccepted service requests in the job offer pool in response to one or more service requests remaining unassigned or unaccepted by at least one driver, the job offer pool is available to at least one or more available drivers through one or several driving computing devices; displaying one or more unassigned service requests with one or more client indicators on one or more driver computing devices, with one or more client indicators corresponding to a client associated with one or more unassigned or unaccepted service requests; getting a selection from one or more unassigned service requests in the pool of job offers to available drivers; and updating the fund of job offers in response to a choice. 14. The method of claim 13, wherein the one or more client indicators identify service related factors associated with unassigned or rejected service requests. 15. The method of claim 11, further comprising: receiving a message from the driver assigned to the at least one service request that the driver is unable to fulfill the at least one service request, and receiving a request from the driver to transfer the at least one service request to the partner driver; delivering to the partner driver a request to transmit at least one service request; receiving from the partner driver a confirmation of a request to transfer at least one service request; and updating the database to indicate the transmission of at least one service request to the partner driver. 16. A computer-implemented system for providing adaptable to specific needs, automated, pre-planned dispatching services for transportation, containing: a server connected with the possibility of transmitting information to one or more computing devices via a network, wherein one or more computing devices include one or more location identifiers configured to determine location data corresponding to one or more locations, and at the same time the server contains at least one long-term computer-readable storage medium with stored computer-readable instructions, a database and a processor for executing the computer-readable instructions in order to: obtain, with the help of a server, area data associated with a plurality of predetermined driver service areas, each predetermined driver service area being defined by one or more geographic regions; receive, with the help of the server, a set of predetermined preferences or restrictions of a certain number of drivers; receive, via a server, a plurality of client selectable presets provided by a plurality of clients; store in the database a plurality of predetermined driving service areas, a plurality of predetermined driving preferences or restrictions, and a plurality of client-selectable preset preferences; receive, with the help of the server, a plurality of service requests for scheduling in advance, with each service request corresponding to one of the plurality of clients and containing location and time specific data associated with at least a pick-up location and a drop-off location; analyze, with the help of the server, a plurality of service requests collected in one or more packages, each package corresponding to a corresponding predetermined driver's service area and includes one or more of a plurality of service requests with pickup and drop-off locations that are both are within the respective predetermined driving service area; plan in advance many service requests for each of one or more packages: (i) retrieve from the database a set of a number of drivers associated with the corresponding predetermined driver service area corresponding to the package; (ii) automatically set by the server, in accordance with one or more predefined rules for each corresponding service request from the given package, a weighted priority for each driver from the set, the weighted priority based on the assigned weighting factors for at least one factor, related to a service associated with a corresponding service request, and wherein the at least one factor related to the service includes at least one of a plurality of predetermined driving preferences or restrictions, or at least one of a client selectable preset preferences, matching the service request; and (iii) apply one or more predefined rules by the server to assign a driver from the set to the corresponding service request based on the weighted driver priority; send by the server to the computing device of a specific driver a dispatch notification that includes one or more assigned service requests; and receiving by the server from the computing device of a particular driver confirmation of at least one of the assigned service requests. 17. The system of claim 16, wherein each of the one or more predefined rules comprises rule criteria and a rule function. 18. The system according to claim 17, characterized in that one or more predefined rules contain default rules and preferential rules, while the preferential rules are predefined by at least either the client or the driver and have priority over the default rules, and when Thereby, the default or preferential rules define assigned weights for each of the at least one factor related to the service. 19. The system of claim 16, wherein the processor further executes computer readable instructions to: receive, via a server, a plurality of predetermined driver service areas from a plurality of driver computing devices, the plurality of driver computing devices being configured to allow a number of drivers to select a predetermined driver service area to which the driver is assigned. 20. The system of claim 16, wherein the processor further executes computer readable instructions to: receive input from one or more computing devices of a number of drivers, the input data comprising a plurality of predetermined driver service areas or a plurality of predetermined driving preferences or restrictions, the set of predetermined driving preferences or restrictions comprising at least one or more personal restrictions, or one or more regulatory restrictions; and save input data by dynamically updating the database based on a variety of predetermined driving preferences or restrictions. 21. The system of claim. 16, characterized in that at least one predetermined area of the driver's service is determined by the geographic region of service, which is selected through at least one of the plurality of computing devices of the driver, at least one of: one or more streets, one or more boroughs of a city, one or more zip codes, one or more administrative centers or townships, one or more cities, one or more boroughs, one or more counties, or one or more states. 22. The system of claim 21, wherein the processor further executes computer readable instructions to: display, on at least one of the plurality of driver computing devices, an electronic map display divided into a plurality of interactive geographic regions corresponding to a plurality of predetermined driver service areas, each interactive geographic region being selected by the driver to enter a predetermined driver service area. 23. The system of claim. 16, wherein the processor additionally executes computer readable instructions to: display, on one or more client computing devices, an interactive electronic interface; and Encourage one or more customers to provide one or more of the customer selectable presets as desired customer preferences, wherein the customer selectable presets include preferences associated with at least one of: driver category, vehicle type, vehicle make and model, number of vehicle seats, vehicle capacity, vehicle carrying capacity, readiness to transport a wheelchair, availability of a child seat, ability to accommodate pets, language skills, gender, driving experience, familiarity with the route, experience with certain types of goods, placement of fragile goods or goods requiring special packaging, delivery method or one or more other characteristic features of driver category or vehicle type. 24. The system of claim. 16, characterized in that the processor additionally executes computer readable instructions in order to: create, using the server, data tables for a specific package, while the data table includes, for each service request for a specific package, in accordance with one or more predefined rules, the ranked compatibility of each of the set of a certain number of drivers, depending on the weighted the priority of each driver from the set; and another factor containing at least one of: the availability of each driver from the set to accept a service request, the driver category, one or more sets of indicators defining factors related to the service, or the customer category. 25. The system of claim 24, wherein the driver category includes a select driver, preferred driver, or regular driver, and wherein the customer category includes a select customer, preferred customer, or regular customer. 26. The system of claim 25, wherein the processor further executes computer readable instructions to: determine, depending on the weighted priority of each driver in the set for a particular service request, the selected driver with the highest priority or the preferred driver with the highest priority and the subsequent select driver or the subsequent preferred driver; and assign a service request to a subsequent select driver or a subsequent preferred driver in a situation where the highest priority chosen driver or the highest priority preferred driver is not available, with the preferred driver assigned a higher weighted value than the preferred driver and the preferred driver assigned a higher weighted value than a regular driver. 27. The system of claim. 16, characterized in that the processor additionally executes computer readable instructions in order to: retrieve from a database a set of historical positioning data obtained using a global positioning system (GPS) associated with at least a portion of historical service data for one or more of a number of drivers, whereby GPS position data is received from a GPS receiver associated with one or more driving computing devices of a number of drivers; and calculate the route familiarity level of at least one of the respective service requests for at least one driver out of a number of drivers, by (i) comparing the GPS location dataset for the route of the corresponding service request with the GPS historical location dataset , and (ii) determining compatibility between the GPS location dataset for the route of the corresponding service request and the GPS historical location dataset, the familiarity level being calculated by determining the degree of overlap between the route of the corresponding service request and the route data associated with with at least one of many drivers; and display, on at least one client computing device, the total value in the form of at least one of: level, range of levels, degree, range of degrees, rating, range of ratings, percentage, range of percent, or an image or illustration, wherein at least At least one of the factors related to the service includes the level of familiarity. 28. The system of claim 16, wherein the processor further executes computer readable instructions to: store one or more unassigned or unaccepted service requests in the job offer pool in response to one or more service requests remaining unassigned or unaccepted by at least one driver, the job offer pool is available to at least one or more available drivers through one or several driver's computing devices; display one or more unassigned service requests with one or more indicators on one or more driver computing devices, with one or more client indicators corresponding to a customer associated with one or more unassigned or unaccepted service requests; receive a selection from one or more unassigned service requests in the pool of job offers to available drivers; and update the fund of job offers in response to the choice. 29. The system of claim 28, wherein the one or more client indicators identify service related factors associated with unassigned or rejected service requests. 30. The system of claim 16, wherein the processor further executes computer readable instructions to: receive a message from the driver assigned to the at least one service request that the driver is unable to fulfill the at least one service request, and receive a request from the driver to transmit the at least one service request to the partner driver; deliver to the driver partner a request to transmit at least one service request; receive from the partner driver confirmation of the request to transfer at least one service request; and update the database to indicate the transmission to the partner driver of at least one service request.

Images