System and method for adaptively identifying optimal model for selecting path to location

Abstract

The present disclosure provides systems and methods for adaptively identifying an optimal model for selecting a path to a location, including: a method for adaptively identifying an optimal model for selecting a path to a location, comprising: providing one or more first models based on path characteristics associated with the location; retrieving one or more first parameters associated with the path characteristics to determine a validity of each of the one or more first models in minimizing the path cost parameter; and selecting an optimal model from the one or more first models based on the validity.

Description

Technical Field

[0001] The present invention generally relates to systems and methods for identifying an optimal model, and more particularly, to systems and methods for adaptively identifying an optimal model for selecting a path to a location. Background Art

[0002] In the delivery business, last mile route optimization is an important component that directly affects customer experience, delivery costs and resource utilization. It can affect customer experience by affecting the duration before delivery is completed, a key indicator in instant delivery services. It can also affect customer experience when there is a delivery time commitment or other delivery requirements (such as maintaining the quality of fresh and frozen goods delivered). Delivery costs can also be reduced through good route optimization, as this cost is directly related to the number of vehicles used and the total distance traveled by all vehicles to fulfill all deliveries. Route optimization also improves resource utilization by ensuring that vehicles are used to deliver as many orders as possible while meeting all specified constraints. Such vehicle route optimization software is also often referred to as a route optimizer.

[0003] Typically, the delivery routing problem is modeled as a vehicle routing problem (VRP) (hereinafter referred to as routing constraints), where the objective function is to minimize the cost of fulfilling all orders (in this case, the cost can be monetary cost, driving distance, time spent on the road, or even a combination of these) (hereinafter referred to as routing cost parameters) while satisfying various constraints as required by the business. Some of these routing constraints include limited vehicle availability, vehicle capacity, delivery time windows, pickup before delivery, etc. In VRP, the demand is modeled as a set of node locations to be visited. The problem is usually solved by a routing optimizer to provide a solution that specifies the paths that vehicles are to take to fulfill customer requests in a certain sequence.

[0004] For VRPs with smaller problem / constraint sizes, they can be solved by path optimizers based on exact optimization algorithms (such as branch and bound or column generation). Since exact solution algorithms rely on the mathematical representation of VRPs, they are inherently scalable and flexible. However, they suffer from the curse of dimensionality (i.e., they cannot solve large-scale problems within a reasonable amount of time and computing resources). Therefore, this type of optimizer is not suitable for solving large-scale VRPs with a large number of different types of constraints, which is a computationally intensive task and it is not easy to find a feasible solution. Examples of such general mathematical optimizers include Google OR tools, Gurobi, CPLEX, etc.

[0005] As such, large-scale VRPs are typically solved with heuristic-based path optimizers, and are able to obtain high-quality solutions within a reasonable amount of time and computing resources. These heuristic-based optimizers are typically dedicated, developed to solve specific variants of path constraints / problems (e.g., with capacity and / or time windows) and do not provide a lot of scalability and flexibility. In addition, the implemented heuristics are tuned for the expected variants and typically do not do well when solving different variants of constraints / problems. This is the "no free lunch theorem" of algorithms, which roughly states that no algorithm is better than all other algorithms when solving a given problem - in other words, all algorithms have their own advantages and disadvantages depending on the nature of the problem at hand (e.g., type of constraints, problem size, etc.). Examples of such dedicated VRP optimizers include OptimoRoute, Circuit, Bringoz, etc.

[0006] Therefore, there is a need for novel methods and systems designed to adaptively identify the best model for selecting a path to a location to solve the problem, and more specifically, to combine the benefits of exact (flexibility and scalability) and heuristic (scalability and performance) methods.

[0007] Furthermore, other desirable features and characteristics will become apparent from the subsequent detailed description and the appended claims, taken in conjunction with the accompanying drawings and this background of the disclosure. Summary of the invention

[0008] In a first aspect, the present disclosure provides a method for adaptively identifying an optimal model for selecting a path to a location, the method comprising: providing one or more first models based on path characteristics associated with the location; retrieving one or more first parameters associated with the path characteristics to determine the effectiveness of each of the one or more first models in minimizing a path cost parameter; and selecting an optimal model from the one or more first models based on the effectiveness.

[0009] In a second aspect, the present disclosure provides a system for adaptively identifying an optimal path connecting multiple destinations, the system comprising: at least one processor; and at least one memory comprising computer program code; the at least one memory and the computer program code are configured to, together with the at least one processor, cause a server to at least perform the following steps: provide one or more first models based on path characteristics associated with a location; retrieve one or more first parameters associated with the path characteristics to determine the effectiveness of each of the one or more first models in minimizing a path cost parameter; and select an optimal model from the one or more first models based on the effectiveness.

[0010] From the description and drawings, additional benefits and advantages of the disclosed embodiments will become apparent. Benefits and / or advantages can be obtained by various embodiments and features of the description and drawings alone, which do not need to be provided in full in order to obtain one or more of such benefits and / or advantages. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The embodiments and implementations are provided by way of example only and will be better understood and readily apparent to one of ordinary skill in the art from the following written description read in conjunction with the accompanying drawings, in which:

[0012] Figure 1 A block diagram illustrating a system for adaptively identifying an optimal model for selecting a path to a location in accordance with various embodiments of the present disclosure is shown.

[0013] Figure 2 A block diagram illustrating various components of a system for adaptively identifying an optimal model for selecting a path to a location in accordance with an embodiment of the present disclosure is shown.

[0014] Figure 3 A flow chart illustrating a method for adaptively identifying an optimal model for selecting a path to a location according to an embodiment of the present disclosure is shown.

[0015] Figure 4 A flow chart illustrating the relationship of entities according to an embodiment of the present disclosure is shown.

[0016] Figure 5 Shown is a block diagram illustrating different types of abstract constraints according to an embodiment of the present disclosure.

[0017] Figure 6 A block diagram illustrating a path entity data structure according to an embodiment of the present disclosure is shown.

[0018] Figure 7 A flow chart illustrating a process of an iterative search process for adaptively identifying an optimal model for selecting a path to a location in accordance with an embodiment of the present disclosure is shown.

[0019] Figure 8 A flow chart illustrating the process of an adaptive large neighborhood search process for adaptively identifying an optimal model for selecting a path to a location in accordance with an embodiment of the present disclosure is shown.

[0020] Fig. 9 A flow chart illustrating a vehicle path optimizer and external interfaces for adaptively identifying an optimal model for selecting a path to a location according to an embodiment of the present disclosure is shown.

[0021] Fig. 10AA diagram illustrating locations corresponding to a Capacity Constrained Vehicle Routing Problem for Pickup and Delivery (CVRPPD) problem and an initial model (solution) for selecting paths to the locations according to an embodiment of the present disclosure is shown.

[0022] Fig. 10B The diagram shows the diagram Fig. 10A Illustration of an improved solution for selecting a path to a location in .

[0023] Fig.11 An exemplary implementation of a vehicle path optimizer according to an embodiment of the present disclosure is shown.

[0024] Fig.12 A sample of an input data file according to an embodiment of the present disclosure is shown.

[0025] Fig.13 Exemplary interface layers for a system implementation for adaptively identifying an optimal model for selecting a path to a location according to an embodiment of the present disclosure are shown.

[0026] Fig.14 A sample native read-evaluate-print loop (REPL) interface according to an embodiment of the present disclosure is shown.

[0027] Fig.15 and Fig.16 Shows that it can be practiced on Figure 1 Schematic diagram of a general computer system of a coordination server.

[0028] Fig.17 Shown is the method for implementing Figure 1 An alternative computer device to the coordination server.

[0029] Fig.18 Shows that it can be practiced on Figure 1 Schematic diagram of a general computer system of a model recognition server.

[0030] Fig.19 Shown is a method for implementing Figure 1 An alternative computer device to the model recognition server.

[0031] Fig. 20 Shows that it can be practiced on Figure 1 Schematic diagram of a general computer system of a combined coordination and model recognition server.

[0032] Fig.21 Shown is the method for implementing Figure 1 An alternative computer device for a combined coordination and model recognition server.

[0033] The skilled person will understand that the elements in the drawings are illustrated for simplicity and clarity and are not necessarily drawn to scale. For example, the size of some elements in the diagrams, block diagrams or flow charts may be exaggerated relative to other elements to help improve the understanding of the embodiments of the present invention. DETAILED DESCRIPTION

[0034] The following detailed description is merely exemplary in nature and is not intended to limit the invention or the application and use of the invention. In addition, there is no intention to be limited by any theory presented in the foregoing background technology of the invention or the following detailed description. The intention of the present invention is to propose a service request allocation system and method in the absence of available service provider conditions.

[0035] When steps and / or features are referenced in any one or more of the drawings with the same reference number, unless otherwise intended, for the purposes of this description, those steps and / or features have the same function or operation.

[0036] It should be noted that the discussion contained in the "Background Art" section and the discussion above relating to prior art devices relate to discussions of devices whose use forms part of the common knowledge. This should not be construed as a representation by the inventor or patent applicant that such devices in any way form part of the common general knowledge in the art.

[0037] Some portions of the following description are presented explicitly or implicitly in terms of algorithms and functional or symbolic representations of operations on data within a computer memory. These algorithmic descriptions and functional or symbolic representations are the means used by those skilled in the art of data processing to most effectively convey the substance of their work to others skilled in the art. An algorithm is here and generally conceived to be a self-consistent sequence of steps leading to a desired result. Steps are those steps requiring physical manipulation of physical quantities (such as electrical, magnetic or optical signals) that can be stored, transferred, combined, compared and otherwise manipulated.

[0038] Unless otherwise specifically stated, and as will become apparent from the following text, it should be understood that throughout this specification, discussions utilizing terms such as "receive," "calculate," "determine," "update," "generate," "initialize," "output," "receive," "retrieve," "identify," "distribute," "verify," etc., refer to the actions and processes by a computer system or similar electronic device to manipulate and transform data represented as physical quantities within the computer system into other data similarly represented as physical quantities within the computer system or other information storage, transmission, or display device.

[0039] This specification also discloses a device for performing the operation of the method. Such a device may be specially constructed for the desired purpose, or may include a computer or other device selectively activated or reconfigured by a computer program stored in the computer. The algorithms and displays presented herein are not inherently related to any specific computer or other device. Various machines may be used with programs according to the teachings of this article. Alternatively, it may be appropriate to construct a more specialized device to perform the desired method steps. The structure of the computer will appear from the following description.

[0040] In addition, this specification also implicitly discloses a computer program, because it is obvious to those skilled in the art that the various steps of the method described herein can be implemented by computer code. The computer program is not intended to be limited to any specific programming language and its implementation. It should be understood that various programming languages ​​and their encodings can be used to implement the teachings of the disclosure contained herein. In addition, the computer program is not intended to be limited to any specific control flow. There are multiple other variations of the computer program that can use different control flows without departing from the spirit or scope of the present invention.

[0041] In addition, one or more of the steps of the computer program may be performed in parallel rather than sequentially. Such a computer program may be stored on any computer readable medium. The computer readable medium may include a storage device, such as a disk or optical disk, a memory chip, or other storage device suitable for being connected to a computer interface. The computer readable medium may also include a hardwired medium such as exemplified in an Internet system or a wireless medium such as exemplified in a GSM mobile phone system. The computer program, when loaded and executed on such a computer, effectively produces a device that implements the steps of the preferred method.

[0042] In the various embodiments below, a path refers to a path connecting a sequence of locations (nodes) that a vehicle of a particular vehicle type will visit. For simplicity, the term "path to a location" is used. The skilled person will understand that such a term can refer to a path leading to more than one location. It should also be understood that the word "location" in such a term can refer to the final / last location (destination) in a sequence of locations, where the path connects all other locations in the sequence that end at the final / last location.

[0043] Similarly, for simplicity, the term "optimal model for selecting a path" is used. It should be understood that such terminology may refer to an optimal model for selecting multiple paths, each of which refers to a way connecting a series of locations to be visited. Multiple paths may lead to the same location (or destination) or different locations (or destinations).

[0044] Such an optimal model may also be applied to first-mile delivery, middle-mile delivery, or last-mile delivery, or a combination thereof. For example, in a hub-and-spoke model where multiple items are batched together, a driver may collect items from multiple sources and deliver them to an origin hub ("first mile" delivery). From here, the items may be delivered to a destination hub ("middle-mile" delivery). At the destination hub, the orders may be batched, sorted according to the batches, and then delivered to their respective destinations ("last mile" delivery). Thus, in some examples, a single driver is picking up multiple orders for delivery to a single destination, rather than delivering multiple orders to multiple destinations. According to the present disclosure, the same optimal model (or optimization algorithm) applied to first-mile delivery may also be applied to middle-mile delivery and / or last-mile delivery, and vice versa, to select the best path. In other words, methods and systems are provided for adaptively identifying an optimal model that is capable of selecting an optimal path (or a near-optimal path) for a driver to pick up all of his assigned orders en route to an origin hub, from one or more origin hubs to one or more destination hubs, and / or from a destination hub to multiple destinations.

[0045] According to various embodiments of the present disclosure, a process of adaptively identifying an optimal model for selecting a path to a location may be implemented by a system. Figure 1 A block diagram illustrating a system 100 for adaptively identifying an optimal model for selecting a path to a location according to an embodiment is shown. In addition, the system 100 can enable transactions of goods or services, and / or requests for goods or services (e.g., model data, path data, vehicle data, location data, model identification services, or path selection services) between requesters and providers (which may be referred to herein as "users").

[0046] The system includes a requester device 102 , a provider device 104 , an acquirer server 106 , a coordination server 108 , an issuer server 110 , and a pattern recognition server 112 .

[0047] A user may be any suitable type of entity, and may include a customer, company, business, or government entity (i.e., requestor) who wishes to purchase or request goods or services (e.g., model data, path data, vehicle data, location data, model identification services, or path selection services) via the coordination server 108, or an application developer, company, business, or government entity (i.e., provider) who wishes to sell or provide goods or services (e.g., model data, path data, vehicle data, location data, model identification services, or path selection services) via the coordination server 108.

[0048] The requester device 102 is associated with a customer (or requester) who is a party to a request for goods or services that occurs, for example, between the requester device 102 and the provider device 104. The requester device 102 may be a computing device such as a desktop computer, an interactive voice response (IVR) system, a smart phone, a laptop computer, a personal digital assistant computer (PDA), a mobile computer, a tablet computer, etc.

[0049] The requester device 102 may include user credentials (e.g., a user account) of the requester that enables the requester device 102 to become a party to the transaction. If the requester has a user account, the user account may also be included (i.e., stored) in the requester device 102. For example, a mobile device (as the requester device 102) may store the customer's user account in the mobile device.

[0050] In one example arrangement, the requester device 102 is a computing device in the form of a watch or similar wearable and is equipped with a wireless communication interface (e.g., an NFC interface). The requester device 102 can then electronically communicate with the provider device 104 regarding the transaction or coordination request. The customer uses the watch or similar wearable to make a request regarding the transaction or coordination request by pressing a button on the watch or wearable.

[0051] The provider device 104 is associated with a provider that is also a party to a request for goods or services that occurs between the requester device 102 and the provider device 104. The provider device 102 may be a computing device such as a desktop computer, an interactive voice response (IVR) system, a smart phone, a laptop computer, a personal digital assistant computer (PDA), a mobile computer, a tablet computer, etc.

[0052] Hereinafter, the term "provider" refers to a service provider and any third party associated with goods or services provided for purchase via provider device 104. Thus, a user account of a provider refers to both the user account of the provider and the user account of a third party associated with the provider (e.g., a path coordinator).

[0053] If the provider has a user account, the details of the user account may also be included (i.e., stored) in the provider device 104. For example, a mobile device (which is the provider device 104) may have the user account details (e.g., account number) of the provider stored in the mobile device.

[0054] In one example arrangement, the provider device 104 is a computing device in the form of a watch or similar wearable and is equipped with a wireless communication interface (e.g., an NFC interface). The provider device 104 can then electronically communicate with the requester to make a request for a transaction or a travel request by pressing a button on the watch or wearable.

[0055] The acquirer server 106 is associated with an acquirer, which may be an entity (e.g., a company or organization) that issues (e.g., establishes, manages, oversees) a payment account (e.g., a financial bank account) of a merchant (e.g., a provider). An example of an acquirer is a bank or other financial institution. As discussed above, the acquirer server 106 may include one or more computing devices for establishing communication with another server (e.g., a coordination server 108) by exchanging messages with the other servers and / or passing information to the other servers. The acquirer server 106 forwards the payment transaction associated with the transaction or shipping request to the coordination server 108.

[0056] The coordination server 108 is configured to perform processes related to the user account by, for example, forwarding data and information associated with the transaction to other servers in the system 100, such as the model recognition server 112. In an example, the coordination server 108 may provide location data, vehicle data, path data, model data associated with a request including parameters that may be used for a path selection / generation process and adaptive model recognition by the model recognition server 112. An image may be determined based on the results of the preview process, for example, an image corresponding to a drop-off point at a location based on the location information.

[0057] The issuer server 110 is associated with an issuer and may include one or more computing devices for performing payment transactions. The issuer may be an entity (e.g., a company or organization) that issues (e.g., establishes, manages, oversees) a transaction credential or payment account (e.g., a financial bank account) associated with the owner of the requester device 102. As discussed above, the issuer server 110 may include one or more computing devices for establishing communication with another server (e.g., the coordination server 108) by exchanging messages with the other server and / or passing information to the other server.

[0058] The coordination server 108 may be a server hosting a software application for processing a transaction or coordination request (e.g., a user purchasing a good or service). The coordination server 108 may also be configured to process coordination requests between a requester and a provider. The coordination server communicates with other servers (e.g., a model recognition server 112) regarding the transaction or coordination request. The coordination server 108 may communicate with the model recognition server 112 to facilitate adaptive identification of an optimal model for selecting a path to a location associated with the transaction or coordination request. The coordination server 108 may use a variety of different protocols and processes in order to process the transaction or coordination request.

[0059] In an example, the coordination server 108 may receive transaction and location, vehicle, path, and model data associated with a request from a user device (such as the requester device 112 or the provider device 114), the request including the problem context, constraints, path characteristics, path costs, and parameters used in the model typically associated with the location or request, and provide the data to the model identification server 112 for use in the adaptive optimal model identification and path selection process.

[0060] Additionally, transactions that may be performed via the coordination server include purchases of goods or services, credit purchases, debit transactions, funds transfers, account withdrawals, etc. The coordination server may be configured to process transactions via cash substitutes, which may include payment cards, letters of credit, checks, payment accounts, tokens, etc.

[0061] Coordination server 108 is typically managed by a service provider, which may be an entity (eg, a company or organization) that operates to process transaction requests or coordination requests. Coordination server 108 may include one or more computing devices for processing transaction requests or coordination requests.

[0062] The user account may be an account of a user registered at the coordination server 108. The user may be a customer, a service provider (e.g., a ride-hailing service provider or a delivery service provider), or any third party (e.g., a map / route planner) who wants to use the coordination server. Users registered with the coordination server 108 or the model recognition server 112 will be referred to as registered users. Users who are not registered with the coordination server 108 or the model recognition server 112 will be referred to as unregistered users.

[0063] The coordination server 108 may also be configured to manage the registration of users. A registered user has a user account including the user's details and data. The registration step is called on-boarding. A user may use the requester device 102 or the provider device 104 to perform on-boarding the coordination server 108.

[0064] The joining process of the user is performed by the user through one of the requester device 102 or the provider device 104. In one arrangement, the user downloads an application (which includes an API or otherwise provides access to the API to interact with the coordination server 108) to the requester device 102 or the provider device 104. In another arrangement, the user visits a website (which includes an API or otherwise provides access to the API to interact with the coordination server 108) on the requester device 102 or the provider device 104. The user is then able to interact with the model recognition server 112. The user can be a requester or a provider associated with the requester device 102 or the provider device 104, respectively.

[0065] The registered details include, for example, user name, user address, emergency contacts, next of kin contacts, license plate number, vehicle type, permission to retrieve data and information from the requesting device 102 and / or the providing device 104. Alternatively, another mobile device may be selected to retrieve the details / data instead of the requesting device 102 and / or the providing device 104. Once joined, the user will have a user account where all the details / data are stored.

[0066] It may not be necessary to have a user account at the coordination server 108 to access the functionality of the coordination server 108. However, there may be functionality available only to registered users, for example, providing certain selections of advanced parameters for processing and identifying the best model. The term user will be used to refer collectively to both registered users and non-registered users. A user may be interchangeably referred to as a requester (e.g., a person requesting a path to a location or a model for identifying such a path) or a provider (e.g., a person providing the best model among multiple models for selecting the (best) path to a location).

[0067] Coordination server 108 may be configured to communicate with database 109 via connection 128, or may include the database. Connection 128 may be through a network (e.g., a local area network, a wide area network, the Internet, etc.). Database 128 stores user details / data and data corresponding to transactions (or transaction data). Examples of transaction data include transaction identifier (ID), merchant (provider) ID, merchant name, MCC / industry code, industry description, merchant country, merchant address, merchant postal code, aggregate merchant ID. For example, data related to the merchant / provider ("merchant name" or "merchant ID"), time and date related to the goods / services transaction.

[0068] The model identification server 112 may be a server that hosts a model and path identification software application for adaptively identifying an optimal model for selecting a path to a location. In one embodiment, each node is associated with a road within a graph / map. In one example, the model identification server 112 may obtain data related to a node / location, vehicle, path, subnetwork, or graph network (e.g., problem context, constraints, path characteristics, path costs associated with the location) and / or its model processing parameters, such as in the form of a request, from a user device (such as a requester device 112 or a provider device 114) or a coordination server 108, and use the data to adaptively identify an optimal model for selecting a path to a location. The model identification server may be configured as follows: Fig.15 , Fig.18 and Fig. 20 The implementation is shown in .

[0069] The model recognition database 113 stores model data, including data related to locations, paths, and vehicles. The location data can be geotagged with geographic coordinates (e.g., latitude and longitude coordinates) and map matched to locate the location using the location coordinates. The model recognition database can be a component of the model recognition server 112. In an example, the model recognition database 113 can be a database managed by an external entity, and the model recognition database 113 retrieves model data (e.g., from the model recognition database 113) based on a request received from a user device (such as, the requester device 112 or the provider device 114) and transmits the data to the user device or the coordination server 108. Alternatively, a module (such as, a model recognition module) can store model data instead of the model recognition database 113, wherein the model recognition module can be integrated as part of the model recognition server 112, or can be external to the model recognition server 112.

[0070] The term "server" used herein may refer to a single computing device or multiple interconnected computing devices that operate together to perform a specific function. That is, a server may be contained within a single hardware unit or distributed among several or more different hardware units.

[0071] The requesting device 102 communicates with the providing device 104 via a connection 112. The connection 112 may be an ad hoc connection (e.g., via NFC communication, Bluetooth, etc.) or through a network (e.g., the Internet). The requesting device 102 also communicates with the model recognition server 112 via a connection 120. The connections 112, 120 may be network connections (e.g., the Internet). The requesting device 102 may also be connected to a cloud that facilitates the system 100 to adaptively identify the best model for selecting a path to a location. For example, the requesting device 102 may send a signal or data directly to the cloud via an ad hoc connection (e.g., via NFC communication, Bluetooth, etc.) or through a network (e.g., the Internet).

[0072] The provider device 104 typically communicates with the requester device 112 via the coordination server 108, as described above. The provider device 104 in turn communicates with the acquirer server 106 via connection 114. The provider device 104 also communicates with the model recognition server 112 via connection 124. Connections 114 and 124 can be network connections (e.g., provided via the Internet). The provider device 104 can also be connected to a cloud that facilitates the system 100 to adaptively identify the best model for selecting a path to a location. For example, the provider device 104 can send a signal or data directly to the cloud via an ad hoc connection (e.g., via NFC communication, Bluetooth, etc.) or over a network (e.g., the Internet).

[0073] The acquirer server 106, in turn, communicates with the coordination server 108 via a connection 116. The coordination server 108, in turn, communicates with the issuer server 110 via a connection 118. The connections 116 and 118 may be through a network (eg, the Internet).

[0074] The coordination server 108 further communicates with the model recognition server 112 via a connection 122. The connection 122 may be through a network (eg, a local area network, a wide area network, the Internet, etc.) In one arrangement, the coordination server 108 and the model recognition server 112 are combined, and the connection 122 may be an interconnect bus.

[0075] The model recognition server 112 in turn communicates with the model recognition database 113 via a connection 126. The connection 126 may be a network connection (e.g., provided via the Internet). The model recognition server 112 may also be connected to a cloud that facilitates the system 100 to adaptively identify the best model for selecting a path to a location. For example, the model recognition server 112 may send signals or data directly to the cloud via a wireless ad hoc connection (e.g., via NFC communication, Bluetooth, etc.) or over a network (e.g., the Internet).

[0076] In an illustrative embodiment, each of the devices 102, 104 and servers 106, 108, 110, 112 provides an interface to enable communication with other connected devices 102, 104 and / or servers 106, 108, 110, 112. Such communication is facilitated by an application programming interface ("API"). Such an API can be part of a user interface, which can include a graphical user interface (GUI), a web-based interface, a programming interface (such as an application programming interface (API)) and / or a remote procedure call (RPC) set corresponding to an interface element, a message transmission interface in which the interface element corresponds to a message of a communication protocol, and / or a suitable combination thereof. Examples of APIs include REST APIs, etc. For example, at least one of the requester device 102 and the provider device 104 can receive or submit a request to identify an optimal model for selecting a path to a location in response to a query shown on a GUI running on a corresponding API.

[0077] Figure 2 A block diagram illustrating various components of a system 200 for adaptively identifying an optimal model for selecting a path to a location according to an embodiment of the present disclosure is shown. The system 200 may include a model providing and generating module 202, a parameter retrieval module 204, a model validity determining module 206, an optimal model selecting module 208, a path generating module 210, a path cost parameter value determining module 212, a weighted number applying and calculating module 214, a model quantity determining module 218, a processing time determining module 220, and a location adding and removing module 222.

[0078] like Figure 3 As shown in the exemplary method for adaptively identifying an optimal model for selecting a path to a location in FIG. 1 , the system 200 is configured to perform the following steps when in operation:

[0079] - Step 302: providing one or more first models based on path characteristics associated with the location;

[0080] - Step 304: retrieving one or more first parameters associated with the path characteristic to determine the effectiveness of each of the one or more first models in minimizing the path cost parameter; and

[0081] - Step 306: A step of selecting the best model from the one or more first models based on effectiveness.

[0082] In step 302, the model providing and generating module 202 is configured to provide one or more first models based on the path characteristics associated with the location. According to an embodiment, the parameters associated with the path characteristics are the location coordinates, distance, time, load, and number of items dropped / picked up at the location; the type, load capacity, speed, and capacity of the vehicle; the number of available vehicles; and the cumulative time constraint, cumulative distance constraint, cumulative load constraint, path sequence constraint, arrival time window constraint, and / or vehicle type constraint associated with the location.

[0083] The path generation module 210 is configured to generate a path to the location (initial path), a vehicle type, a distance to the location, a time, and / or a load (e.g., a load picked up or dropped off at the location) for each of the one or more first models, and the best model selection module 208 is configured to further identify the path to the location, the vehicle type, the distance to the location, the time, and the load as those of the best model when identifying the best model. Alternatively, in step 306, the path generation module 210 may generate the path to the location, the vehicle type, the distance to the location, the time, and / or the load (e.g., a load picked up or dropped off at the location) only for the best model when selecting the best model.

[0084] In step 304, the parameter retrieval module 204 is configured to retrieve one or more parameters associated with the path characteristics, and the model validity determination module 206 is configured to determine the validity of each of the one or more first models in minimizing the path cost parameter. In one embodiment, the model validity determination module 206 is combined with the parameter retrieval module 204 and forms a part of the parameter retrieval module. According to an embodiment, the path cost parameter is at least one of load balancing cost, travel time, travel distance, vehicle usage, and cumulative load at the location.

[0085] Additionally, the path cost parameter module 212 is configured to determine a value of a path cost parameter based on one or more parameters of each of the one or more first models, wherein a high path cost parameter value indicates that the model is low in effectiveness in minimizing the path cost parameter, and the best model selection module 208 is configured to select a best model from the one or more first models based on the path cost parameter value.

[0086] Additionally, the weighted number application and calculation module 214 may be configured to apply a weighted number of values ​​of the path cost parameter of each of the one or more first models determined by the path cost parameter module 212, and the best model selection module 208 may be configured to select a best model from the one or more first models based on the weighted path cost parameter values.

[0087] In step 306 , the best model selection module 208 is configured to select one of the one or more first models based on its effectiveness, for example, the one with the highest effectiveness among all the first models, and identify it as the best model.

[0088] The model providing and generating module 202 may be configured to further generate a new model from the best model generated by the best model selecting module 208 in step 306. Then, the model validity determining module 206 determines whether the validity of the new model in minimizing the path cost parameter is greater than the validity of the best model, and the best model selecting module 208 sets / updates the new model as the new / updated best model in response to a result of determining that, for example, the validity of the new model is indeed greater than the validity of the best model in minimizing the path cost parameter.

[0089] Similarly, the path generation module 210 is configured to further generate a new path to the location, vehicle type, distance, time, and / or load to the location (e.g., a load picked up or dropped off at the location) for the new model, and the best model selection module 208 is configured to further identify the path to the location, vehicle type, distance, time, and / or load to the location as the path to the location, vehicle type, distance, time, and / or load to the location of the new best model when the second model is set as the new best model.

[0090] The position adding and removing module 222 is configured to add a new position to the path to generate a new path. If the position is one of a plurality of positions and the path connects the plurality of positions into a sequence, the position adding and removing module 222 can remove the position from the path or switch the sequence of the position and another position in the plurality of positions to generate a new path.

[0091] The model validity determination module 206 may also determine whether the validity of the new model is greater than the validity of a previously generated new model, for example, stored in a database (not shown), and the best model selection module is configured to set the new model as a new best model in response to determining that the validity of the new model is also greater than the validity of the previously generated new model. In one embodiment, the new model is one of many new models, and the model providing and generating module 202 is configured to generate the new model (i.e., one of many new models) from the best model based on the weighted number. More specifically, the new model with the highest weighted number compared to the weighted numbers of the remaining new models is identified.

[0092] The weighting number application and calculation module 214 can be configured to increase or decrease the weighting number of the new model in response to the determination result of the effectiveness of the new model. For example, if the effectiveness of the new model is greater than the best model, the weighting number of the new model is increased and / or the weighting numbers of the remaining new models in the plurality of new models are decreased, so that the model providing and generating module 202 will subsequently be more inclined to select the new model that is better than the remaining new models.

[0093] In one embodiment, the number of model determination module 218 is configured to determine whether the total number of new models generated by the model providing and generating module 202, for example, based on the best model. If the model number determination module 218 determines that the total number of new models generated does not exceed a preconfigured threshold condition, the model providing and generating module 202 is configured to continue to generate new models based on the updated best model.

[0094] Additionally or alternatively, the processing time determination module 220 is configured to determine whether the total processing time of the system 200 adaptively identifying the best model for selecting a path to the location exceeds a pre-configured threshold condition. If the processing time determination module 220 determines that the total processing time does not exceed the pre-configured threshold condition, the model providing and generating module 202 is configured to continue to generate a new model based on the updated best model.

[0095] As mentioned previously, the present disclosure provides a system (referred to herein as a vehicle path optimizer or VRO) that combines the benefits of exact (flexibility and scalability) and heuristic (scalability and performance) approaches for adaptively identifying an optimal model for selecting a path to a location, e.g. Figure 2 System 200 and Figure 1 A model recognition server in . The design of a vehicle routing optimizer that is (1) flexible and extensible, (2) adaptable, and (3) high-performance and scalable is described.

[0096] First, it is flexible in its modular nature, capable of modeling different VRP variants ranging from general capacity, time windows, pickup and delivery, multiple vehicle types, multiple warehouses, delivery priority, etc. Second, it is adaptive, as it implements multiple algorithms (each suitable for handling different constraints and requirements) and dynamically selects which algorithms to use at different stages of the optimization process. Finally, it is high-performance, as it can obtain high-quality solutions for large-scale problems in a reasonable amount of time. In this way, we obtain the benefits of both exact and heuristic methods.

[0097] Specifically, the present disclosure provides a design of a flexible, adaptive, high-performance vehicle path optimizer that is different from known path optimizers. The flexibility of the VRO in the present disclosure is achieved through vehicle path specific entity modeling. The adaptability of the VRO in the present disclosure is achieved through a general optimization framework. The high performance of the VRO in the present disclosure is achieved through the implementation of specialized data structures and algorithms. The detailed implementation of the VRO is described in the following paragraphs.

[0098] In the various embodiments below, the terms "model" and "solution" may be used interchangeably. In other words, according to the present disclosure, the best solution (i.e., the best model) is selected and identified to select a path (or optimal path) to a location. It should be noted that the terms "path constraint" and "vehicle routing problem" or "VRP" may also be used interchangeably in the following paragraphs.

[0099] In terms of flexibility, the entities involved in the vehicle routing problem are modeled in an efficient and modular way. These entities can be classified into two main categories: (1) Problem Context (2) Solution (3)

[0100] Figure 4 A flowchart 400 illustrating the relationship of entities according to an embodiment of the present disclosure is shown. The problem context entity 402 is a composite entity for storing all problem-related input data and contains sub-entities that collectively describe the path constraints or vehicle routing problem (VRP) to be solved. These sub-entities of the problem context entity 402 are nodes 406, data matrices (DataMatrix) (not shown), constraints 408, objective parameters 410, and vehicle types 404. On the other hand, the solution entity 420 is a composite entity that describes the solution (optimal model) of a given problem (output of the optimizer). The solution (optimal model) is a set of paths, each path containing a sequence of nodes to be visited by a vehicle of a specific vehicle type. The solution entity 420 includes sub-entities routes 414, visits 416, accumulators 418, and scores 422.

[0101] Each of the sub-entities is designed to follow the single responsibility principle so that they serve a single purpose in problem modeling and are easily decoupled. The sub-entities are generic and can hold different types of concrete data to represent different variations of path constraints.

[0102] The node entity 406 describes the location to be visited. It contains location data and information such as the geographic coordinates of the location (e.g., latitude and longitude coordinates), the load or combination of items to be delivered or picked up at each location (node), the constraints when visiting the location (e.g., time window), and the service time at the location (i.e., how long the vehicle will be parked at the location). Such location-related constraints may alternatively be included in the constraint entity 408.

[0103] The vehicle type entity 404 contains information about the vehicle type, such as capacity, driving distance, fuel efficiency, driving time, compatibility, initial values ​​related to the vehicle. This data will be used for accumulator calculations (e.g., total distance, total load, etc.), checked in constraints and summarized in the objective function. The constraint sub-entity and accumulator sub-entity will be described later.

[0104] The constraint entity 408 in this design is used to model the different types of constraints presented in different VRP variants. For example, for a path constraint with capacity, a capacity-related constraint 408 can be added. In another example, there can be multiple relationships between nodes - distance, time, cost - which can be described by a data matrix (not shown) and incorporated into the objective parameter entity 410 in the multi-objective optimization. These general problem scenario sub-entities gain the ability to flexibly describe different path constraint variants without the user having to change the underlying sub-entities. Instead, what the user must do is create specific sub-entities that appropriately describe the specific problem variant to be solved.

[0105] In one embodiment, constraint entity 408 contains vehicle type constraints and location (node) constraints originally contained in vehicle type entity 404 and node entity 406. In another embodiment, constraint entity 408 may contain abstract constraints to include more exotic constraints in addition to common constraints like time window, capacity, pickup-delivery, thereby increasing its path constraint diversity and the flexibility to identify different optimal models for different VRP variants.

[0106] Abstract constraints can be classified into three different types: cumulative constraints, membership constraints, and precedence constraints. Figure 5 A diagram illustrating an embodiment of the present disclosure is shown. Figure 4408 in the constraint entity 408. Abstract constraint entities include cumulative constraint entities, membership constraints, and precedence constraints. Cumulative constraint entities are used to model constraints imposed on certain cumulative quantities (e.g., time, distance, load) along the path. Common examples like time window constraints or capacity constraints fall into this category; for example, the total load of vehicles along the path should not exceed a certain number. At other times, we have constraints on the types of vehicles that can be used to serve certain customer requests. For example, some frozen items like ice cream or fish can only be delivered by vehicles with refrigerators or freezers. This type of constraint can be modeled using membership constraints in the design, specifying which customer requests can be served by which vehicle types. As for precedence constraints, it is used to constrain or limit the sequence of visiting multiple locations in the path, for example, the visit sequence of customers. Like in the pickup-delivery VRP, the item needs to be picked up before it can be delivered. Sometimes, we may also need to pick up all items before any unloading. These types of constraints can be modeled using precedence constraints. With this kind of generalization, we are able to model almost all common constraints that appear in different VRP variants.

[0107] In one implementation, the user may be a social seller or SME who handles large batches of orders. The user can complete batch uploads of orders to be delivered to multiple destinations. The batch uploaded order data is input to the optimizer (each row in the order data corresponds to a node along the path). If the user does not specify any sequence, the optimizer can simply determine the best path to perform all deliveries. If a sequence is specified in the input order data, such user requirements can be used as constraints for optimization (e.g., priority constraints). As a further option, batches can be defined before path optimization. These can be user-defined or automatically or semi-automatically determined, for example, by clustering orders according to pickup location / destination. The defined batches can be used as further constraints for optimization. In other words, the user has some ability to directly or indirectly input constraints and affect the optimization of finding the best path to meet the user requirements.

[0108] In one example, a set of factory methods are provided together in the design so that common constraints can be easily input; while for other more exotic constraints, users can still utilize the abstract constraint entity design to implement the required constraints accordingly.

[0109] The accumulator entity 418 in the solution entity 420 is implemented to perform accumulation on the accumulated quantities received from the constraint entity 408 and calculate a sum, which will be used to compare with the quantity boundary or limit to determine the feasibility of the constraint. The separation of the accumulator 418 from the constraint entity 408 allows the observation of the single responsibility design principle, and the constraint entity 408 serves a single feasibility analysis purpose. Better scalability and maintainability can be achieved with this design.

[0110] Another important aspect of VRP is the objective function used in modeling. For different VRP variants, different objective functions are used to determine path cost parameters or scores, which indicate the effectiveness of the solution in achieving the goal, for example, minimizing the effectiveness of the path cost in terms of vehicle use cost, time cost, distance cost, load / path balance cost or its combination. In order to incorporate such flexibility into the problem modeling, a target parameter entity 410 is included in the optimizer. Basically, the target parameter entity 410 is composed of different sets of weighted numbers or weight parameters for various costs (for example, path, vehicle use and path balance cost). Users can specify different weights according to their usage. For example, if the user does not wish to consider the path balance penalty when determining the score, they can simply set the associated weight parameter to zero. Multi-objective optimization can also be supported by specifying corresponding weights for each item in the objective function.

[0111] The score entity 422 simply stores the path cost parameter values ​​of the different models calculated from the parameters or data retrieved from the problem situation 402 child entity. A high path cost parameter value indicates a high path cost of the generated model path and corresponds to a low effectiveness (or feasibility) of the model in minimizing the path cost of the path. The key benefit of this implementation is that the solution entity 420 interacts closely with the problem situation entity 402, so that the flexibility of describing the problem situation entity 402 is extended to the solution entity 420. The corresponding solution algorithm will then be able to automatically consider all the different requirements described in the problem situation entity 402 without any user intervention.

[0112] The score entity 422 can also be used to compare the path cost parameter values ​​of different models and select the best model with the lowest path cost parameter value (highest effectiveness). The solution entity 420 then outputs the best model to be used in the optimization framework and subsequent iterative search process.

[0113] A key implementation is the path entity 414 and its data structure. The path entity 414 describes the (close to) optimal vehicle path, including which vehicle types to use and the sequence of nodes to visit, including the relevant cumulative metrics for each visit (e.g., time, load). The path data structure encapsulates the sequence of nodes to be visited by the vehicle. Thus, the entire solution to the VRP can be represented by a collection of paths. The implementation of the path data structure is crucial to the performance of the optimizer because the search heuristics in the optimization framework rely heavily on the manipulation of the path; the more efficiently the path can be manipulated, the more solution space can be explored given a finite amount of time, and therefore the better the final solution will be.

[0114] Figure 6 An embodiment of the present disclosure is shown. Figure 4 6. Block diagram 600 of a path entity data structure for a path entity 414 in FIG. 6. Specifically, a visit entity 416 encapsulates information about a node to be visited and a cumulative number of visits (e.g., time, distance, item, etc.) leading up to that visit. The path data structure is implemented as a doubly linked list of visit structures 604a through 604d included on the visit entity 416, with additional information about the vehicle type 602 (i.e., which vehicle type is servicing the path). A node is a demand to be visited. The path entity 414 also contains a mapping showing a sequence of nodes to be visited, which converts a node into a visit structure 606.

[0115] It should be noted that the modeling is both specialized (i.e., the entities are specific to the vehicle routing problem) and general (i.e., the entities can effectively model different requirements within the vehicle routing domain). Figure 4 This specialized but general set of entities shown in can model and solve different VRP variants with great flexibility in an efficient and modular way. Extension and modification of entities can also be easily achieved to adapt to customized VRPs.

[0116] In terms of adaptability, the design of the optimizer allows for adaptive and scalable vehicle routing optimization through an optimization framework. The internal implementation of the optimization framework is an iterative search process. The framework is designed and implemented from two perspectives: (1) Internally, the framework builds a general process for solving the VRP problem, which starts with an initial optimal solution, for example, based on the path cost parameters as described above and then selected using multiple iterations of the improvement algorithm. The framework can be adapted and extended with any algorithm that follows this process. (2) Externally, the framework provides a general interface to the end user, allowing the user to dynamically configure the algorithm.

[0117] Specifically, the constructed initial solution is feasible with respect to the path constraints derived or determined based on the input, but is usually far from optimal because only a short amount of time is available for the initial construction. Without loss of generality, multiple construction algorithms can be executed to obtain different initial solutions, and proceed to the next step with the best initial solution.

[0118] Then, given the initial solution, the optimizer iterates through different search algorithms to improve the solution. The optimizer spends most of its time iterating through these algorithms and improving the solution. Finally, after a predetermined amount of time specified by the user, the best solution found so far is finally returned to the user.

[0119] While the above is common in other vehicle routing optimizers, the optimization framework in the present invention implements multiple algorithms (called movers because they move solutions from one algorithm to another). Each mover executes a specific subroutine to explore the solution space (potentially leading to better solutions in the future) or to exploit the current solution, for example by changing parameters (e.g., vehicle type / usage, load, number of items) or adding / removing / switching locations to / from the initial path, to obtain an improved solution that selects new paths in a pre-configured manner. The selection of these movers is dynamic based on the mover's historical performance in obtaining better solutions to a given problem. Therefore, the framework exploits the no free lunch theorem of algorithms, which roughly states that no algorithm is better than all other algorithms at solving a given problem - in other words, all algorithms have their own strengths and weaknesses depending on the nature of the problem at hand (e.g., type of constraints, problem size, etc.). In addition, this adaptive selection can also transform the optimizer's behavior from exploratory at the initial stage to exploitative towards the end of the search duration. The exploration stage is crucial because it allows the optimizer to avoid getting stuck in a local optimum too early.

[0120] In other words, the optimizer is able to adaptively and dynamically select the appropriate algorithm to solve different VRP variants. This design also allows for scalability of the optimizer, as additional movers can be implemented to further enhance its capabilities. Combined with the adaptive selection feature, implementing additional movers does not deteriorate the optimizer, because if the new mover has poor performance given the problem to be solved, it will eventually not be selected in subsequent iterations.

[0121] Figure 7 A flow chart 700 illustrating a process of an iterative search process for adaptively identifying an optimal model for selecting a path to a location is shown in accordance with an embodiment of the present disclosure.

[0122] In step 702, inputs are read that contain data for entity modeling, such as problem context data, and parameters, such as the builder algorithm to be used (e.g., greedy insertion, ant colony system) and weights. In one embodiment, in this step, path characteristics are also determined based on the input. In step 704, a step of retrieving the data is performed. In step 706, construction of an initial solution (first model) is performed using one of the builder algorithms based on the path characteristics determined from the input and the VRP variant to be solved. In this way, the design of the optimizer allows for adaptive vehicle path optimization that the optimizer can solve. It is possible that multiple builder algorithms can be used to obtain multiple initial solutions (first models), and a step of selecting one of the best initial solutions for subsequent processes is performed.

[0123] With the initial best solution, the optimizer performs an iterative search process 707, in which multiple iterations are performed through different search algorithms (movement algorithms) to improve the solution. Each iteration is an improvement iteration. Finally, the best solution found so far after a predetermined amount of time specified by the user is returned and output.

[0124] Specifically, in each iteration of the iterative search process 707, step 708a of selecting a moving algorithm from the mover component 708 from a plurality of weight-based algorithms is performed, and in step 710, the moving algorithm is applied to the current solution (for the first iteration, the initial solution is the current solution) to generate a new solution. In step 712, the acceptor algorithm is applied to the new solution to determine whether to accept the solution. Without loss of generality, even when the new solution is not better than the current solution in minimizing the cost parameter, it is possible that the acceptor algorithm will accept the new solution based on other conditions in order to expand the search space.

[0125] If it is to be accepted, then step 714 is performed; otherwise, step 716 is performed. In step 714, the new solution is set as the current solution. In step 716, it is determined whether a termination condition, such as the total number of iterations (the total number of new solutions generated) or the total processing time, is met. If the termination condition is met (e.g., the total number of iterations or the total processing time exceeds a certain threshold number of iterations or threshold processing time), then step 722 is performed. If the termination condition is not met, another refinement iteration is performed using another mover component selected based on the weights or updated weights and steps 708a to 714 are repeated.

[0126] In step 718, a step of checking the new solution generated in step 710 against the best solution currently stored in a database (not shown) is performed to determine whether the new solution is better than the best solution (for the first iteration, the new solution is set as the best solution), and in step 720, the best solution is identified and selected, and the record of the best solution stored in the database is updated. The comparison can be based on their effectiveness in minimizing the path cost parameter, and the best solution is selected from the solutions with higher effectiveness in minimizing the path cost parameter. In step 722, the iteration is terminated and the best solution stored in the database set is set as the final solution. Then, the final solution is returned and output, and the process can end.

[0127] Figure 8 A flow chart illustrating a process of an adaptive large neighborhood search process for adaptively identifying an optimal model for selecting a path to a location according to an embodiment of the present disclosure is shown. In step 708a, a mover component (e.g., mover component 708) applies an adaptive large neighborhood search such that a moving algorithm is selected and applied based on a weight. Specifically, the mover component includes a plurality of moving algorithms, each of which includes parameters and an assigned weight, and is capable of receiving an initial solution as input and returning a new solution as output, such as Figure 7 In each improvement iteration, the moving algorithm is dynamically selected based on the weight, for example, the moving algorithm with the highest weight will be selected to generate a new solution from the current solution. The weight distribution of all moving algorithm candidates is dynamically updated through this adaptive large neighborhood search process.

[0128] In step 802, a current solution is generated, e.g., a coordinator algorithm or a movement algorithm implemented by a mover component 804 after an improvement iteration. The mover component 804 includes a mover selection 804a configured to select one of a plurality of movement algorithms 806a to 806c based on their weights. In step 808, a new solution (and a new path with different parameters) is generated based on the selected movement algorithm.

[0129] In step 808, the acceptor algorithm is applied to the new solution to determine whether to accept the solution. If the new solution is to be accepted, then in step 812, the new solution is set as the current solution for subsequent improvement iteration steps. In addition, the weight of the selected move algorithm will be updated. If the new solution is rejected, for example, if the effectiveness of the new solution is lower than the current solution, then in step 812, the new solution will not become an asset like the current solution, and the weight of the selected move algorithm will remain the same or decrease. Without loss of generality, even when the effectiveness of the new solution in minimizing the cost parameter is no better than the effectiveness of the current solution (e.g., simulated annealing acceptor), it is possible that the acceptor algorithm will also accept the new solution based on other conditions.

[0130] The updated weights then determine a new set of selection probabilities for the move algorithm to be selected in the next refinement iteration.Such an adaptive nature of the selection weights together with the large mover (move algorithm) library constitutes the adaptive large neighborhood search process and framework.

[0131] Externally, a generic interface is provided to dynamically receive VRO input regarding algorithm configurations (such as a list of algorithms) as well as individual weights and their parameters. Fig. 9 A flow chart 900 illustrating a vehicle path optimizer and external interface for adaptively identifying an optimal model for selecting a path to a location according to an embodiment of the present disclosure is shown. The interface defines the VRO input 904 and output 906 in a plain text format, so that the input 904 and output 908 can be converted to have other text formats, such as JSON, CSV. This further brings flexibility to the framework to adopt any other format. The VRO framework 906 performs Figure 7 or Figure 8 The operations described in .

[0132] With well-defined external interfaces, the designed optimizer can also serve as a core optimizer module in a larger routing, inventory or demand management software. The input interface can accept inputs from other data processing sources, while the output interface can provide visualization or post-optimization solutions to the ground operation team.

[0133] The design in the present disclosure also achieves high performance, meaning that it can obtain a high-quality solution (as close to the optimal solution as possible) - within reasonable time (e.g., specified by the user based on the use case) and resources (CPU and memory). This is achieved through a customized implementation of data structures and algorithms, which greatly improves the efficiency of frequently called subroutines in the mover.

[0134] Typical sequence containers of nodes have linear runtime complexity (meaning that the runtime of operations on a path increases linearly with the size of the path), while the custom data structure implemented in the present disclosure has constant runtime complexity (meaning that the runtime of path operations does not increase with the size of the path). This allows the optimizer to handle large-scale problems because the runtime of the subroutines involved does not increase with the size of the problem. In addition, the custom path data structure also encapsulates information about constraints and accumulated values ​​(e.g., time, distance, capacity) along a sequence of nodes visited with minimal overhead.

[0135] Reference Figure 6, with a custom linked list implementation, the path data 600 can be manipulated by inserting or removing visits / nodes from the visit chain / sequence, respectively. The path manipulation process can be performed. This allows the operation to have a constant O(1) runtime complexity regardless of how long the visit chain is. This speeds up the search heuristic because the search heuristic can frequently call insertion and removal operations for the path to explore different sequences of nodes to visit. The operation of changing the type of vehicle used to serve the path also has a constant O(1) runtime because it only involves changing the vehicle type information in the path.

[0136] The visit structures 604a to 604d containing information about the cumulative number of nodes to be visited can be used to check whether an insertion is potentially feasible in terms of quantity restrictions. For example, if it is determined that the weight (load) of the nodes to be visited has exceeded the weight limit of the vehicle (as stored in the vehicle type field 602), or the processing time has exceeded the threshold runtime, then there is no need to attempt to insert any further visits after this particular visit. This again helps speed up the search heuristics without actually implementing additional data structures for each heuristic.

[0137] Updating the cumulative count is also fast, since it only requires information about the node to be visited and / or the visits before and after that visit (the required count information is stored in the problem context). Whenever the state of a visit is updated, there is no need to iterate through the entire path to update the cumulative count - instead, iterating through the visits starting from the point of change is sufficient.

[0138] Finally, a map 606 that converts nodes to corresponding access structures ensures that searching for the corresponding access for a given node also has a constant O(1) runtime complexity, since there is no need to iterate through the access structures to find which access corresponds to the node of interest in a typical linked list data structure. When accesses are inserted or removed, the map is updated accordingly.

[0139] In other words, specialized data structures and algorithms tailored for paths allow the optimizer to have constant O(1) runtime complexity for path manipulation, which greatly speeds up the overall search algorithm and allows it to obtain high-quality solutions in a reasonable amount of time. This allows the optimizer to be scalable, potentially solving very large problems.

[0140] Fig. 10AA schematic diagram 1000 is shown illustrating locations corresponding to a vehicle routing problem with capacity constraints for pickup and delivery (CVRPPD) problem and an initial model (solution) for selecting a path to the locations according to an embodiment of the present disclosure. In this embodiment, there are three packages that are picked up at a warehouse represented as node 0 and delivered to different locations represented as nodes 4, 5, and 6. The location coordinates are represented by a pair of scalars in parentheses, while the load to be unloaded at the time of delivery is represented by a scalar (e.g.,

[10] ,

[20] ,

[30] ) next to its link. When identifying the best model for selecting a path, two types of vehicles with different capacities / capabilities and usage costs are input and modeled. A model can be obtained that identifies a path connecting all three locations with the minimum possible path fee / cost (e.g., vehicle usage and transportation (travel time) cost) for dispatching vehicles to deliver the packages, while observing the capacity and pickup delivery constraints and constantly checking the cumulative load / time / distance of the vehicles to see if it exceeds a cumulative threshold.

[0141] For example, a possible initial solution (construction algorithm) is identified that assigns each node to a vehicle, so three paths are selected (path 1, path 2, path 3). In path 1, vehicle 1 (not shown) is assigned to access node 6; in path 2, vehicle 2 (not shown) is assigned to access node 5; and vehicle 3 (not shown) is assigned to access node 4. With this solution, the path cost parameter in terms of the total load of each vehicle is within its corresponding vehicle capacity, but the path cost parameter in terms of the total distance traveled by all vehicles is 25 (6+10+9=25).

[0142] The path can be further improved using the mover algorithm (improvement iterations), for example by removing node 4 from path 3 and inserting node 4 into path 2. Fig. 10B The diagram shows the diagram Fig. 10A1010 of an improved solution for selecting a path to a location in FIG. By removing node 4 and therefore removing path 3 and adding node 4 to path 2, there will be two paths. Path 1 remains unchanged and vehicle 1 is assigned to visit node 6 in path 1; while in path 2, vehicle 2 is now assigned to visit node 4 and then visit node 5. The node visit sequence in path 2 is selected so that the path cost parameter in terms of the distance traveled in the path is smaller. Specifically, if the visit sequence is node 5 followed by node 4, the distance traveled in the path is 13 (10+3=13); but if the visit sequence is node 4 followed by node 5, the distance traveled in the path becomes 12 (9+3). With this improved solution, the path cost parameter in terms of the total load of each vehicle is still within its corresponding vehicle capacity (unchanged), but the path cost parameter in terms of the total distance traveled by all vehicles is now 18 (6+12) and in addition the path cost parameter in terms of the number of vehicles is lower. Compared to the initial model, the improved solution minimizes the path cost parameter and selects better paths to the locations which are more efficient because the total distance is smaller (and also uses fewer vehicles), while still satisfying all requirements and constraints.

[0143] Fig.11 An exemplary implementation of a vehicle path optimizer according to an embodiment of the present disclosure is shown. The implementation first starts with preparing an input data file 1102, which includes raw input data (such as node-related data (node ​​index, location coordinates, load, etc.)), vehicle type data (type index, number of available vehicles, capacity, etc.), data matrix (ETA / distance matrix), constraints (time accumulation constraints, load accumulation constraints, and pickup-delivery priority constraints), and target parameters (weighted numbers of vehicle usage and travel time costs in the target function). Fig.12 A sample format of an input data file 1102 provided to users is shown so that they can simply input or modify data according to corresponding usage scenarios.

[0144] Once the input data file 1102 is ready, the user can use the input file with the C++ binary file in the command line tool or the API provided by the optimizer user interface 1104. Thereafter, the input file will be processed and parsed to obtain the problem context and parameter data required inside the optimizer 1106. With this data, the optimizer 1106 will perform calculations with the specified solution algorithm to identify the best model for selecting a path and solving the above problem, and return the best model (final solution) together with performance indicators (e.g., score, path cost parameters, effectiveness of minimizing path cost parameters) in the output solution file 1108.

[0145] If additional time windows are imposed on the above package delivery, meaning that the package should be delivered within certain feasible time windows specified by the customer, then the time window constraints can be added when modeling with constraint entities. The problem then becomes a pickup and delivery capacity-constrained VRP with time windows (CVRPPDTW) problem. After including the time window constraints, the implementation flow remains the same, which demonstrates the flexibility of the current design to solve different VRP variants. Table 1 illustrates an example source of input data.

[0146] Table 1. Example input data and sources

[0147]

[0148] Fig.13 An exemplary interface layer for a system implementation for adaptively identifying an optimal model for selecting a path to a location according to an embodiment of the present disclosure is shown. A flexible infrastructure is designed and implemented for the high-performance vehicle path optimizer. The infrastructure includes three different interface layers 1304, 1306, 1308.

[0149] The first interface layer is a native REPL (read-evaluate-print loop) 1304 that can be deployed on the end-user environment. It is using the native programming language interface to provide user input 1302 (or Fig.12 Direct interaction between 1102 in the example and the optimizer 1316. Fig.14 A sample of a native read-evaluate-print loop (REPL) interface according to an embodiment of the present disclosure is shown. The end user executes the native interface called VRO (Vehicle Path Optimizer) and obtains the solution results directly on the console.

[0150] The second interface layer is the synchronous HTTP interface 1306, through which the user sends the problem situation (such as Fig.12 1306) is sent to an HTTP server. This layer 1306 supports limited input size and limited solution time because HTTP communication may have timeout restrictions between the end user and the interface. For example, a limit of 100 nodes of input size and a limited solution time of 5 seconds will be applied on the interface.

[0151] The third interface layer is an asynchronous on-demand cloud service 1308, where the user will input the file 1302 (or Fig.121102 in the example) is submitted as a job request to the cloud service 1308. Service 1308 will process the user input and store the input in a job list / database 1310. Scheduler 1314 will schedule a predefined time to obtain input file 1302 from job list 1310 and solve the problem using one or more job processors (e.g., processor 1312). The interface supports larger input sizes and longer solution times. For example, the input size can be increased to more than 1000 nodes and the solution time can be increased to more than 30 seconds. In this high-performance vehicle routing optimizer infrastructure design, each layer can be easily turned on and off, and even packaged separately. This provides flexibility and scalability for infrastructure implementation.

[0152] Fig.15 Shows that it can be practiced on Figure 1 Schematic diagram of a general computer system 1500 of the coordination server 108. The computer system 1500 includes: a computer module 1501, input devices (such as a keyboard 1502, a mouse pointer device 1503, a scanner 1526, a camera 1527, and a microphone 1580); and output devices (including a printer 1515, a display device 1514, and a speaker 1517). An external modulator-demodulator (modem) transceiver device 1516 can be used by the computer module 1501 to communicate to and from a communication network 1520 via a connection 1521. The communication network 1520 can be a wide area network (WAN) such as the Internet, a cellular telecommunications network, or a dedicated WAN. In the case where the connection 1521 is a telephone line, the modem 1516 can be a traditional "dial-up" modem. Alternatively, in the case where the connection 1521 is a high-capacity (e.g., cable) connection, the modem 1516 can be a broadband modem. A wireless modem can also be used for wireless connection to the communication network 1520.

[0153] The input and output devices may be used by an operator who is interacting with the coordination server 108. For example, the printer 1515 may be used to print reports related to the status of the coordination server 108.

[0154] The coordination server 108 communicates with the provider device 104, the requester device 102, the model recognition server 112, and the database 188 using the communication network 1520 to receive commands and data. The coordination server 108 also communicates with the provider device 104, the requester device 102, the model recognition server 112, and the database 188 using the communication network 1520 to send notification messages or transaction / location / route / vehicle / model data.

[0155] The computer module 1501 typically includes at least one processor unit 1505 and at least one memory unit 1506. For example, the memory unit 1506 may have a semiconductor random access memory (RAM) and a semiconductor read-only memory (ROM). The computer module 1501 also includes a plurality of input / output (I / O) interfaces, including: an audio-video interface 1507 coupled to a video display 1514, a speaker 1517, and a microphone 1580; an I / O interface 1513 coupled to a keyboard 1502, a mouse 1503, a scanner 1526, a camera 1527, and an optional joystick or other human interface device (not shown); and an interface 1508 for an external modem 1516 and a printer 1515. In some implementations, the modem 1516 may be incorporated into the computer module 1501, for example, into the interface 1508. The computer module 1501 also has a local network interface 1511 which allows the computer system 1500 to be coupled to a local area communications network 1522, known as a local area network (LAN), via connection 223. Fig. 9 As shown in FIG. 1 , the local communication network 1522 may also be coupled to the wide area network 1520 via connection 1524, which typically includes a so-called "firewall" device or a device with similar functions. The local network interface 1511 may include an Ethernet circuit card, wireless device or IEEE 1502.11 wireless device; however, for interface 1511, various other types of interfaces may be practiced.

[0156] I / O interfaces 1508 and 1513 may provide either or both serial and parallel connections, the former typically being implemented in accordance with the Universal Serial Bus (USB) standard and having a corresponding USB connector (not shown). Storage device 1509 is provided and typically includes a hard disk drive (HDD) 1510. Other storage devices such as floppy disk drives and tape drives (not shown) may also be used. An optical disk drive 1512 is typically provided to act as a source of non-volatile data. For example, a portable storage device such as an optical disk (e.g., CD-ROM, DVD, Blu-ray Disc) TM ), USB-RAM, portable external hard drive and floppy disk) can be used as appropriate data sources for the coordination server 108.

[0157] The components 1505 to 1513 of the computer module 1501 typically communicate via an interconnection bus 1504 and in a manner that results in a conventional mode of operation of a computer system known to those skilled in the relevant art. For example, the processor 1505 is coupled to the system bus 1504 using connection 1518. Similarly, the memory 1506 and the optical drive 1512 are coupled to the system bus 1504 via connection 1519. Examples of computers on which the described apparatus can be practiced include IBM-PC and compatible machines, Sun Sparcstation, Apple Mac TM or similar computer system.

[0158] like Figure 3 , Figures 6 to 9 and Fig.11 The operation method of the coordination server 108 shown in the process can be implemented as one or more software applications 1533 executable within the coordination server 108. Specifically, Figure 3 , Figures 6 to 9 and Fig.11 The steps of the process shown in FIG. 1 are performed by instructions 1531 in software (ie, computer program code) 1533 executed within the coordination server 108 (see Fig.16 ) is implemented. The software instructions 1531 can be formed into one or more code modules, each of which is used to perform one or more specific tasks. The software can also be divided into two separate parts, where the first part and the corresponding code modules perform the operation of the coordination server 108, and the second part and the corresponding code modules manage the API and corresponding user interface in the provider device 104, the requester device 102 and on the display 1514. In other words, the second part of the software manages the interaction between (a) the first part and (b) any one of the operators of the provider device 104, the requester device 102 and the server 108.

[0159] The software may be stored in a computer readable medium, including, for example, a storage device as described below. The software is loaded from the computer readable medium into the coordination server 108 and then executed by the computer system 1500. A computer readable medium having such software or a computer program recorded on a computer readable medium is a computer program product. The use of a computer program product in the coordination server 108 preferably implements an advantageous device for receiving / sending data, including position data, vehicle data, path data, model data, path constraint data (or data and parameters input to the problem situation entity 404) and / or transaction data for the adaptive best model identification and path selection / generation process performed by the model identification server 112.

[0160] The software (i.e., computer program code) 1533 is typically stored in the HDD 1510 or the memory 1506. The software 1533 is loaded into the computer system 1500 from a computer readable medium (e.g., the memory 1506) and executed by the processor 1505. Thus, for example, the software 1533 may be stored on an optically readable disk storage medium (e.g., a CD-ROM) 1525 read by the optical disk drive 1512. A computer readable medium having such software or a computer program recorded on a computer readable medium is a computer program product. The use of a computer program product in the coordination server 108 preferably implements a device for receiving / sending data, which includes position data, vehicle data, path data, model data, path constraint data (or data and parameters input to the problem situation entity 404) and / or transaction data for the adaptive best model identification and path selection / generation process performed by the model identification server 112.

[0161] In some examples, the application 1533 encoded on one or more CD-ROMs 1525 can be supplied to the user and read via the corresponding drive 1512, or alternatively, can be read by the user from the network 1520 or 1522. Further, the software can also be loaded into the coordination server 108 from other computer-readable media. A computer-readable storage medium is any non-transitory tangible storage medium that provides recorded instructions and / or data to the coordination server 108 for execution and / or processing by the processor 1505. Examples of such storage media include floppy disks, magnetic tapes, CD-ROMs, DVDs, Blu-ray disks, and the like. TM The computer module 1501 may be a computer-readable medium such as a disk, a hard disk drive, a ROM or integrated circuit, a USB memory, a magneto-optical disk, or a computer-readable card (such as a PCMCIA card), etc., whether such a device is internal or external to the computer module 1501. Examples of transient or non-tangible computer-readable transmission media that may also be involved in providing software, applications, instructions and / or data to the computer module 1501 include radio or infrared transmission channels and network connections to another computer or networked device, as well as the Internet or Intranet including electronic mail transmissions and information recorded on websites, etc.

[0162] The second portion of the application 1533 and the corresponding code modules mentioned above can be executed to implement one or more APIs of the coordination server 108 and an associated graphical user interface (GUI) to be presented or otherwise represented on the display 1514 or the display of the provider device 104 and the requester device 102. Through the usual manipulation of the keyboard 1502 and the mouse 1503, the operator and the application of the server 110 can manipulate the interface in a functionally adaptable manner to provide control commands and / or input to the application associated with the GUI. Similarly, on the provider device 104 and the requester device 102, the user of those devices 102, 104 manipulates the input devices (e.g., touch screen, keyboard, mouse, etc.) of those devices 102, 104 in a functionally adaptable manner to provide control commands and / or input to the application associated with the GUI. Other forms of functionally adaptable user interfaces can also be implemented, such as audio interfaces that utilize voice prompts output via the speaker 1517 and user voice commands input via the microphone 1580. These other forms of functionally adaptable user interfaces may also be implemented on the provider device 104 and the requester device 102 .

[0163] Fig.16 is a detailed schematic block diagram of the processor 1505 and the "memory" 1534. The memory 1534 represents the memory that can be used by Fig.15 A logical collection of all memory modules (including HDD 1509 and semiconductor memory 1506) accessed by the computer module 1501 in.

[0164] When the computer module 1501 is initially powered on, a power-on self-test (POST) program 1550 is executed. The POST program 1550 is typically stored in Fig.15 1549 of semiconductor memory 1506. Hardware devices that store software, such as ROM 1549, are sometimes referred to as firmware. POST program 1550 checks the hardware within computer module 1501 to ensure proper operation, and typically checks processor 1505, memory 1534 (609, 1506), and a basic input-output system software (BIOS) module 1551, which is also typically stored in ROM 1549, for proper operation. Once POST program 1550 runs successfully, BIOS 1551 activates Fig.161505. Activation of the hard disk drive 1510 causes the boot loader 1552 resident on the hard disk drive 1510 to be executed via the processor 1505. This loads the operating system 1553 into the RAM memory 1506, on which the operating system 1553 begins to operate. The operating system 1553 is a system-level application executable by the processor 1505 to implement various high-level functions including processor management, memory management, device management, storage management, software application interface, and general user interface.

[0165] The operating system 1553 manages the memory 1534 (609, 1506) to ensure that each process or application running on the computer module 1501 has enough memory to execute without conflicting with the memory allocated to another process. Fig.15 The different types of memory available in the server 108 must be used correctly so that each process can run efficiently. Therefore, the aggregate memory 1534 is not intended to illustrate how specific segments of memory are allocated (unless otherwise specified), but rather to provide an overall view of the memory accessible to the server 108 and how it is used.

[0166] like Fig.16 As shown in , the processor 1505 includes multiple functional modules, including a control unit 1539, an arithmetic logic unit (ALU) 1540, and a local or internal memory 1548 (sometimes referred to as a cache memory). The cache memory 1548 typically includes a plurality of storage registers 1544 to 1546 in a register section. One or more internal buses 1541 functionally interconnect these functional modules. The processor 1505 also typically has one or more interfaces 1542 for communicating with external devices via the system bus 1504 using a connection 1518. The memory 1534 is coupled to the bus 1504 using a connection 1519.

[0167] The application 1533 includes an instruction sequence 1531, which may include conditional branching and looping instructions. The program 1533 may also include data 1532 used in the execution of the program 233. The instructions 1531 and the data 1532 are stored in memory locations 1528, 1529, 1530 and 1535, 1536, 1537, respectively. Depending on the relative size of the instructions 1531 and the memory locations 1528 to 1530, a specific instruction may be stored in a single memory location, as depicted by the instruction shown in memory location 1530. Alternatively, the instruction may be split into multiple parts, each of which is stored in a separate memory location, as depicted by the instruction segments shown in memory locations 1528 and 1529.

[0168] Generally, processor 1505 is given a set of instructions to execute therein. Processor 1505 waits for subsequent inputs, to which processor 1505 reacts by executing another set of instructions. Each input may be from a set of instructions including all of the Fig.15 1502, 1503, received from an external source via one of the networks 1520, 1502, retrieved from one of the storage devices 1506, 1509, or retrieved from a storage medium 1525 inserted into a corresponding reader 1512. In some cases, execution of the set of instructions may result in the output of data. Execution may also involve storing data or variables to memory 1534.

[0169] The disclosed association management and payment initiation apparatus uses input variables 1554, which are stored in corresponding memory locations 1555, 1556, 1557 in memory 1534. The association management and payment initiation apparatus generates output variables 1561, which are stored in corresponding memory locations 1562, 1563, 1564 in memory 1534. Intermediate variables 258 may be stored in memory locations 1559, 1560, 1566, and 1567.

[0170] Reference Fig.15 The processor 1505, registers 1544, 1545, 1546, arithmetic logic unit (ALU) 1540, and control unit 1539 work together to perform the sequence of micro-operations required to perform a "fetch, decode, and execute" cycle for each instruction in the instruction set that makes up the program 1533. Each fetch, decode, and execute cycle includes: a fetch operation to fetch or read an instruction 1531 from a memory location 1528, 1529, 1530; a decode operation to determine which instruction has been fetched by the control unit 1539; and an execute operation to execute the instruction by the control unit 1539 and / or ALU 1540.

[0171] Thereafter, a further fetch, decode and execute cycle of the next instruction may be performed.Similarly, a store cycle may be performed by which the control unit 1539 stores or writes a value to the memory location 1532.

[0172] Figure 3 , Figures 6 to 9 and Fig.11 Each step or sub-process in the process is associated with one or more sections of program 1533 and is performed by register sections 1544, 1545, 1547, ALU 1540 and control unit 1539 in the processor 1505 that work together to perform a fetch, decode and execute loop for each instruction in the instruction set in the said section of program 1533.

[0173] It should be understood that the structural scenario of the coordination server 108 is presented by way of example only. Therefore, in some arrangements, one or more features of the coordination server 108 may be omitted. In addition, in some arrangements, one or more features of the coordination server 108 may be combined. In addition, in some arrangements, one or more features of the coordination server 108 may be split into one or more components.

[0174] Fig.17 Shown is the method for implementing Figure 1 1702 and 1704. The coordination server 108 is an alternative computer device (i.e., computer system 1500) of the coordination server 108. In an alternative implementation, the coordination server 108 can be generally described as a physical device including at least one processor 1702 and at least one memory 1704 including computer program code. The at least one memory 1704 and the computer program code are configured to work with the at least one processor 1702 to enable the coordination server 108 to facilitate Figure 3 , Figures 6 to 9 and Fig.11 The coordination server 108 may also include a coordination module 1706. The memory 1704 stores computer program codes compiled by the processor 1702 to enable each of the modules to perform its corresponding functions.

[0175] refer to Figure 1 , the coordination module 1706 performs the function of communicating with the requester device 102 and the provider device 104; and the acquirer server 106 and the issuer server 110 are used to receive and send transaction and location / route / vehicle / model data respectively. In addition, the coordination module 1706 can provide data and information such as location data, vehicle data, route data, model data, route constraint data (or data and parameters input to the problem situation entity 404) and transaction data for the adaptive optimal model identification and route selection / generation process performed by the model identification server 112.

[0176] Fig.18 Shows that it can be practiced on Figure 1Schematic diagram of a general computer system 1800 of the model recognition server 112 of FIG. The computer system 1800 includes: a computer module 1801, input devices such as a keyboard 1802, a mouse pointer device 1803, a scanner 1826, a camera 1827, and a microphone 1880; and output devices including a printer 1815, a display device 1814, and a speaker 1817. An external modulator-demodulator (modem) transceiver device 1816 can be used by the computer module 1801 to communicate to and from a communication network 1820 via a connection 1821. The communication network 1820 can be a wide area network (WAN), such as the Internet, a cellular telecommunications network, or a dedicated WAN. In the case where the connection 1821 is a telephone line, the modem 1816 can be a traditional "dial-up" modem. Alternatively, in the case where the connection 1821 is a high-capacity (e.g., cable) connection, the modem 1813 can be a broadband modem. A wireless modem can also be used for wireless connection to the communication network 1820.

[0177] The input and output devices may be used by an operator interacting with the pattern recognition server 112. For example, the printer 1815 may be used to print reports related to the status of the pattern recognition server 112.

[0178] The model recognition server 112 communicates with the provider device 104, the requester device 102, the coordination server 108, and the model recognition database 113 using the communication network 1820 to receive commands and data. The model recognition server 112 also communicates with the provider device 104, the requester device 102, the model recognition server 112, and the database 188 using the communication network 1820 to send notification messages or transaction / location / route / vehicle / model data.

[0179] The computer module 1801 typically includes at least one processor unit 1805 and at least one memory unit 1806. For example, the memory unit 1806 may have a semiconductor random access memory (RAM) and a semiconductor read-only memory (ROM). The computer module 1801 also includes a plurality of input / output (I / O) interfaces, including: an audio-video interface 1807 coupled to a video display 1814, a speaker 1817, and a microphone 1880; an I / O interface 1813 coupled to a keyboard 1802, a mouse 1803, a scanner 1826, a camera 1827, and an optional joystick or other human interface device (not shown); and an interface 1808 for an external modem 1816 and a printer 1815. In some implementations, the modem 1816 may be incorporated into the computer module 1801, such as into the interface 1808. The computer module 1801 also has a local network interface 1811 that allows the computer system 1800 to be coupled to a local area communication network 1822, known as a local area network (LAN), via a connection 1823. Fig.18 As shown in FIG. 1 , the local communication network 1822 may also be coupled to the wide area network 1820 via a connection 1824, which typically includes a so-called "firewall" device or a device with similar functions. The local network interface 1811 may include an Ethernet circuit card, wireless device or IEEE 802.11 wireless device; however, various other types of interfaces may be employed for interface 1811.

[0180] I / O interfaces 1808 and 1813 may provide either or both serial and parallel connections, the former typically being implemented in accordance with the Universal Serial Bus (USB) standard and having a corresponding USB connector (not shown). Storage device 1809 is provided and typically includes a hard disk drive (HDD) 1810. Other storage devices such as floppy disk drives and tape drives (not shown) may also be used. An optical disk drive 1812 is typically provided to act as a source of non-volatile data. For example, a portable storage device (such as an optical disk (e.g., CD-ROM, DVD, Blu-ray Disc) TM ), USB-RAM, portable external hard drive and floppy disk) can be used as appropriate data sources for the model recognition server 112.

[0181] The components 1805 to 1813 of the computer module 1801 typically communicate via an interconnection bus 1804 and in a manner that results in conventional operating modes of computer systems known to those skilled in the relevant art. For example, the processor 1805 is coupled to the system bus 1804 using connection 1818. Similarly, the memory 1806 and the optical drive 1812 are coupled to the system bus 1804 via connection 1819. Examples of computers on which the described apparatus can be practiced include IBM-PC and compatible machines, Sun Sparcstation, Apple Macintosh, and the like. TM or similar computer system.

[0182] like Figure 3 , Figures 6 to 9 and Fig.11 The operation method of the model recognition server 112 shown in the process can be implemented as one or more software applications 1833 executable within the model recognition server 112. Specifically, Figure 3 , Figures 6 to 9 and Fig.11 The steps of the process shown in FIG. 1 are performed by instructions in software (ie, computer program code) 1833 executed within the model recognition server 112 (see Fig.16 The software instructions 1531 may be implemented as one or more code modules, each of which is used to perform one or more specific tasks. The software may also be divided into two separate parts, wherein the first part and the corresponding code modules perform the operation of the model recognition server 112, and the second part and the corresponding code modules manage the API and the corresponding user interface in the provider device 104, the requester device 102 and on the display 1814. In other words, the second part of the software manages the interaction between (a) the first part and (b) any one of the operators of the provider device 104, the requester device 102 and the server 112.

[0183] The software may be stored in a computer readable medium, including, for example, a storage device described below. The software is loaded from the computer readable medium into the model recognition server 112 and then executed by the computer system 1800. A computer readable medium having such software or a computer program recorded on a computer readable medium is a computer program product. The use of a computer program product in the model recognition server 112 preferably implements an advantageous apparatus for adaptively identifying an optimal model to select a path to a location.

[0184] The software (i.e., computer program code) 1833 is typically stored in the HDD 1810 or the memory 1806. The software 1833 is loaded into the computer system 1800 from a computer readable medium (e.g., the memory 1806) and executed by the processor 1805. Thus, for example, the software 1833 may be stored on an optically readable disk storage medium (e.g., a CD-ROM) 1825 read by the optical disk drive 1812. A computer readable medium having such software or a computer program recorded on a computer readable medium is a computer program product. The use of a computer program product in the model recognition server 112 preferably implements an advantageous device for adaptively identifying an optimal model to select a path to a location.

[0185] In some examples, the application 1833 may be encoded on one or more CD-ROMs 1825 and supplied to the user and read via a corresponding drive 1812, or alternatively, may be read by the user from a network 1820 or 1822. Further, the software may also be loaded into the model recognition server 112 from other computer-readable media. A computer-readable storage medium is any non-transitory tangible storage medium that provides recorded instructions and / or data to the model recognition server 112 for execution and / or processing by the processor 1805. Examples of such storage media include floppy disks, magnetic tapes, CD-ROMs, DVDs, Blu-rays, and the like. TM The computer module 1801 may be a computer program product, such as a disk, a hard disk drive, a ROM or integrated circuit, a USB memory, a magneto-optical disk, or a computer readable card (such as a PCMCIA card), etc., whether such a device is internal or external to the computer module 1801. Examples of transient or non-tangible computer-readable transmission media that may also be involved in providing software, applications, instructions and / or data to the computer module 1801 include radio or infrared transmission channels and network connections to another computer or networked device, as well as the Internet or an intranet including electronic mail transmissions and information recorded on websites, etc.

[0186] The second portion of the application 1833 and the corresponding code modules mentioned above can be executed to implement one or more APIs of the model recognition server 112 and an associated graphical user interface (GUI) to be presented or otherwise represented on the display 1814 or the display of the provider device 104 and the requester device 102. Through the usual manipulation of the keyboard 1802 and the mouse 1803, the operator and the application of the server 112 can manipulate the interface in a functionally adaptable manner to provide control commands and / or input to the application associated with the GUI. Similarly, on the provider device 104 and the requester device 102, the user of those devices 102, 104 manipulates the input devices (e.g., touch screen, keyboard, mouse, etc.) of those devices 102, 104 in a functionally adaptable manner to provide control commands and / or input to the application associated with the GUI. Other forms of functionally adaptable user interfaces can also be implemented, such as audio interfaces that utilize voice prompts output via the speaker 1817 and user voice commands input via the microphone 680. These other forms of functionally adaptable user interfaces may also be implemented on the provider device 104 and the requester device 102 .

[0187] It should be understood that the structural scenario of the coordination server 108 is presented by way of example only. Therefore, in some arrangements, one or more features of the coordination server 108 may be omitted. In addition, in some arrangements, one or more features of the model recognition server 112 may be combined. In addition, in some arrangements, one or more features of the model recognition server 112 may be split into one or more components.

[0188] Fig.19 Shown is the method for implementing Figure 1 In an alternative implementation, the model recognition server 112 can be generally described as a physical device including at least one processor 1302 and at least one memory 1904 including computer program code. The at least one memory 1904 and the computer program code are configured to work with the at least one processor 1902 to perform a Figure 1 The model recognition server 112 executes Figure 3 , Figures 6 to 9 and Fig.11 The model recognition server 112 may include Figure 2 The various modules 202 to 222 of the system 200 are described in detail. The memory 1904 stores computer program code compiled by the processor 1902 to enable each of the modules 202 to 222 to perform its corresponding function, such as Figure 2 and as described in the accompanying description.

[0189] The model recognition server 112 may also include a data module 1906 configured to execute the requesting device 102, the providing device 104, the coordination server 108, the cloud, and the Figure 3 , Figures 6 to 9 and Fig.11 The data module 1906 may be configured to receive data from other information sources of the process, the data including location data, vehicle data, path data, model data, path constraint data (or data and parameters input to the problem situation entity 404), and / or transaction data. For example, the data module 1906 may be configured to receive a request including data from a user device (such as the requester device 112 or the provider device 114), the data including location data, vehicle data, path data, model data, path constraint data (or data and parameters input to the problem situation entity 404), and / or transaction data for use by the coordination server 108 in the adaptive model identification and path selection / generation process.

[0190] Fig. 20 Shows that it can be practiced on Figure 1 Schematic diagram of a general computer system of a combined coordination and model recognition server 108, 112. The computer system 2000 includes: a computer module 2001, input devices such as a keyboard 2002, a mouse pointer device 2003, a scanner 2026, a camera 2027 and a microphone 2080; and output devices including a printer 2015, a display device 2014 and a speaker 2017. An external modulator-demodulator (modem) transceiver device 2016 can be used by the computer module 2001 to communicate to and from a communication network 2020 via a connection 2021. The communication network 2020 can be a wide area network (WAN), such as the Internet, a cellular telecommunications network, or a dedicated WAN. In the case where the connection 2021 is a telephone line, the modem 2016 can be a traditional "dial-up" modem. Alternatively, in the case where the connection 2021 is a high-capacity (e.g., cable) connection, the modem 2013 can be a broadband modem. A wireless modem can also be used for wireless connection to the communication network 1820.

[0191] The input and output devices may be used by an operator who is interacting with the combined coordination and model recognition server 108, 112. For example, the printer 2015 may be used to print reports related to the status of the combined coordination and model recognition server 108, 112.

[0192] The combined coordination and model recognition servers 108, 112 communicate with the provider device 104, the requester device 102, and the databases 109, 113 using the communication network 2020 to receive commands and data. In one example, the databases 109, 113 may be combined, such as Fig. 20The combined coordination and model recognition servers 108, 112 also communicate with the provider device 104, the requester device 102 and the databases 109, 113 using the communication network 2020 to send notification messages or transaction / location / route / vehicle / model data.

[0193] The computer module 2001 generally includes at least one processor unit 2005 and at least one memory unit 2006. For example, the memory unit 2006 may have a semiconductor random access memory (RAM) and a semiconductor read-only memory (ROM). The computer module 2001 also includes a plurality of input / output (I / O) interfaces, including: an audio-video interface 2007 coupled to a video display 2014, a speaker 2017, and a microphone 2080; an I / O interface 2013 coupled to a keyboard 2002, a mouse 2003, a scanner 2026, a camera 2027, and an optional joystick or other human interface device (not shown); and an interface 2008 for an external modem 2016 and a printer 2015. In some implementations, the modem 2016 may be incorporated into the computer module 2001, for example, into the interface 2008. The computer module 2001 also has a local network interface 2011 which allows the computer system 2000 to be coupled to a local area communication network 2022, known as a local area network (LAN), via a connection 223. Fig. 20 As shown in FIG. 2 , the local communication network 2022 may also be coupled to the wide area network 2020 via a connection 2024, which typically includes a so-called "firewall" device or a device with similar functions. The local network interface 2011 may include an Ethernet circuit card, wireless device or IEEE 802.11 wireless device; however, for interface 2011, various other types of interfaces may be practiced.

[0194] I / O interfaces 2008 and 2013 may provide either or both serial and parallel connections, the former typically being implemented in accordance with the Universal Serial Bus (USB) standard and having a corresponding USB connector (not shown). Storage device 2009 is provided and typically includes a hard disk drive (HDD) 2010. Other storage devices such as floppy disk drives and tape drives (not shown) may also be used. An optical disk drive 2012 is typically provided to act as a source of non-volatile data. For example, a portable storage device (such as an optical disk (e.g., CD-ROM, DVD, Blu-ray Disc) TM ), USB-RAM, portable external hard drive and floppy disk) can be used as appropriate data sources for the combined coordination and model recognition servers 108, 112.

[0195] The components 2005 to 2013 of the computer module 2001 typically communicate via an interconnection bus 2004 and in a manner that results in a conventional mode of operation of a computer system known to those skilled in the relevant art. For example, the processor 2005 is coupled to the system bus 2004 using connection 2018. Similarly, the memory 2006 and the optical drive 2012 are coupled to the system bus 2004 via connection 2019. Examples of computers on which the described apparatus may be practiced include IBM-PC and compatible machines, Sun Sparcstation, Apple Mac TM or similar computer system.

[0196] like Figure 2 and Figures 5 to 7 The method of operation of the combined coordination and model recognition server 108, 112 shown in the process can be implemented as one or more software applications 2033 executable within the combined coordination and model recognition server 108, 112. Specifically, Figure 2 and Figures 5 to 7 The steps of the process shown in FIG. 1 are performed by instructions in software (ie, computer program code) 2033 executed within the combined coordination and model identification server 108, 112 (see Fig.15 The software instructions 1531 may be implemented as one or more code modules, each of which is used to perform one or more specific tasks. The software may also be divided into two separate parts, wherein the first part and the corresponding code modules perform the operations of the combined coordination and model recognition servers 108, 112, and the second part and the corresponding code modules manage the APIs and corresponding user interfaces in the provider device 104, the requester device 102 and on the display 2014. In other words, the second part of the software manages the interaction between (a) the first part and (b) any one of the operators of the provider device 104, the requester device 102 and the server 112.

[0197] The software may be stored in a computer readable medium, including, for example, a storage device as described below. The software is loaded from the computer readable medium into the combined coordination and model identification server 108, 112 and then executed by the computer system 2000. A computer readable medium having such software or a computer program recorded on a computer readable medium is a computer program product. The use of the computer program product in the combined coordination and model identification server 108, 112 preferably implements an advantageous device for adaptively identifying an optimal model for selecting a path to a location and for receiving / sending data, including location data, vehicle data, path data, model data, path constraint data (or data and parameters input to the problem situation entity 404) and / or transaction data for the adaptive optimal model identification and path selection / generation process performed by the model identification server 112.

[0198] The software (i.e., computer program code) 2033 is typically stored in the HDD 2010 or the memory 2006. The software 2033 is loaded into the computer system 2000 from a computer readable medium (e.g., the memory 2006) and executed by the processor 2005. Thus, for example, the software 2033 may be stored on an optically readable disk storage medium (e.g., a CD-ROM) 2025 read by the optical disk drive 2012. A computer readable medium having such software or a computer program recorded on a computer readable medium is a computer program product. The use of a computer program product in the combined coordination and model identification servers 108, 112 preferably implements an advantageous device for adaptively identifying an optimal model for selecting a path to a location and for receiving / sending data, the data including location data, vehicle data, path data, model data, path constraint data (or data and parameters input to the problem situation entity 404) and / or transaction data for adaptive optimal model identification and path selection / generation processes.

[0199] In some examples, the application 2033 may be encoded on one or more CD-ROMs 2025 and supplied to the user and read via a corresponding drive 2012, or alternatively, may be read by the user from a network 2020 or 222. Further, the software may also be loaded into the combined coordination and model recognition server 108, 112 from other computer-readable media. A computer-readable storage medium is any non-transitory tangible storage medium that provides recorded instructions and / or data to the combined coordination and model recognition server 108, 112 for execution and / or processing by the processor 2005. Examples of such storage media include floppy disks, magnetic tapes, CD-ROMs, DVDs, Blu-rays, and the like. TMThe computer module 2001 may be a computer program product, such as a disk, a hard disk drive, a ROM or integrated circuit, a USB memory, a magneto-optical disk, or a computer readable card (such as a PCMCIA card), etc., whether such a device is internal or external to the computer module 2001. Examples of temporary or non-tangible computer-readable transmission media that may also be involved in providing software, applications, instructions and / or data to the computer module 2001 include radio or infrared transmission channels and network connections to another computer or networked device, as well as the Internet or an intranet including electronic mail transmissions and information recorded on websites, etc.

[0200] The second portion of the application 2033 and the corresponding code modules mentioned above can be executed to implement one or more APIs of the combined coordination and model recognition server 108, 112 and an associated graphical user interface (GUI) to be presented or otherwise represented on the display 2014 or the display of the provider device 104 and the requester device 102. Through the usual manipulation of the keyboard 2002 and the mouse 2003, the operator of the server 112 and the application can manipulate the interface in a functionally adaptable manner to provide control commands and / or input to the application associated with the GUI. Similarly, on the provider device 104 and the requester device 102, the user of those devices 102, 104 manipulates the input devices (e.g., touch screen, keyboard, mouse, etc.) of those devices 102, 104 in a functionally adaptable manner to provide control commands and / or input to the application associated with the GUI. Other forms of functionally adaptable user interfaces can also be implemented, such as audio interfaces that utilize voice prompts output via the speaker 2017 and user voice commands input via the microphone 680. These other forms of functionally adaptable user interfaces may also be implemented on the provider device 104 and the requester device 102 .

[0201] It should be understood that the structural scenario of the coordination server 108 is presented by way of example only. Therefore, in some arrangements, one or more features of the coordination server 108 may be omitted. Moreover, in some arrangements, one or more features of the combined coordination and model recognition servers 108, 112 may be combined. In addition, in some arrangements, one or more features of the combined coordination and model recognition servers 108, 112 may be split into one or more component parts.

[0202] Fig.21 Shown is the method for implementing Figure 1In an alternative implementation, the combined coordination and model recognition server 108, 112 can be generally described as a physical device including at least one processor 2102 and at least one memory 2104 including computer program code. The at least one memory 2104 and the computer program code are configured to, together with the at least one processor 2102, cause the combined coordination and model recognition server 108, 112 to execute Figure 3 , Figures 6 to 9 and Fig.11 The combined coordination and model identification servers 108, 112 may include Figure 2 The various modules 202 to 222 of the system 200 are described in detail. The memory 2104 stores computer program code compiled by the processor 2102 to enable each of the modules 202 to 222 to perform its corresponding function, such as Figure 2 and as described in the accompanying description.

[0203] The combined coordination and model identification server 108, 112 may also include: a coordination module 1508, which is configured to perform the function of communicating with the requester device 102 and the provider device 104; and a payment acquirer server 106 and a publisher server 110, which are used to receive and send data respectively, which data includes location data, vehicle data, path data, model data, path constraint data (or data and parameters input to the problem situation entity 404) and / or transaction data for adaptive optimal model identification and path selection / generation process.

[0204] The combined coordination and model recognition server 108, 112 may also include a data module 2106 configured to execute the data from the requesting device 102, the providing device 104, the coordination server 108, the cloud and the Figure 3 , Figures 6 to 9 and Fig.11 The data module 1506 may be configured to receive data from other information sources of the process, the data including location data, vehicle data, path data, model data, path constraint data (or data and parameters input to the problem situation entity 404), and / or transaction data. For example, the data module 1506 may be configured to receive a request with data from a user device (such as the requester device 112 or the provider device 114), the data including location data, vehicle data, path data, model data, path constraint data (or data and parameters input to the problem situation entity 404), and / or transaction data to perform the adaptive model identification and path selection / generation process.

[0205] The above describes only some embodiments of the present disclosure, and modifications and / or changes may be made thereto without departing from the scope and spirit of the present invention, and these embodiments are exemplary rather than restrictive.

Claims

1. A method for adaptively identifying an optimal model for selecting a path to a location, comprising: providing one or more first models based on path characteristics associated with the location; retrieving one or more first parameters associated with the path characteristic to determine effectiveness of each of the one or more first models in minimizing a path cost parameter; as well as Based on the effectiveness, the best model is selected from the one or more first models.

2. The method according to claim 1, wherein: The step of retrieving one or more first parameters associated with the path characteristics to determine the effectiveness of each of the one or more first models in minimizing the path cost parameter comprises: For each of the one or more first models, at least one of a first load at the location, a first time, a first path to the location, a first vehicle type, a first distance is generated, and wherein the step of selecting the best model from the one or more first models comprises: At least one of the first load at the location, the first time, the first path to the location, the first vehicle type, and the first distance of one of the one or more first models is identified as the first load at the location, the first time, the first path to the location, the first vehicle type, and the first distance of the optimal model.

3. The method according to claim 1 or 2, wherein: The one or more first parameters include at least one of the following: the number, load, location coordinates, distance, time of items to be unloaded / picked up at the location; the type, load capacity, speed, and capacity of the vehicle; the number of available vehicles; and the vehicle type constraint, cumulative time constraint, cumulative distance constraint, cumulative load constraint, path sequence constraint, arrival time window constraint associated with the location.

4. The method according to any one of claims 1 to 3, wherein: The step of retrieving one or more first parameters associated with the path characteristics to determine the effectiveness of each of the one or more first models in minimizing the path cost parameter comprises: For each of the one or more first models, a value of the path cost parameter is determined based on one or more first parameters of each of the one or more first models, a high value of the path cost parameter indicates low effectiveness in minimizing the path cost parameter, wherein the step of selecting the best model from the one or more first models is based on the value of the path cost parameter.

5. The method according to any one of claims 1 to 4, further comprising: generating a second model from the best model; determining whether the effectiveness of the second model in minimizing the path cost parameter is greater than the effectiveness of the best model in minimizing the path cost parameter; The second model is set as the optimal model in response to a result of the determining.

6. The method according to claim 5, wherein: The step of generating the second model from the best model comprises: generating at least one of a second load for the location, a second time, a second path to the location, a second vehicle type, a second distance, and wherein the step of setting the second model as the optimal model in response to a result of the determining comprises: Identify at least one of the second load at the location, the second time, the second path to the location, the second vehicle type, and the second distance of the second model as the second load at the location, the second time, the second path to the location, the second vehicle type, and the second distance of the optimal model.

7. The method of claim 6, wherein the step of generating the second path to the location comprises one of: (a) adding a new location to the path; or (b) wherein the position is one of a plurality of positions, and the path leading to the position selected by the optimal model is a path that connects the plurality of positions in sequence, removes the position from the path, or switches the sequence of the position with another position of the plurality of positions.

8. The method according to any one of claims 5 to 7, further comprising: A determination is made as to whether the validity of the second model is greater than the validity of a previously generated second model.

9. The method according to any one of claims 5 to 8, wherein: The second model is one of a plurality of second models, and the generation of the second model is based on a weighted number, the second model having a highest weighted number compared to weighted numbers of the remaining second models of the plurality of second models.

10. The method according to any one of claims 5 to 9, further comprising: determining whether a total number of generated second models or a total processing time exceeds a preconfigured threshold condition, the total processing time representing a total time taken to adaptively identify the best model for selecting the path to the location, wherein generating the second model from the best path is performed in response to determining that the total number of second models or the total processing time does not exceed the preconfigured threshold condition.

11. A system for identifying an optimal path connecting a plurality of destinations, the system comprising: at least one processor; as well as at least one memory including computer program code; The at least one memory and the computer program code are configured to, together with at least one processor, cause the server to perform at least the following steps: providing one or more first models based on path characteristics associated with the locations; retrieving one or more first parameters associated with the path characteristic to determine effectiveness of each of the one or more first models in minimizing a path cost parameter; as well as Based on the effectiveness, a best model is selected from the one or more first models.

12. The system according to claim 11, wherein: The at least one memory and the computer program code are configured to, together with the at least one processor, cause the server to further perform at least the following steps: generating, for each of the one or more first models, at least one of a first load for a location, a first time, a first path to the location, a first vehicle type, a first distance; as well as At least one of the first load at the location, the first time, the first path to the location, the first vehicle type, and the first distance of one of the one or more first models is identified as the first load at the location, the first time, the first path to the location, the first vehicle type, and the first distance of the optimal model.

13. The system according to claim 11 or 12, wherein: The one or more first parameters include at least one of the following: the number, load, location coordinates, distance, time of items to be unloaded / picked up at the location; the type, load capacity, speed, and capacity of the vehicle; the number of available vehicles; and the vehicle type constraint, cumulative time constraint, cumulative distance constraint, cumulative load constraint, path sequence constraint, arrival time window constraint associated with the location.

14. A system according to any one of claims 11 to 13, wherein: The at least one memory and the computer program code are configured to, with the at least one processor, cause the server to at least further: For each of the one or more first models, a value of the path cost parameter is determined based on one or more first parameters of each of the one or more first models; a high value of the path cost parameter indicates low effectiveness in minimizing the path cost parameter, wherein the step of selecting the best model from the one or more first models is based on the value of the path cost parameter.

15. The system according to claim 11, wherein: The at least one memory and the computer program code are configured to, with the at least one processor, cause the server to at least further: generating a second model from the best model; determining whether the effectiveness of the second model in minimizing the path cost parameter is greater than the effectiveness of the best model in minimizing the path cost parameter; The second model is set as the optimal model in response to a result of the determining.

16. The system of claim 15, wherein: To generate the second model from the best model, the at least one memory and the computer program code are configured to, together with the at least one processor, cause the server to at least: generating at least one of a second load for the location, a second time, a second path to the location, a second vehicle type, a second distance; Identify at least one of the second load at the location, the second time, the second path to the location, the second vehicle type, and the second distance of the second model as the second load at the location, the second time, the second path to the location, the second vehicle type, and the second distance of the optimal model.

17. The system of claim 16, wherein to generate the second path to the location, the at least one memory and the computer program code are configured to, together with the at least one processor, cause the server to perform at least one of the following steps: (a) adding a new location to the path; or (b) wherein the position is one of a plurality of positions, and the path leading to the position selected by the optimal model is a path that connects the plurality of positions in sequence, removes the position from the path, or switches the sequence of the position with another position of the plurality of positions.

18. A system according to any one of claims 15 to 17, wherein: The at least one memory and the computer program code are configured to, with the at least one processor, cause the server to at least: Determining whether the validity of the second model is greater than the validity of a previously generated second model, wherein setting the second model as the optimal model is performed further in response to determining that the validity of the second model is greater than the validity of the previously generated second model.

19. A system according to any one of claims 15 to 18, wherein: The second model is one of a plurality of second models, and the generation of the second model is based on a weighted number, the second model having a highest weighted number compared to weighted numbers of the remaining second models of the plurality of second models.

20. A system according to any one of claims 15 to 19, wherein: The at least one memory and the computer program code are configured to, with the at least one processor, cause the server to at least further: determining whether a total number of generated second models or a total processing time exceeds a preconfigured threshold condition, the total processing time representing a total time taken to adaptively identify the best model for selecting the path to the location, wherein generating the second model from the best path is performed in response to determining that the total number of second models or the total processing time does not exceed the preconfigured threshold condition.

Images