Method and system for adaptively determining position of moving object relative to target object

Abstract

Methods and systems are provided for adaptively determining a position of a moving object relative to a target object. In some examples, there is provided a method for adaptively determining a position of a moving object relative to a target object, the method comprising: in response to a request message comprising position information of the target object, identifying a latitude and a longitude of the position of the target object; identifying position information of a moving object near the target object based on the identified latitude and longitude of the target object; and adaptively determining a position of the moving object relative to the target object based on the identified position information.

Description

Technical Field

[0001] The present disclosure relates broadly, but not exclusively, to methods and systems for adaptively determining a position of a moving object relative to a target object. Background Art

[0002] One of the fundamental problems in the ride-hailing and delivery industries is to locate the nearest moving objects in real time. This is a problem that is intensively studied in ride-hailing platform companies. An approach known as Network Incremental Expansion (NIE) is often used because the algorithm finds the K nearest neighbors (KNN) sorted by actual travel distance or travel time.

[0003] However, since the algorithm needs to visit all nodes / edges of the search space until one of the termination conditions is met, such as finding the K nearest neighbors or exceeding the distance / time limit, it is a computationally expensive operation. Therefore, when the KNN search radius is relatively small (below 5000 meters), the classic NIE tends to perform well, but when the search radius is larger, such as when searching for KNN in an entire province or city, the classic NIE tends to have a poor running time.

[0004] Therefore, there is a need to provide methods and systems that seek to overcome or at least minimize the above-mentioned challenges. Summary of the invention

[0005] According to a first aspect of the present disclosure, a method for adaptively determining a position of a mobile object relative to a target object is provided, the method comprising: identifying the latitude and longitude of the position of the target object in response to a request message including the position information of the target object; identifying the position information of a mobile object near the target object based on the identified latitude and longitude of the target object; and adaptively determining the position of the mobile object relative to the target object based on the identified position information.

[0006] According to a second aspect of the present disclosure, a system for adaptively determining a position of a mobile object relative to a target object is provided, 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 utilize the at least one processor to enable the system to at least: identify the latitude and longitude of the position of the target object in response to a request message comprising the position information of the target object; identify the position information of a mobile object near the target object based on the identified latitude and longitude of the target object; and adaptively determine the position of the mobile object relative to the target object based on the identified position information. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0008] Figure 1 A system for adaptively determining a position of a moving object relative to a target object according to various embodiments of the present disclosure is shown.

[0009] Figure 2 is a schematic diagram of a positioning server according to various embodiments of the present disclosure.

[0010] Figure 3 is an overview of a process for adaptively determining a position of a moving object relative to a target object in accordance with various implementations.

[0011] Figure 4A Depicted are example diagrams of how phantom nodes may be utilized in accordance with various implementations.

[0012] Figure 4B Depicted are example diagrams of mobile object storage in accordance with various implementations.

[0013] Figure 4C Depicted is an example diagram of an associated directory including a node store and a partition store in accordance with various implementations.

[0014] Figure 5 Depicted are example illustrations of an architectural framework for adaptively determining a position of a moving object relative to a target object in accordance with various implementations.

[0015] Fig. 6A Depicted is an example illustration of a mobile object update flow chart in accordance with various implementations.

[0016] Figure 6B Depicted is an example illustration of an algorithm that may be implemented for a moving object update flow chart in accordance with various embodiments.

[0017] Figure 6C An example illustration of a mobile object proximity request flow diagram is depicted in accordance with various implementations.

[0018] FIG. 6D to FIG. 6E Depicted is an example illustration of an algorithm that may be implemented for a mobile object proximity request flow chart in accordance with various implementations.

[0019] Figure 7 An example flow chart of a method for adaptively determining a position of a moving object relative to a target object according to various embodiments is shown.

[0020] Fig. 8A is a schematic block diagram of a general-purpose computer system on which Figure 2 The positioning server.

[0021] Figure 8Bis a schematic block diagram of a general-purpose computer system on which Figure 1 A combined transaction processing and location server.

[0022] Fig. 9 Shows the implementation Figure 1 An example of a computing device of a transaction processing server is shown in .

[0023] Fig.10 Shows the implementation Figure 1 An example of a computing device for a positioning server is shown in FIG.

[0024] Fig.11 Shows the implementation Figure 1 An example of a combined transaction processing and location server computing device is shown in FIG.

[0025] Those skilled in the art will appreciate that the elements in the figures are shown 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 understanding of the present embodiment. DETAILED DESCRIPTION

[0026] Terminology Description

[0027] A platform refers to a set of technologies that are used as a basis for facilitating exchanges between two or more interdependent servers, entities, and / or devices, such as exchanges between a requester device (of a product or service) and a provider device (of a product or service). For example, a platform may provide services provided by providers to requesters, such as rides, deliveries, online shopping, insurance, and other similar services. Requesters may typically access the platform via a website, an application, or other similar methods. In this disclosure, a requester of a ride is also referred to as a target object, and a provider of a ride is also referred to as a mobile object.

[0028] The request message may refer to a request for a ride, or a request for determining the position of a mobile object relative to a target object. The request message may originate from the target object and be transmitted from the requester device to a server or device associated with the platform, and may include location information of the target object. The location information may include GPS coordinates of latitude and longitude for identifying the location of the target object. The location of the target object may also be referred to as a query point. The location of the mobile object close to the given location information is then determined based on the latitude and the longitude. Each mobile object whose location is determined may be associated with a graph partition. The graph edges may also be partitioned based on the location information of each mobile object whose location is determined. A graph edge refers to a representation of the relative position of a target object or mobile object on a road map, which includes a road network. Mapping and partitioning of graph edges may involve retrieving and / or updating data related to the association between each object and a corresponding graph partition, as well as data related to a road network derived from, for example, an Open Street Map (OSM) graph.

[0029] In at least some embodiments, a user may be any suitable type of entity, which may include a person, a consumer who wishes to purchase a product or service via a transaction processing server, a seller or merchant who wishes to sell a product or service via a transaction processing server, a motorcycle driver or pillion passenger in the case where a user wishes to book or provide a motorcycle ride or delivery via a transaction processing server, a car driver or passenger in the case where a user wishes to book or provide a car ride or delivery via a transaction processing server, a delivery person who travels by bicycle, electric mobility vehicle (EMV) or on foot to provide delivery services via a transaction processing service, and other similar entities. Users registered with a transaction processing or positioning server will be referred to as registered users. Users who are not registered with a transaction processing server or positioning server will be referred to as unregistered users. The term user will be used to collectively refer to registered users and unregistered users. Users may be interchangeably referred to as requesters (e.g., people who request products or services by, for example, sending a request message) or providers (e.g., people who provide requested products or services to requesters).

[0030] In at least some embodiments, the positioning server is a server that hosts a software application (e.g., Pharos©) for adaptively determining the position of a mobile object relative to a target object. The positioning server may be configured as follows: Figure 3 As shown in the schematic diagram 300 , the method is implemented to adaptively determine the position of the moving object relative to the target object.

[0031] In at least some embodiments, a transaction processing server is a server that hosts a software application for processing payment transactions for, for example, trip ordering requests, user purchases of goods or services, and other similar services. The transaction processing server communicates with any other server (e.g., a positioning server) regarding processing payment transactions related to the purchase of goods or services (such as trip coordination requests). For example, data associated with a request message such as a trip coordination request or a KNN query (e.g., the date, time, location information of the user making the request or query, and other similar data) can be provided to the positioning server and processed to determine the location of a mobile object that is proximate to the user's location. The transaction processing server can use a variety of different protocols and procedures in order to process payment and / or trip coordination requests.

[0032] Transactions that may be performed via the transaction processing server include product or service purchases, credit purchases, debit transactions, funds transfers, account withdrawals, etc. The transaction processing server may be configured to process transactions via cash substitutes, which may include payment cards, letters of credit, checks, payment accounts, etc.

[0033] In at least some embodiments, the transaction processing server is typically managed by a service provider, which can be an entity (e.g., a company or organization) that operates to process transaction requests and / or trip coordination requests, for example, pairing a provider of trip coordination requests with a requester of trip coordination requests. The transaction processing server can include one or more computing devices for processing transaction requests and / or trip coordination requests.

[0034] In at least some embodiments, a transaction account is an account of a user registered at a transaction processing server. A user may be a customer, a merchant offering products for sale on the platform and / or joining the platform, a ride provider (e.g., a mobile object), or any third party (e.g., a courier) who wants to use a transaction processing server. In some cases, a transaction account is not required to use a transaction processing server. A transaction account includes details of a user (e.g., name, address, vehicle, facial image, etc.). The transaction processing server manages transactions.

[0035] Embodiments will be described by way of example only with reference to the accompanying drawings, in which like reference numerals and characters refer to like elements or equivalents.

[0036] Some portions of the following description are presented, either 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 technology to most effectively convey the substance of their work to others skilled in the art. An algorithm is here generally considered to be a self-consistent sequence of steps leading to a desired result. These steps are those requiring physical manipulation of physical quantities, such as electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated.

[0037] Unless otherwise specifically noted, and as will become apparent from the following, it should be understood that throughout this specification, discussions using terms such as "locating," "identifying," "determining," "associating," "mapping," "partitioning," "processing," "storing," "aggregating," "computing," and the like refer to actions and processes of a computer system or similar electronic device that manipulate and transform data represented as physical quantities within a computer system into other data similarly represented as physical quantities within a computer system or other information storage, transmission, or display device.

[0038] In addition, this specification also implicitly discloses a computer program, and 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 particular 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 present disclosure contained herein. In addition, the computer program is not intended to be limited to any particular control flow. There are many other variations of the computer program, which can use different control flows without departing from the scope of this specification.

[0039] In addition, one or more 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. A computer readable medium may include a storage device, such as a magnetic or optical disk, a memory chip or other storage device suitable for being connected to a computer interface. A computer readable medium may also include hardwired media, such as those illustrated in the Internet system, or wireless media, such as those illustrated in the GSM mobile phone system. When the computer program is loaded and executed on such a computer, a device that implements the steps of the preferred method is effectively generated.

[0040] Incremental Network Expansion (INE) refers to an algorithmic technique for finding K nearest neighbors (KNN) sorted by actual driving distance or driving time. This technique is commonly utilized by ride-hailing platforms and can be implemented in applications such as Pharos©.

[0041] Open Street Map (OSM) is a free, open-source, editable map maintained by its community. Pharos© uses a map extracted from the OSM base map as a graph representation of road topology. This base map is represented as a raw OSM protobuf file and will be processed to generate a Multi-Level Dijkstra (MLD) graph.

[0042] Pharos© is an application that supports large-scale, real-time K-nearest searches by driving distance or ETA, with high object update frequency. OSM graphs can be used in Pharos© to represent road networks. OSM graphs can be partitioned by city and vertical domain (e.g., road networks for four-wheeled vehicles are different compared to motorcycles or pedestrians). The partition key for graph partitioning can be represented as a map ID. Pharos© loads graph partitions at service startup and stores spatial data of drivers in memory in a distributed manner to alleviate scalability issues as the graph or number of drivers grows. To answer KNN queries by routing distance or estimated time of arrival (ETA), Pharos uses INEs starting from the road segment at the query point (e.g., the location relevant to the KNN query, such as the location where the driver picked up the user). During expansion, drivers stored along the road segment are incrementally retrieved as candidates and put into the results. Expansion generates isochrone graphs and can terminate when a predefined distance radius or ETA is reached, or even just when a maximum number of candidates is reached. Since drivers typically move around in a road network while performing searches, objects associated with drivers may be referred to as moving objects, while requesters associated with KNN queries may be referred to as target objects.

[0043] The minimum cut maximum flow theorem refers to a network flow theorem that states that the maximum flow from a given source through any network to a given sink is exactly the sum of the edge weights that if removed would completely disconnect the source from the sink. In other words, for any network graph and selected source and sink nodes, the maximum flow from the source to the sink = the minimum cut required to separate the source from the sink. Flow can be applied to anything. For example, it could mean the amount of water that can pass through a network pipe, or it could mean the amount of data that can pass through a computer network such as the Internet. In the present disclosure, the minimum cut maximum flow algorithm is an algorithm that works based on the minimum cut maximum flow theorem and can be implemented for use in partitioned road networks, where the flow can be interpreted as being related to multiple moving objects (e.g., drivers) in the road network.

[0044] There are some challenges in serving large radius KNN in real time. From the business requirement, the K nearest objects need to be calculated by actual routing distance rather than straight-line distance. When processing KNN queries with large search radius, classic methods like INE become computationally expensive because the search space is exponentially related to the search radius, making it a non-scalable solution. In addition, the objects to be searched and located during the KNN search keep changing at different speeds in the road network. These updates need to be reflected in the search results in real time. By overcoming the above challenges, the proposed solution can efficiently search for K mobile objects within an entire city or even a country. In addition, the algorithm can be advantageously extended to be able to search for any type of spatial objects within a large radius (e.g., ~100km).

[0045] In the present disclosure, an improvement to the classic INE (which uses a computationally expensive method to traverse the road network for distance calculation) is proposed by utilizing search space pruning. Search space pruning can be very efficient for spatial objects because in reality, spatial objects are usually clustered in certain areas, such as densely populated residential areas, central business districts. Therefore, there are opportunities for optimization because many areas that do not contain any spatial objects can be skipped. The search space of the KNN query can be advantageously significantly reduced, thereby improving its runtime complexity.

[0046] To support the above operations, a method is needed to efficiently partition the road network into partitions of reasonable size and actively maintain the association between object locations and road networks and road network partitions. For example, the road network is recursively partitioned into multiple layers of partitions through the minimum cut maximum flow algorithm. By performing a series of minimum "natural cut" calculations, the algorithm can identify and retain dense areas in the map while maintaining the natural structure of the network in each partition.

[0047] The proposed solution can be implemented in Pharos© as a scalable in-memory solution and used to support large-scale, real-time K-nearest searches by driving distance or ETA with high object update frequency. Pharos© can store map data and spatial data of objects and associations between each object and partitions in a mobile object store and an associated directory. Pharos© can use multiple concurrent hashmaps to maintain a mapping between the location of mobile objects and the road network. For example, during a mobile object update operation, the location of a mobile object is snapped to the road network to obtain its relative position in the road graph (graph edge ID, relative distance to the starting node of the edge, and which partitions in all levels the edge is surrounded by). This information is finally stored in the in-memory object store along with the object's metadata. When performing a KNN search, starting from a query point, Pharos© can be configured to expand the road network while proactively checking whether it can skip partitions where some objects are empty by looking up the associated directory and the mobile object store. In Figure 4A and Figure 4B Moving object storage and associated directories are further explained in.

[0048] Figure 1 A block diagram of an example system 100 for adaptively determining a position of a moving object relative to a target object is shown. In some implementations, the system 100 can enable payment transactions for goods or services between requesters and providers, and / or requesting a ride or delivery of physical items (e.g., one or more groceries or packages).

[0049] System 100 includes a requester device 102 , a provider device 104 , an acquirer server 106 , a transaction processing server 108 , an issuer server 110 , a locator server 140 , and a reference database 150 .

[0050] The requester device 102 communicates with the provider device 104 via connection 112, and when the location of the mobile object relative to the target object is determined, it can be associated with the target object during the KNN query search. The connection 112 can be wireless (e.g., via NFC communication, Bluetooth, etc.) or through a network (e.g., the Internet). The requester device 102 also communicates with the locator server 140 via connection 121, wherein the positioning server 140 can be configured to receive the location information of the requester device 102 (and thus receive the location information of the associated target object). The connection 121 can be via a network (e.g., the Internet). The requester device 102 can also be connected to a cloud that facilitates the system 100 to adaptively determine the location of the mobile object relative to the target object. For example, the requester device 102 can send a signal or data directly to the cloud via a wireless connection (e.g., via NFC communication, Bluetooth, etc.) or through a network (e.g., the Internet).

[0051] As described above, the provider device 104 typically communicates with the requester device 102 via the transaction processing server 108, and when the location of the mobile object relative to the target object is determined, it can be associated with the mobile object during the KNN query search. The provider device 104 in turn communicates with the acquirer server 106 via connection 114. The provider device 104 also communicates with the locator server 140 via connection 123, wherein the locator server 140 can be configured to receive the location information of the provider device 104 (and thus the location information of the associated mobile object). Connections 114 and 123 can be via a network (e.g., the Internet). The provider device 104 can also be connected to a cloud that facilitates the system 100 to adaptively determine the location of the mobile object relative to the target object. For example, the provider device 104 can send a signal or data directly to the cloud via a wireless connection (e.g., via NFC communication, Bluetooth, etc.) or through a network (e.g., the Internet).

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

[0053] The transaction processing server 108 further communicates with the positioning server 140 via a connection 120. The connection 120 may be through a network (eg, a local area network, a wide area network, the Internet, etc.) In one arrangement, the transaction processing server 108 and the positioning server 140 are combined, and the connection 120 may be an interconnecting bus.

[0054] The positioning server 140 in turn communicates with the reference database 150 via a corresponding connection 122. The connection 122 may be through a network (e.g., the Internet). The positioning server 140 may also be connected to a cloud that facilitates the system 100 to adaptively determine the location of the mobile object relative to the target object. For example, the positioning server 140 may send a signal or data directly to the cloud via a wireless connection (e.g., via NFC communication, Bluetooth, etc.) or through a network (e.g., the Internet).

[0055] The reference database 150 may include data used by the positioning server 140 to adaptively determine the position of the mobile object relative to the target object. For example, the mobile object storage and associated directory may be stored in the reference database 150. For example, data related to the mobile object storage and associated directory (such as map data, object spatial data, data related to the association between each object and the corresponding map partition) may be stored in the reference database 150. In addition, data related to the OSM map may also be stored in the reference database 150. In an implementation, the reference database 150 may be combined with the positioning server 140. In an example, the reference database 150 may be managed by an external entity.

[0056] The positioning server 140 can identify the latitude and longitude of the location of the target object based on the location information of the target object indicated in the request message (e.g., a request provided by a user). Then, the positioning server 140 can be configured to identify the location information of the mobile object near the target object based on the identified latitude and longitude of the target object, and adaptively determine the position of the mobile object relative to the target object based on the identified location information. The association of the mobile object and the target object can involve retrieving and / or updating data related to the mobile object storage and association directory (such as map data, object spatial data, and data related to the association between each object and the corresponding map partition), which can be stored in the reference database 150.

[0057] The positioning server 140 may be further configured to identify location information of a road network on which one or more target objects are traveling, identify a relative distance of a starting location of each of the one or more target objects, and map one or more mobile objects relative to the target objects, and partition the graph edges based on the location information of each of the one or more mobile objects. Mapping and partitioning of graph edges may involve retrieving and / or updating data related to an association between each object and a corresponding graph partition, as well as data related to the road network derived from the OSM graph that may be stored in the reference database 150.

[0058] In an implementation, there may be more than one reference database, wherein the positioning server 140 may be configured to determine which database to use at each step in the process of processing the KNN query request. Alternatively, one or more modules may store the above data instead of the reference database 150, wherein the module may be integrated as part of the positioning server 140 or external to the positioning server 140.

[0059] In an illustrative embodiment, each of the devices 102, 104 and servers 106, 108, 110, 140 and / or reference database 150 provides an interface to enable communication with other connected devices 102, 104 and / or servers 106, 108, 110, 140 and / or reference database 150. 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 (e.g., an application programming interface (API) and / or a remote procedure call (RPC) set corresponding to interface elements), a messaging interface (wherein the interface elements correspond to messages of a communication protocol), and / or a suitable combination thereof. For example, at least one of the requester device 102 and the provider device 104 can send data related to, for example, location information of a target object and a mobile object, respectively, in response to a query shown on a GUI running on a corresponding API.

[0060] The term "server" as 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 many different hardware units.

[0061] The location server 140 is associated with an entity (e.g., a company or organization or an administrator of a service). In one arrangement, the location server 140 is owned and operated by the entity that runs the transaction processing server 108. In this arrangement, the location server 140 can be implemented as a part of the transaction processing server 108 (e.g., a computer program module, a computing device, etc.).

[0062] The transaction processing server 108 may also be configured to manage the registration of users. A registered user has a transaction account (see discussion above) which includes the user's details. The registration step is called joining. A user may perform joining to the transaction processing server 108 using either the requester device 102 or the provider device 104.

[0063] It may not be necessary to have a transaction account at the transaction processing server 108 to access the functionality of the transaction processing server 108. However, there are functions available to registered users. These additional functions will be discussed below.

[0064] The user's onboarding process is performed by the user through one of the requester device 102 and the provider device 104. In one arrangement, the user downloads an application (which includes an API that interacts with the transaction processing server 108) to the requester device 102 or the provider device 104. In another arrangement, the user visits a website (which includes an API that interacts with the transaction processing server 108) on the requester device 102 or the provider device 104. The user is then able to interact with the positioning server 140. The user can be a requester or a provider associated with the requester device 102 or the provider device 104, respectively.

[0065] For example, the registered details may include the user's name, the user's address, emergency contacts, blood type or other healthcare information, immediate family contacts, permission to retrieve data and information from the requester device 102 and / or provider device 104 for adaptively determining the location of a mobile object relative to a target object, such as permission to retrieve location information of the requester device 104 and / or provider device 102. Alternatively, another mobile device may be selected to retrieve data in place of the requester device 102 and / or provider device 104. Once joined, the user will have a transaction account where all details are stored.

[0066] The requester device 102 is associated with a customer (or requester), who is a party to a transaction occurring between the requester device 102 and the provider device 104 or between the requester device 102 and the positioning server 140. 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. When determining the position of a mobile object relative to a target object, the requester device 102 may be associated with the target object during a KNN query search.

[0067] The requester device 102 includes the transaction credentials (e.g., payment account) of the requester to enable the requester device 102 to become a party to the payment transaction. If the requester has a transaction account, the transaction account may also be included (i.e., stored) in the requester device 102. For example, a mobile device (which is the requester device 102) may store the customer's transaction account in the mobile device.

[0068] In one example arrangement, the requester device 102 is a computing device in a watch or similar wearable device 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 request. The customer uses the watch or similar wearable device to make a request regarding the transaction request by pressing a button on the watch or wearable device.

[0069] The provider device 104 is associated with a provider who is also a party to the transaction request occurring between the requester device 102 and the provider device 104. The provider device 104 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. The provider device 104 may be associated with the mobile object during a KNN query search when determining the location of the mobile object relative to the target object.

[0070] Hereinafter, the term "provider" refers to the service provider and any third party associated with providing a product or service, or a trip or ride or delivery service for purchase via the provider device 104. Thus, a provider's transaction account refers to the provider's transaction account and the transaction account of a third party associated with the provider (e.g., a trip coordinator or merchant).

[0071] If the provider has a transaction account, the transaction account may also be included (ie, stored) in the provider device 104. For example, a mobile device (which is the provider device 104) may store the provider's transaction account in the mobile device.

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

[0073] 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, operates, manages) a merchant's payment account (e.g., a financial bank account). Examples of acquirers include banks and / or other financial institutions. As described above, the acquirer server 106 may include one or more computing devices that are used to establish communication with another server (e.g., a transaction processing server 108) by exchanging messages with the other server and / or passing information to the other server. The acquirer server 106 forwards the payment transaction associated with the transaction request to the transaction processing server 108.

[0074] The transaction processing server 108 is configured to handle processes related to transaction accounts by, for example, forwarding data and information associated with the transaction to other servers in the system 100 (e.g., the positioning server 140). In an example, the transaction processing server 108 may transmit data related to a request message such as a trip coordination request or a KNN query (e.g., the date, time, location information of the user making the request or query, and other similar data) to the positioning server for processing to determine the location of a mobile object close to the user's location. The transaction processing server 108 may use a variety of different protocols and processes in order to process payment and / or trip coordination requests. It should be understood that payment for transactions may be made via a variety of methods, such as credit cards, debit cards, digital wallets, buy now, pay later schemes, and other similar payment methods. In an implementation, the transaction processing server 108 may be further configured to perform the functions of the positioning server 140, so that the positioning server 140 is not required.

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

[0076] The reference database 150 is a database or server associated with an entity (e.g., a company or organization) that manages (e.g., creates, manages) data associated with users, transactions, products, services, and other similar data, such as data associated with the entity. In one arrangement, the reference database 150 may include data used by the positioning server 140 to adaptively determine the position of a mobile object relative to a target object. For example, a mobile object store and an associated directory may be stored in the reference database 150. For example, data related to the mobile object store and the associated directory (such as map data, object spatial data, data related to the association between each object and the corresponding map partition) may be stored in the reference database 150. In addition, data related to the OSM map may also be stored in the reference database 150.

[0077] Advantageously, the system 100 enables a road network to be efficiently partitioned into reasonably sized partitions while actively maintaining associations between object locations and road networks and road network partitions, significantly reducing the search space of KNN queries and thereby improving runtime complexity.

[0078] Figure 2 A schematic diagram of an example positioning server 140 according to various embodiments is shown. The positioning server 140 may include a data module 260 configured to receive data and information from the requester device 102, the provider device 104, the transaction processing server 108, the reference database 150, the cloud, and other information sources to adaptively determine the position of the mobile object relative to the target object by the positioning server 140. For example, the data module 260 may be configured to receive data and information required to process the request message from the requester device 102, the provider device 104, the transaction processing server 108, the reference database 150, and / or other information sources. The data module 260 may also be configured to retrieve the data required for the request message from the reference database 150 and / or other information sources. The data module 260 may further be configured to send information related to the data retrieved in response to the data request to the requester device 102, the provider device 104, the transaction processing server 108, or other destinations where the information is needed.

[0079] The positioning server 140 may include an identification module 262, which is configured to identify the latitude and longitude of the location of the target object in response to a request message including the location information of the target object, and identify the location information of mobile objects near the target object based on the identified latitude and longitude of the target object. For example, the identification module 262 may be configured to identify the latitude and longitude based on the GPS coordinates corresponding to the location information provided in the request message. The identification module 262 may be further configured to identify the location information of the road network on which the target object is traveling, and identify the relative distance of the starting position of the target object. The identification module 262 may be further configured to identify the mobile object closest to the target object when more than one mobile object is identified. FIG. 6A to FIG. 6E The above identification steps are further explained in .

[0080] The positioning server 140 may further include a positioning module 264 configured to adaptively determine the position of the mobile object relative to the target object based on the identified position information. FIG. 6A to FIG. 6E Determining the position of a moving object relative to a target object is further explained in .

[0081] The positioning server 140 may also include a mapping module 266 configured to map more than one mobile object relative to the target object, subtracting or adding data retrieved from the first and second databases, and may also be configured to map the location of the target object onto the road network to obtain its relative location in the road map, wherein the road map includes the road network. The positioning server 140 may also include a partitioning module 268 configured to partition the graph edge based on the location information of the mobile information.

[0082] Each of the data module 260, the identification module 262, the positioning module 264, the mapping module 266, and the partitioning module 268 may further communicate with a processing module (not shown) of the positioning server 140, for example, to coordinate the corresponding tasks and functions during processing. The data module 260 may be further configured to communicate and store data and information with each of the processing module, the identification module 262, the positioning module 264, the mapping module 266, and the partitioning module 268. Alternatively, all tasks and functions required to adaptively determine the position of the mobile object relative to the target object may be performed by a single processor of the positioning server 140.

[0083] In the present disclosure, the proposed solution is described based on utilizing Pharos© to adaptively determine the position of a moving object relative to a target object. However, it should be understood that other similar applications may also be utilized.

[0084] As mentioned earlier, Pharos© uses a map extracted from the OSM base map as its graph representation of road topology. This base map, represented as a raw OSM protobuf file, is processed to generate an MLD graph. Pharos© prefers the MLD graph representation because (1) MLD graphs are widely used and can be seamlessly integrated with Pharos©, (2) rich graph details (e.g., turn restrictions, road closures) can be easily incorporated into the MLD graph, and (3) the MLD graph has multiple layers of partitioning to speed up route queries. These techniques benefit Pharos© in supporting fast long-distance KNN queries. If the query point is far away, the INE solution does not scale well because the time complexity increases with the size of the extended network. This issue is not critical because KNN queries in Pharos© usually search a very limited area because mobile objects far away from the pickup point may incur a high cancellation rate (e.g., cancellation of the trip coordination request associated with the KNN query). However, in order to meet various business needs (e.g., nearby queries for a specific type of vehicle that may be far away), it may be desirable to support KNN queries over long distances. Multi-level partitioning in an MLD graph can be used to handle this scenario, although it needs to be carefully weighed because of the indices between moving objects and the graph will continue to grow.

[0085] To reduce computational complexity and storage, the road network will first be converted to a compressed node-based graph (CNBG) and then to an edge-based graph (EBG). Each node on the EBG is represented as an edge-based node (EBN), which is equal to the compressed edge in the original graph. Pharos© will load the MLD graph into memory during service startup. To support highly localized business needs, the graph is partitioned by city and vertical domain (e.g., the road network for four-wheeled vehicles is definitely different compared to motorcycles or pedestrians). The partition key for graph partitioning is represented as the map ID.

[0086] In order to support K-nearest neighbor (KNN) search using the association directory algorithm, one of the requirements is to split the road network into multiple partitions. Ideally, each partition should be a strongly connected component, which means that every node in the partition should be reachable from any other node. This guarantees the correctness of the revised KNN algorithm.

[0087] Graph partitioning algorithms can be used to partition the road network by repeatedly performing "natural cuts". By using a minimum cut maximum flow algorithm, dense areas in the map can be identified and retained while preserving the natural structure of the network in each partition. Figure 3 As shown in the diagram 300 of , given an original graph A 302 (e.g., considered as a level 4 partition, where the entire map is surrounded by a single partition), a partition hierarchy with five levels can be created. A minimum cut maximum flow algorithm is performed to split A 302 (level 4) into partitions B 304 and C 306 (level 3), which are further split into D 308, E 310, F 312, and G 314 (level 2), respectively, and the operation continues until level 1, which contains partitions H 316, I 318, J 320, K 322, L 324, M 326, N 328, O 330. Therefore, the road network is organized as a hierarchy of partitions, with larger partitions at higher levels, each larger partition containing up to 2 smaller partitions at lower levels, and the base graph at the lowest level (level 0), where each graph node is considered a partition. Each level can be viewed as a network of interconnected partitions.

[0088] Furthermore, in each partition, all boundary nodes (e.g., nodes with outgoing or incoming edges to other partitions) can be identified. For any pair of boundary nodes, shortcuts (in terms of driving distance / time) are pre-computed and stored in memory. These shortcuts will be used to skip partitions without objects while still being able to correctly compute driving distance / time during KNN expansion in road networks.

[0089] Before a mobile object update request reaches the mobile object storage layer, a “snapping” algorithm converts the latitude and longitude of the mobile object into a relative position on the road network, which includes the graph edge ID, the relative distance to the starting node of the edge, and which partitions the edge is surrounded by in all levels. Figure 4A400 demonstrates how the latitude and longitude of a mobile object (e.g., represented by node 402) can be captured to phantom nodes 404 and 406 in a road network. The projection of the phantom node (e.g., the projection of phantom node 404) includes an edge ID 408, which is a projection ratio from the starting node ID 410. If there are multiple phantom node candidates, the one closest to the observed GPS (in terms of haversine distance) can be selected.

[0090] The mobile object data from the update request along with the captured data will be processed and stored in the mobile object storage 412 and the associated directory 414, respectively. Figure 4B and Figure 4C As shown in . The mobile object store 412 is a key-value data structure that maps the ID of the driver to the corresponding driver object that will be used later during the K nearest neighbor request. The association directory 414 is also a key-value data structure that acts like an extension of the mobile object store 412. The association directory can be configured to map the graph edge to all mobile objects currently on it (e.g., under the node store 416), and to maintain the number of drivers on each partition (e.g., under the partition store 418) at the moment, so that during the search phase, all mobile objects on the graph edge can be quickly found and checked whether the partition surrounds any mobile objects.

[0091] Since Pharos© is an extremely high throughput system, each node needs to handle all mobile object updates and mobile object proximity requests for the entire city (e.g., notably, Jakarta, Ho Chi Minh City, Manila). Therefore, the driver store 412 must handle a continuous and highly frequent stream of read and write operations. To maintain data consistency, each write and read operation requires locking. Otherwise, data corruption may occur. In addition, since mobile objects are constantly moving on the road network, it may happen that the same driver is found repeatedly at different locations on the road network during the K-nearest neighbor search. Therefore, the classic approach is to take a snapshot of the driver store 412 and the associated directory 414 to feed the K-nearest neighbor query. This poses another challenge to designing the driver store, as taking a snapshot is a very expensive operation that performs a large number of reads on the driver store. In short, choosing a suitable data structure for the driver store that meets all the above requirements is a challenging task. Even the most complex and elegant in-memory data structures often fail to perform at high throughput, mainly because of read / write locks, which often lead to poor performance or even starvation.

[0092] Pharos© can use a data structure called "Short-term Driver Store Exchange" which utilizes two driver stores: the first "Writable Driver Store" only handles "write-only" driver update requests, and the second "Readable Driver Store" is used solely for "read-only" driver nearby requests. Internally, the driver store uses a concurrent hash map, which is one of the best performing in-memory data structures for read / write operations. The "Short-term Driver Store Exchange" data structure works as follows:

[0093] 1. When the service starts, an empty "writable driver storage" is initialized, and all driver update requests will be processed and stored in the "writable driver storage" within the next two seconds.

[0094] 2. After two seconds, a new empty "temporary writable driver storage" is initialized, which simultaneously copies all data from the current "writable driver storage" (this operation is very fast due to the read / write efficiency of the concurrent hash map). This "writable driver storage" is selected as the "readable driver storage", and the "temporary writable driver storage" is selected as the "writable driver storage", which is responsible for handling the driver storage for the next two seconds. The previous "readable driver storage" will be terminated and recycled.

[0095] 3. Repeat step 2 until the Pharos© service is terminated.

[0096] In the example above, a two-second latency was achieved from the moment a driver update reaches Pharos© until it can be reflected in the results of a nearby request. Based on experiments, this latency may be an acceptable trade-off as it does not negatively impact Pharos© key metrics (e.g., booking cancellations, number of completed bookings per hour, number of drivers found by K-nearest neighbor queries).

[0097] Generally speaking, Pharos© receives requests from upstream, performs corresponding actions, and then returns the results. Figure 5As shown in Figure 500, the architecture of Pharos© is a distributed memory storage of drivers, and drivers are stored in a structure called models (e.g., model layer 502). Each model is indexed by a map ID and can be replicated to multiple replicas (e.g., one or more other nodes in the node layer 504) to achieve fault tolerance. For example, if three replicas are replicated, a driver update to any of the three replicas will also be forwarded to the other two. Multiple models can be stored in the same node to optimize resources. Each node uses the map ID as an index key to track the models stored in itself. Each machine or instance (e.g., instances 508, 510, and 512) contains only one node. On top of the node, there is another structure called a proxy (e.g., proxy layer 506). When a driver update request comes, it will also be forwarded to the replicas. The proxy is designed as a component that distributes messages. In order to know which instance to forward the message to, each proxy tracks a routing table that contains a mapping from a partition key (map ID) to an instance containing a model. The routing table is dynamic and it handles the case when a new map ID is added or an existing map ID is deleted.

[0098] In general, the architecture of Pharos© can be decomposed into three layers: agent layer 506, node layer 504 and model layer 502, as shown in Figure 5 The proxy layer 506 is responsible for passing the request down to the correct node, especially when the node is on another machine or instance; the node layer 504 stores the model and passes the request to the correct model for execution; the model layer 502 performs the precise operation and returns the result.

[0099] Fig. 6A600 demonstrates the life cycle of a driver update request 602 from upstream, and diagram 610 depicts a corresponding algorithm that can be implemented to process the driver update request 602. The driver update request from upstream is distributed to each agent by the load balancer, and the selected agent (e.g., agent 604 in this example) will first construct a driver object based on the information indicated in the request. Each driver update request may include information such as the driver ID of the driver, the latitude and longitude (latlon) of the driver's location, a map ID, and other similar information that can be used to update the driver's location in the road network. Agent 604 uses the map ID as a key to check its routing table and obtain the IP addresses of all instances containing the node. Agent 604 then forwards the update to other replicas (e.g., other agents whose nodes contain replicas of the model being sought). When the replica receives the message, it will know that the update is forwarded from another agent. Therefore, they will not check the routing table in order to forward the message, but will directly pass the driver object down to their corresponding nodes (e.g., in the node layer 606). After the driver object is passed from the proxy to the node with the correct model, the driver will first be snapped to the road network and then updated in both the driver store and the associated directory. If the model being sought is not found on the current machine (e.g., in the model layer 608) because the model is stored on other machines, no action is taken and no error is raised. This is because the proxy 604 will forward the update request to those machines that have the model by looking up the routing table. In practice, Pharos© prefers high throughput over strong consistency of KNN query results because the update frequency is high and minor inconsistencies do not significantly affect the allocation performance.

[0100] The driver nearby request handler is another endpoint in Pharos© that handles KNN driver queries for a point. Pharos© can be configured to use a modified version of INE that makes use of the associated directory (e.g. Figure 4C The associated directory 414 in is used for search space pruning purposes. Similar to driver updates, after a driver neighborhood request comes from upstream, it is distributed to one of the machines or instances by the load balancer. Figure 6CAs shown in the diagram 612 of , upon receiving a nearby request 614, a nearby object is constructed and passed to the proxy layer 616. The driver nearby request 614 may include information such as the latitude and longitude (latlon) of the location, associated filter parameters, and other similar information that can be used to search for nearby drivers relative to the location indicated in the driver nearby request 614. The proxy first checks the routing table based on the indicated map ID to see if this request can be served on the current machine or instance. If so, the nearby object is passed to the node layer 618. Otherwise, the nearby request 614 needs to be forwarded to the machine or instance containing the map ID. A polling method is applied to select the correct instance for load balancing. After the selected machine receives the request, the proxy layer 616 will know that the request is forwarded from another machine and directly pass the nearby object to the node layer 618. Once the node layer 618 receives the nearby object, it uses the map ID as a key to find the correct model. Finally, the nearby object enters the model layer 620, where the K-nearest driver calculation is performed. The model will snap the requested position to some phantom nodes, which will be used as starting nodes for later expansion.

[0101] Fig.6D and Fig. 6EA diagram of a driver nearby algorithm 624 that can be implemented to process a nearby request 614 is depicted. As previously described, Pharos uses an INE with an associated directory, and those phantom nodes will be used as starting nodes for expansion. In the algorithm 624, the phantom nodes, filter parameters, maximum driver limits, and driver storage snapshots can be used as inputs 626 for searching nearby drivers based on the nearby request 614. Two priority queues implemented are used in the algorithm. The EbnPQ 630 is used to track the nearest EBN, while the driver PQ 628 tracks drivers on the road network by the distance of the driver to the nearby query point. First, a snapshot of the driver's current location is obtained from the "readable driver storage" (e.g., the driver storage snapshot). From each starting node, the parent EBN is found, and the drivers on these EBNs are attached to the driver PQ 628 (see reference 632). In the next step, the algorithm will scan the levels from the partition hierarchy, starting from the base map (level 0) to the highest level. In each level, the algorithm will find the partition containing the current EBN and check if there are any drivers on that partition by looking up the associated directory. This operation is to find the lowest level of partitions that contains at least one driver. Once the partition level is identified, the KNN search is expanded from the identified partition level to all EBNs adjacent to the current EBN (see reference 634). This is when search space pruning occurs, which ensures that the algorithm can skip empty partitions from lower levels. After repeating this process for each starting node, there will be some initial drivers in the driver PQ 628 and there will be more adjacent EBNs waiting to be expanded in the ebnPQ 630.

[0102] Each time the nearest EBN is removed from ebnPQ 630, the driver located on that EBN will be attached to driver PQ 628. The nearest driver is also removed from driver PQ 628. If the driver passes all filtering requirements, it will be attached to the result, which is a dynamic array of drivers; otherwise, the next nearest driver will be continued. This step is repeated until driver PQ 628 becomes empty. During this process, if the size of the result reaches the maximum driver limit (see reference 636), the result will be returned. After driver PQ 628 becomes empty, the adjacent EBNs of the current EBN at the same partition level will be extended, and EBNs within a predefined range (such as three kilometers) will be attached to ebnPQ 630. Then, the nearest EBN is removed from ebnPQ 630, and the driver on that EBN is attached to driver PQ 628 again. This loop continues until ebnPQ 630 becomes empty. The result will be returned to the caller.

[0103] It should be understood that the driver storage also includes metadata for the driver, which contains business-related information about the driver (e.g., driver status and specific assignment preferences). In nearby requests, a set of filter parameters can be used to match driver metadata in order to support KNN queries with various business requirements. Driver metadata also carries an update timestamp. During nearby searches, drivers with expired timestamps can be filtered out.

[0104] Figure 7 An example flow chart of a method for adaptively determining the position of a mobile object relative to a target object according to various embodiments is shown. In step 702, in response to a request message including the position information of the target object, the latitude and longitude of the position of the target object are identified. In step 704, the position information of a mobile object near the target object is identified based on the identified latitude and longitude of the target object. In step 706, the position of the mobile object relative to the target object is adaptively determined based on the identified position information.

[0105] Fig. 8A An example computer system 1400 is depicted, according to which the described positioning server 140 can be practiced. The computer system 1400 includes a computer module 1401. The computer module 1401 can use an external modulator-demodulator (modem) transceiver device 1416 to communicate with a communication network 1420 via a connection 1421. The communication network 1420 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 1421 is a telephone line, the modem 1416 can be a traditional "dial-up" modem. Alternatively, in the case where the connection 1421 is a high-capacity (e.g., cable) connection, the modem 1416 can be a broadband modem. A wireless modem can also be used to connect wirelessly to the communication network 1420.

[0106] The computer module 1401 typically includes at least one processor unit 1405 and a memory unit 1406. For example, the memory unit 1406 may have a semiconductor random access memory (RAM) and a semiconductor read-only memory (ROM). The computer module 1401 also includes an interface 1408 for an external modem 1416. In some implementations, the modem 1416 may be incorporated within the computer module 1401, such as within the interface 1408. The computer module 1401 also has a local network interface 1411, which allows the computer system 1400 to be coupled to a local communication network 1422, known as a local area network (LAN), via a connection 1423. As shown in FIG. Fig. 8AAs shown in , the local communication network 1422 may also be coupled to the wide area network 1420 via a connection 1424, which typically includes a so-called "firewall" device or a device with similar functionality. The local network interface 1411 may include an Ethernet circuit card, a Bluetooth® wireless device, or an IEEE 802.11 wireless device; however, many other types of interfaces may be practiced for the interface 1411.

[0107] The I / O interface 1408 may provide one or both of a serial and parallel connection, the former typically implemented according to the Universal Serial Bus (USB) standard and having a corresponding USB connector (not shown). A storage device 1409 is provided and typically includes a hard disk drive (HDD) 1410. Other storage devices, such as floppy disk drives and tape drives (not shown) may also be used. An optical disk drive 1412 is typically provided to act as a non-volatile data source. Portable memory devices, such as optical disks, USB-RAMs, portable external hard disk drives, and floppy disks, may be used as appropriate data sources for the system 1400.

[0108] The components 1405 to 1412 of the computer module 1401 typically communicate via the interconnection bus 1304, and in a manner that results in a conventional mode of operation of the computer system 1400 known to those skilled in the relevant art. For example, the processor 1405 is coupled to the system bus 1404 using connection 1418. Likewise, the memory 1406 and the optical drive 1412 are coupled to the system bus 1404 via connection 1419. Examples of computers on which the described arrangements may be practiced include IBM-PCs and compatibles thereof, Sun Sparcstations, Apple or similar computer systems.

[0109] The method 700 performed by the positioning server 140 can be implemented using the computer system 1400. The process can be implemented as one or more software applications 1433 that can be executed within the computer system 1400. Specifically, the sub-processes 400, 500 and 600 are implemented by instructions in the software 1433 executed within the computer system 1400. The software instructions can be formed into one or more code modules, each code module is used to perform one or more specific tasks. The software can also be divided into two independent parts, where the first part and the corresponding code module execute the method, and the second part and the corresponding code module manage the user interface between the first part and the user.

[0110] The software may be stored in a computer readable medium, which includes, for example, the storage device described below. The software is loaded from the computer readable medium into the computer system 1400 and then executed by the computer system 1400. A computer readable medium having such software or a computer program recorded on a computer readable medium is a computer program product. Using a computer program product in the computer system 1400 preferably implements an advantageous means for locating the server 140.

[0111] The software 1433 is typically stored in the HDD 1410 or the memory 1406. The software is loaded into the computer system 1400 from a computer-readable medium and executed by the computer system 1400. Thus, for example, the software 1433 may be stored on an optically readable disk storage medium (e.g., a CD-ROM) 1425 read by the optical drive 1412. A computer-readable medium having such software or a computer program recorded thereon is a computer program product. The use of a computer program product in the computer system 1400 preferably implements the apparatus for locating the server 140.

[0112] In some examples, the application 1433 may be provided to the user, encoded on one or more CD-ROMs 1425 and read via corresponding drives 1412, or alternatively may be read by the user from a network 1420 or 1422. Further, the software may also be loaded into the computer system 1400 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 computer system 1400 for execution and / or processing. Examples of such storage media include floppy disks, magnetic tapes, optical disks, hard drives, ROMs or integrated circuits, USB memories, magneto-optical disks, or computer-readable cards such as PCMCIA cards, whether such devices are internal or external to the computer module 1401. Examples of temporary or non-tangible computer-readable transmission media that may also be involved in providing software, application programs, instructions and / or data to the computer module 1401 include radio or infrared transmission channels and network connections to another computer or networked device, as well as the Internet or intranet including email transmissions and information recorded on websites, etc.

[0113] The second portion of the above-described application 1433 and the corresponding code modules may be executed to implement one or more graphical user interfaces (GUIs) to be presented on a display or otherwise represented. Users of the computer system 1400 and the applications may manipulate the interface in a functionally adaptable manner by typically manipulating a keyboard and mouse to provide control commands and / or input to the applications associated with the GUI. Other forms of functionally adaptable user interfaces may also be implemented, such as an audio interface utilizing voice prompts output via a speaker and user voice commands input via a microphone.

[0114] It should be understood that the structural context of computer system 1400 (i.e., positioning server 140) is presented only as an example. Therefore, in some arrangements, one or more features of computer system 1400 may be omitted. In addition, in some arrangements, one or more features of computer system 1400 may be combined together. In addition, in some arrangements, one or more features of computer system 1400 may be separated into one or more components.

[0115] Fig. 9 An implementation of a transaction processing server 108 (i.e., a computer system 1300) is shown. In this implementation, the transaction processing 108 can generally be described as a physical device including at least one processor 802 and at least one memory 804 including computer program code. The at least one memory 804 and the computer program code are configured to work with the at least one processor 802 so that the transaction processing server 108 facilitates the operations described in the method 700. The transaction processing server 108 may also include a transaction processing module 806. The memory 804 stores the computer program code, which the processor 802 compiles to cause the transaction processing module 806 to perform the corresponding functions.

[0116] refer to Figure 1 , the transaction processing module 806 performs the function of communicating with the requester device 102 and the provider device 104, as well as the acquirer server 106 and the issuer server 110, to receive and transmit transactions, itinerary coordination request messages, or other similar messages, respectively. In addition, instead of the requester device 102 or the provider device 104, the transaction processing module 806 can provide the positioning server 140 with data and information related to the request message, such as the request message for adaptively determining the position of the mobile object relative to the target object (e.g., date, time, position information of the target object and / or the mobile object, and other similar data).

[0117] Fig.10 An alternative implementation of the positioning server 140 (i.e., computer system 1400) is shown. In an alternative implementation, the positioning server 140 can generally be described as a physical device including at least one processor 902 and at least one memory 904 including computer program code. The at least one memory 904 and the computer program code are configured to, together with the at least one processor 902, enable the positioning server 140 to perform the operations described in the method 700. The positioning server 140 may also include a data module 906, an identification module 908, a positioning module 910, a mapping module 912, and a partitioning module 914. The memory 904 computer program code stores the processor 902 to compile it so that each of the modules 906 to 914 performs their respective functions.

[0118] refer to Figures 1 to 7 , the identification module 908 performs the following functions: in response to the request message including the location information of the target object, identifies the latitude and longitude of the location of the target object, and identifies the location information of the mobile object near the target object based on the identified latitude and longitude of the target object. The identification module 908 can be further configured to identify the location information of the road network on which the target object is traveling, and identify the relative distance of the starting position of the target object. The identification module 262 can be further configured to identify the mobile object closest to the target object when more than one mobile object is identified.

[0119] refer to Figures 1 to 7 , the positioning module 910 performs the following functions: adaptively determining the position of the mobile object relative to the target object based on the recognized position information.

[0120] refer to Figures 1 to 7 , the mapping module 912 performs the following functions: mapping more than one mobile object relative to the target object, subtracting or adding data retrieved from the first and second databases, and can also be configured to map the location of the target object onto the road network to obtain its relative location in the road map, wherein the road map includes the road network. In addition, the partitioning module 914 performs the following functions: partitioning the graph edge based on the location information of the mobile information.

[0121] refer to Figures 1 to 7 , the data module 906 performs the function of receiving data and information from the requester device 102, the provider device 104, the transaction processing server 108, the reference database 150, the cloud, and other information sources to facilitate the method 700. For example, the data module 906 can be configured to receive data and information required to process a request for adaptively determining the position of a mobile object relative to a target object from the requester device 102, the provider device 104, the transaction processing server 108, the reference database 150, and / or other information sources. The data module 906 can also be configured to retrieve the data required for the request from the reference database 150, other databases that can be specified by the data request, and / or other information sources. The data module 906 can be further configured to send information related to the data retrieved in response to the request to the requester device 102, the provider device 104, the transaction processing server 108, or other destinations that require the information. The data module 906 can be further configured to communicate with each of the identification module 908, the positioning module 910, the mapping module 912, and the partitioning module 914 and store data and information. Alternatively, all tasks and functions required to facilitate method 700 may be performed by a single processor 902 of location server 140 .

[0122] Figure 8BA general purpose computer system 1500 is depicted on which the described combined transaction processing server 108 and positioning server 140 can be practiced. The computer system 1500 includes a computer module 1501. The computer module 1501 can use an external modulator-demodulator (modem) transceiver device 1516 to communicate with 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 to connect wirelessly to the communication network 1520.

[0123] The computer module 1501 typically includes at least one processor unit 1505 and a 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 an interface 1508 for an external modem 1516. In some implementations, the modem 1516 may be incorporated within the computer module 1501, such as within 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 communication network 1522, known as a local area network (LAN), via a connection 1523. As shown in FIG. Figure 8B As shown in , the local communication network 1522 may also be coupled to the wide area network 1520 via a connection 1524, which typically includes a so-called "firewall" device or a device with similar functionality. The local network interface 1511 may include an Ethernet circuit card, a Bluetooth® wireless device, or an IEEE 802.11 wireless device; however, many other types of interfaces may be practiced for the interface 1511.

[0124] I / O interface 1508 may provide one or both of serial and parallel connections, the former typically implemented according to 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 non-volatile data source. Portable memory devices such as optical disks, USB-RAM, portable external hard disk drives, and floppy disks may be used as appropriate data sources for system 1500.

[0125] The components 1505 to 1512 of the computer module 1501 typically communicate via an interconnect bus 1504, and in a manner that results in a conventional mode of operation of the computer system 1500 known to those skilled in the relevant art. For example, the processor 1505 is coupled to the system bus 1504 using connection 1518. Likewise, 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 arrangements may be practiced include IBM-PCs and compatibles thereof, Sun Sparcstations, Apple or similar computer systems.

[0126] The steps of the method 700 performed by the positioning server 140 and facilitated by the transaction processing server 108 can be implemented using the computer system 1500. For example, the steps of the method 700 performed by the positioning server 140 can be implemented as one or more software applications 1533 that can be executed within the computer system 1500. Specifically, the steps of the method 700 are implemented by instructions in the software 1533 executed within the computer system 1500. The software instructions can be formed into one or more code modules, each code module for performing one or more specific tasks. The software can also be divided into two independent parts, wherein the first part and the corresponding code module perform the steps of the method 700, and the second part and the corresponding code module manage the user interface between the first part and the user.

[0127] The software may be stored in a computer readable medium, such as the storage device described below. The software is loaded from the computer readable medium into the computer system 1500 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 computer system 1500 preferably implements an advantageous means for combining transaction processing and locating servers.

[0128] The software 1533 is typically stored in the HDD 1510 or the memory 1506. The software is loaded into the computer system 1500 from a computer readable medium and executed by the computer system 1500. 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 drive 1512. A computer readable medium having such software or a computer program recorded thereon is a computer program product. The use of a computer program product in the computer system 1500 preferably implements an apparatus for combining transaction processing and locating a server.

[0129] In some instances, the application 1533 may be provided to the user, encoded on one or more CD-ROMs 1525 and read via corresponding drives 1512, or alternatively may be read by the user from a network 1520 or 1522. Further, the software may also be loaded into the computer system 1500 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 computer system 1500 for execution and / or processing. Examples of such storage media include floppy disks, magnetic tapes, optical disks, hard drives, ROMs or integrated circuits, USB memories, magneto-optical disks, or computer-readable cards such as PCMCIA cards, whether such devices are internal or external to the computer module 1501. Examples of temporary or non-tangible computer-readable transmission media that may also be involved in providing software, application programs, 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 email transmissions and information recorded on websites, etc.

[0130] The second portion of the above-described application 1533 and the corresponding code modules may be executed to implement one or more graphical user interfaces (GUIs) to be presented on a display or otherwise represented. Users of the computer system 1500 and the applications may manipulate the interface in a functionally adaptable manner by typically manipulating a keyboard and mouse to provide control commands and / or input to the application associated with the GUI. Other forms of functionally adaptable user interfaces may also be implemented, such as an audio interface utilizing voice prompts output via a speaker and user voice commands input via a microphone.

[0131] It should be understood that the architectural context of computer system 1500 (i.e., combined transaction processing and positioning server 1500) is presented only as an example. Therefore, in some arrangements, one or more features of server 1500 may be omitted. Furthermore, in some arrangements, one or more features of server 1500 may be combined together. Furthermore, in some arrangements, one or more features of server 1500 may be separated into one or more component parts.

[0132] Fig.11An alternative implementation of a combined transaction processing and positioning server (i.e., computer system 1500) is shown. In an alternative implementation, the combined transaction processing and positioning server can generally be described as a physical device including at least one processor 1002 and at least one memory 904 including computer program code. The at least one memory 1004 and the computer program code are configured to, together with the at least one processor 1002, cause the combined transaction processing and positioning server to perform the operations described in the steps of method 700. The combined transaction processing and positioning server may also include a transaction processing module 806, a data module 906, an identification module 908, a positioning module 910, a mapping module 912, and a partitioning module 914. The memory 1004 computer program code stores the processor 1002 compiled to cause each of the modules 806 to 912 to perform their respective functions. The transaction processing module 806 performs operations related to Fig. 9 The data module 906, the identification module 908, the positioning module 910, the mapping module 912 and the partitioning module 914 perform the same functions as described for the same transaction processing module in FIG. Fig.10 The same functions are described for the same corresponding modules in .

[0133] Those skilled in the art will appreciate that many changes and / or modifications may be made to the present disclosure as shown in the specific embodiments without departing from the scope of the specification as broadly described. Therefore, the present embodiments are to be considered in all aspects as illustrative and not restrictive.

Claims

1. A method for adaptively determining a position of a moving object relative to a target object, the method comprising: In response to the request message including the location information of the target object, identifying the latitude and longitude of the location of the target object; identifying position information of a mobile object near the target object based on the identified latitude and longitude of the target object; as well as The position of the mobile object relative to the target object is adaptively determined based on the recognized position information.

2. The method according to claim 1, wherein: The step of identifying the latitude and longitude of the location of the target object further comprises: Identifying location information of a road network on which the target object is traveling; and Identify the relative distance of the starting position of the target object.

3. The method according to claim 2, wherein: The step of adaptively determining the position of the mobile object relative to the target object based on the identified position information further comprises: When more than one of the moving objects is identified, the moving object closest to the target object is identified.

4. The method according to claim 3, wherein: The step of adaptively determining the position of the mobile object relative to the target object based on the identified position information further comprises: More than one of the moving objects are mapped relative to the target object.

5. The method according to claim 4, wherein: The step of mapping more than one of the moving objects relative to the target object further comprises: The graph edges are partitioned based on the position information of the mobile object.

6. The method according to claim 2, further comprising: The position of the target object is mapped onto the road network to obtain a relative position of the target object in a road map, wherein the road map includes the road network.

7. A system for adaptively determining a position of a moving object relative to a target object, 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, with the at least one processor, cause the system to at least: In response to the request message including the location information of the target object, identifying the latitude and longitude of the location of the target object; identifying position information of a mobile object near the target object based on the identified latitude and longitude of the target object; as well as The position of the mobile object relative to the target object is adaptively determined based on the recognized position information.

8. The system according to claim 7, wherein: Identifying the latitude and longitude of the location of the target object further comprises: Identifying location information of a road network on which the target object is traveling; and Relative distance of the starting position of the identified target object.

9. The system according to claim 8, wherein: Adaptively determining the position of the mobile object relative to the target object based on the identified position information further comprises: When more than one of the moving objects is identified, the moving object closest to the target object is identified.

10. The system according to claim 9, wherein: Adaptively determining the position of the mobile object relative to the target object based on the identified position information further comprises: More than one of the moving objects are mapped relative to the target object.

11. The system according to claim 10, wherein: The step of mapping more than one of the moving objects relative to the target object further comprises: The graph edges are partitioned based on the position information of the mobile object.

12. The system according to claim 8, further configured to: Mapping the position of the target object onto the road network to obtain the relative position of the target object in the road map, wherein: The road map includes the road network.

Images