Method and system for adaptively predicting provision of service

Abstract

The present disclosure relates generally to a method and system for adaptively predicting a provision of a service, the method comprising: receiving, from a database, data in response to an input request indicating for a service at a target time, the data indicating information relating to the service at a time of receiving the input request; and generating, at a processor, a metric for predicting the provision of the service based on the data, the metric indicating a probability of provision of the service within a predefined time period from the target time.

Description

METHOD AND SYSTEM FOR ADAPTIVELY PREDICTING PROVISION OF SERVICETECHNICAL FIELD

[0001] The present disclosure relates generally to method and system for adaptively predicting a provision of a service.BACKGROUND

[0002] In various service industries, such as ride-hailing, food delivery, grocery delivery, and other on-demand services, accurately predicting the likelihood of service provision is crucial in optimising resource allocation, increasing operational efficiency, and improving user satisfaction. However, existing techniques for forecasting or predicting service provision often rely on historical data or static models, which may not fully account for real-time changes in market conditions, such as fluctuations in supply and demand.

[0003] One conventional technique involves the use of a Confirm Allocation Rate (CAR) signal, derived from confirmed service allocations over a fixed time period. While CAR signals provide some insights into market conditions, it is limited by its dependence on historical data and past service confirmations, resulting in delayed response to real-time changes in supply and demand conditions. Moreover, the use of a fixed time period for prediction limits its ability to adapt to changing market conditions. This approach does not account for real-time variability in market conditions, such as sudden increases in demand for the service or variability in service provider availability. Consequently, these conventional methods may produce inaccurate predictions that do not reflect the current market condition, leading to inefficient resource allocation.

[0004] Accordingly, there exists a need to provide a novel method and system for adaptively predicting a provision of a service to address the above issues, and more particularly, to improve the accuracy of service provision predictions.

[0005] 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

[0006] In a first aspect, the present disclosure provides a method for adaptively predicting a provision of a service, the method comprising: receiving, from a database, data in response to an input request indicating for a service at a target time, the data indicating information relating to the service at a time of receiving the input request; and generating, at a processor, a metric for predicting the provision of the service based on the data, the metric indicating a probability of provision of the service within a predefined time period from the target time.

[0007] In a second aspect, the present disclosure provides a system for adaptively predicting a provision of a service, the system comprising: at least one processor; and at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the system at least to: receive, from a database, data in response to an input request indicating for a service at a target time, the data indicating information relating to the service at a time of receiving the input request; and generate a metric for predicting the provision of the service based on the data, the metric indicating a probability of provision of the service within a predefined time period from the target time.

[0008] Additional benefits and advantages of the disclosed embodiments will become apparent from the specification and drawings. The benefits and / or advantages may be individually obtained by the various embodiments and features of the specification and drawings, which need not all be provided in order to obtain one or more of such benefits and / or advantages.BRIEF DESCRIPTION OF THE DRAWINGS

[0009] 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 drawings, in which:

[0010] Figure 1 shows a block diagram illustrating a system for adaptively predicting a provision of a service according to various embodiments of the present disclosure.

[0011] Figure 2 shows a block diagram illustrating various components of system for adaptively predicting a provision of a service according to an embodiment of the present disclosure.

[0012] Figure 3 shows a flow chart illustrating a method for adaptively predicting a provision of a service according to an embodiment of the present disclosure.

[0013] Figure 4 shows a schematic diagram illustrating exemplary time periods for which a probability of a service being provided during each time period is determined according to various embodiments of the present disclosure.

[0014] Figure 5 shows a schematic diagram illustrating an inference process implemented by a model for adaptively predicting a provision of a service according to various embodiments of the present disclosure.

[0015] Figure 6 shows a schematic diagram illustrating a training process implemented by a model for adaptively predicting a provision of a service according to various embodiments of the present disclosure.

[0016] Figure 7 shows a flow chart illustrating an inference process implemented by a service provision prediction server according to an embodiment of the present disclosure.

[0017] Figure 8 shows a flow chart illustrating a training process implemented by a service provision prediction server according to an embodiment of the present disclosure.

[0018] Figure 9 shows a schematic diagram illustrating an exemplary training logic according to various embodiments of the present disclosure.

[0019] Figure 10 shows a schematic diagram illustrating an exemplary test time logic according to various embodiments of the present disclosure.

[0020] Figures 11 and 12 show a schematic diagram of a general-purpose computer system upon which the coordination server of Figure 1 can be practiced.

[0021] Figure 13 shows an alternative computer device to implement the coordination server of Figure 1.

[0022] Figure 14 shows a schematic diagram of a general-purpose computer system upon which the service provision prediction server of Figure 1 can be practiced.

[0023] Figure 15 shows an alternative computer device to implement the service provision prediction server of Figure 1.

[0024] Figure 16 shows a schematic diagram of a general-purpose computer system upon which a combined coordination and service provision prediction server of Figure 1 can be practiced.

[0025] Figure 17 shows an alternative computer device to implement a combined coordination and service provision prediction server of Figure 1.

[0026] Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been depicted to scale. For example, the dimensions of some of the elements in the illustrations, block diagrams or flowcharts may be exaggerated in respect to other elements to help to improve understanding of the present embodiments.DETAILED DESCRIPTION

[0027] The following detailed description is merely exemplary in nature and is not intended to limit the invention or the application and uses of the invention. Furthermore, there is no intention to be bound by any theory presented in the preceding background of the invention or the following detailed description. It is the intent of this invention to provide a method and system for adaptively predicting a provision of a service.Terms Description

[0028] Service - The term "service" used herein refers to a task or a set of tasks requested by a requestor and provided by a provider. Examples of services include ride-hailing, food delivery, grocery delivery, or any other on-demand service. In various embodiments described below, a provision of a service may refer to an allocation of a service or a fulfilment or completion of a service.

[0029] Input request - The term "input request" used herein refers to a request made by a user for a particular service at a specific time.

[0030] Target time - The term "target time" used herein refers to the specific time at which the requested service is expected or required to be provided. The target time may be a future point in time after the input request is received, or it may coincide with the time of receiving the input request.

[0031] Information (relating to the service) - The term "information" used herein describes market conditions for the service, such as the demand from consumers or requestors and the supply from service providers associated with the requested service, and may be stored as data in a database. Examples of information include a location of the service (e.g., geohash, latitudinal and longitudinal coordinates, city ID) , a number of requests or orders for the service (e.g., demand size) , a number of available providers (e.g., available drivers) , a type of the service, a real time (e.g., actual time of receiving the request) , a number of fulfilled or completed requests or orders, a rate of service allocation within a certain time period, a number of confirmed allocations of the service within a certain time period, a certain hour of a day (e.g., peak or non-peak hour) , a certain day of a week (e.g., weekday or weekend) , a specific day of a year (e.g., holiday) , or a combination thereof.

[0032] Metric (for predicting the provision of the service) - The term "metric" used herein refers to a measurement of the likelihood of the service being provided within a specific time period relative to the target time. The metric may be used to determine a predicted time required to provide the service and / or a predicted range of time required to provide the service. In various embodiments described below, the metric may comprise a probability that the service will be allocated to a provider of the service within the predefined time period and / or a probability that the service will be fulfilled or completed by the provider within the predefined time period.

[0033] Predefined time period - The term "predefined time period" used herein refers to a duration relative to the target time (e.g., a time bound) during which the likelihood of the service being provided is determined. This time period may span before or after the target time. In various embodiments described below, the term "time period" may be used interchangeably with "time bound" , and different predefined time period may be defined according to the location of the service (e.g., city-specific time bounds) .

[0034] Probability of provision of the service - The term "probability of provision of the service" used herein refers to a numerical value between 0 and 1 that represents a likelihood that the requested service will be provided. In various embodiments described below, the probability of provision of a service within a predefined time period from the target time represents the likelihood that the requested service will be provided within the predefined time period from the target time, where 0 indicates no probability that the service will be provided within the predefined time period from the target time, and 1 indicates a 100%probability that the service will be provided within the predefined time period from the target time.

[0035] Feature (of the service) - The term "feature" used herein refers to a characteristic of the service. Examples include a location of the service, a type of service, a requestor of the service, a provider of the service, and a payment type.

[0036] Aggregated metric - The term "aggregated data" used herein refers to a combined metric generated by aggregating multiple metrics based on one or more features of the service. In various embodiments described below, the aggregation process may involve combining metrics with different predefined time periods according to specific criteria. For example, metrics with different predefined time periods may be combined according to pre-specific criteria at the city level, such as city-specific predefined time periods or time bounds.

[0037] Attribute (of the data) - The term "attribute" used herein refers to a characteristic of the data received from the database, such as a location of the requested service (e.g., geohash, latitudinal and longitudinal coordinates, city ID) , a service type (e.g., ride-hailing, delivery) , a requestor (e.g., membership tier) , a provider (e.g., vehicle type) , and a payment type (e.g., cash or cashless payment) .

[0038] Aggregated data - The term "aggregated data" used herein refers to a combined data generated by aggregating data based on one or more of its attributes.

[0039] Parameter (of a model) - The term "parameter" used herein refers to a variable of a model (e.g., weight or bias) that defines its behaviour or characteristics. In various embodiments described below, the parameters may be represented as numerical values and adjusted during a training process through optimisation algorithms to minimise loss and improve prediction accuracy.

[0040] Reference value (representing provision of the service) - The term "reference value" used herein refers to a value representing whether the service is provided, and may be denoted by a binary value of 0 or 1. In various embodiments described below, the provision of the service is indicated by a ground truth label. For example, if the service is provided within the predefined time period, the reference value would be 1; otherwise, it would be 0.

[0041] Predicted (range of) time required to provide the service - The term "predicted time" used herein refers to the estimated time at which the requested service is expected to be provided. Similarly, the term "predicted range of time" refers to a range of time (e.g., time frame) within which the requested service is expected to be provided.Exemplary Embodiments

[0042] Where reference is made in any one or more of the accompanying drawings to steps and / or features, which have the same reference numerals, those steps and / or features have for the purposes of this description the same function (s) or operation (s) , unless the contrary intention appears.

[0043] It is to be noted that the discussions contained in the "Background" section and that above relating to prior art arrangements relate to discussions of methods which form public knowledge through their use. Such methods should not be interpreted as a representation by the present inventor (s) or the patent applicant that such methods in any way form part of the common general knowledge in the art.

[0044] Some portions of the description which follows are explicitly or implicitly presented 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 data processing arts to convey most effectively 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. The steps are those requiring physical manipulations of physical quantities, such as electrical, magnetic or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated.

[0045] Unless specifically stated otherwise, and as apparent from the following, it will be appreciated that throughout the present specification, discussions utilising terms such as "receiving" , "calculating" , "determining" , "updating" , "generating" , "initialising" , "outputting" , "receiving" , "retrieving" , "identifying" , "dispersing" , "authenticating" or the like, refer to the action and processes of a computer system, or similar electronic device, that manipulates and transforms 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 devices.

[0046] The present specification also discloses apparatus for performing the operations of the methods. Such apparatus may be specially constructed for the required purposes, or may comprise 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 particular computer or other apparatus. Various machines may be used with programs in accordance with the teachings herein. Alternatively, the construction of more specialised apparatus to perform the required method steps may be appropriate. The structure of a computer will appear from the description below.

[0047] In addition, the present specification also implicitly discloses a computer program, in that it would be apparent to the person skilled in the art that the individual steps of the method described herein may be put into effect by computer code. The computer program is not intended to be limited to any particular programming language and implementation thereof. It will be appreciated that a variety of programming languages and coding thereof may be used to implement the teachings of the disclosure contained herein. Moreover, the computer program is not intended to be limited to any particular control flow. There are many other variants of the computer program, which can use different control flows without departing from the spirit or scope of the invention.

[0048] Furthermore, 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 storage devices such as magnetic or optical disks, memory chips, or other storage devices suitable for interfacing with a computer. The computer readable medium may also include a hard-wired medium such as exemplified in the Internet system, or wireless medium such as exemplified in the GSM mobile telephone system. The computer program when loaded and executed on such a computer effectively results in an apparatus that implements the steps of the preferred method.

[0049] According to various embodiments of the present disclosure, the process of adaptively predicting a provision of a service can be implemented through a system. Figure 1 shows a block diagram illustrating a system 100 for adaptively predicting a provision of a service. Further, the system 100 may enable a transaction for a good or service, and / or a request for a good or service (e.g., ride-hailing service, delivery) between a requestor (e.g., consumer) and a provider (e.g., driver) . Herein, the requestor and the provider may be referred to as "users" ; and a request for a product of the provider from the requestor may be referred to as a coordination request or a transaction request.

[0050] The system comprises a requestor device 102, a provider device 104, an acquirer server 106, a coordination server 108, an issuer server 110 and a service provision prediction server 112.

[0051] A user may be any suitable type of entity, which may include a consumer, company, corporation or governmental entity (i.e., requestor) who is looking to request for a product via a coordination server 108, and an application developer, company, corporation or governmental entity (i.e., provider) who is looking to sell or provide a good or service via the coordination server 108.

[0052] A requestor device 102 is associated with a customer (or requestor) who is a party to, for example, a request for a good or service that occurs between the requestor device 102 and the provider device 104. The requestor device 102 may be a computing device such as a desktop computer, an interactive voice response (IVR) system, a smartphone, a laptop computer, a personal digital assistant computer (PDA) , a mobile computer, a tablet computer, and the like.

[0053] The requestor device 102 may include user credentials (e.g., a user account) of a requestor to enable the requestor device 102 to be a party to a transaction (e.g., a service request) . If the requestor has a user account, the user account may also be included (i.e., stored) in the requestor device 102. For example, a mobile device (which is a requestor device 102) may have the user account of the customer stored in the mobile device.

[0054] In one example arrangement, the requestor device 102 is a computing device in the form of a watch or similar wearable and is fitted with a wireless communications interface (e.g., an NFC interface) . The requestor device 102 can then electronically communicate with the provider device 104 regarding a 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.

[0055] A provider device 104 is associated with a provider who is also a party to the request for a good or service that occurs between the requestor 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 smartphone, a laptop computer, a personal digital assistant computer (PDA) , a mobile computer, a tablet computer, and the like.

[0056] Hereinafter, the term "provider" refers to a service provider and any third party associated with providing a good or service for purchase via the provider device 104. Therefore, the user account of a provider refers to both the user account of a provider and the user account of a third party (e.g., route or service coordinator, platform operator, application developer) associated with the provider.

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

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

[0059] An acquirer server 106 is associated with an acquirer who may be an entity (e.g. a company or organisation) which issues (e.g. establishes, manages, administers) a payment account (e.g. a financial bank account) of a merchant (e.g., 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 that are used to establish communication with another server (e.g., the coordination server 108) by exchanging messages with and / or passing information to the other server. The acquirer server 106 forwards the payment transaction relating to a transaction or transport request to the coordination server 108.

[0060] A coordination server 108 is configured to carry out processes relating to a user account by, for example, forwarding data and information associated with the transaction to the other servers in the system 100, such as the service provision prediction server 112. In an example, the coordination server 108 may provide data and information associated with a request that may be used for predicting a provision of a service by the service provision prediction server 112. An image or list may be determined based on an outcome of the process, e.g., an image showing a predicted time required to provide a service based on the information.

[0061] An issuer server 110 is associated with an issuer and may include one or more computing devices that are used to perform a payment transaction. The issuer may be an entity (e.g. a company or organisation) which issues (e.g. establishes, manages, administers) a transaction credential or a payment account (e.g. a financial bank account) associated with the owner of the requestor device 102. As discussed above, the issuer server 110 may include one or more computing devices that are used to establish communication with another server (e.g., the coordination server 108) by exchanging messages with and / or passing information to the other server.

[0062] The coordination server 108 may be a server that hosts software application programs for processing transaction or coordination requests, for example, purchasing of a good or service by a user. The coordination server 108 may also be configured for processing coordination requests between a requestor and a provider. The coordination server communicates with other servers (e.g., service provision prediction server 112) concerning transaction or coordination requests. The coordination server 108 may communicate with the service provision prediction server 112 to facilitate generation of metric for predicting the provision of the service associated with the transaction or coordination requests. The coordination server 108 may use a variety of different protocols and procedures in order to process the transaction or coordination requests.

[0063] In an example, the coordination server 108 may receive from one user device (such as the requestor device 102 or the provider device 104) data and information associated with a request that may be used for predicting a provision of a service by the service provision prediction server 112 and provide the data and information to the service provision prediction server 112 for use in predicting the provision of the service.

[0064] Additionally, transactions that may be performed via the coordination server 108 include good or service purchases, credit purchases, debit transactions, fund transfers, account withdrawals, etc. The coordination server 108 may be configured to process transactions via cash-substitutes, which may include payment cards, letters of credit, checks, payment accounts, tokens, etc.

[0065] The coordination server 108 is usually managed by a service provider that may be an entity (e.g. a company or organisation) which operates to process transaction or coordination requests. The coordination server 108 may include one or more computing devices that are used for processing transaction or coordination requests.

[0066] A user account may be an account of a user who is registered at the coordination server 108. The user can be a customer, a service provider (e.g., a ride-hailing or delivery service provider) , or any third parties (e.g., route or service coordinator, platform operator, application developer) who want to use the coordination server. A user who is registered to a coordination server 108 or a service provision prediction server 112 will be called a registered user. A user who is not registered to the coordination server 108 or service provision prediction server 112 will be called a non-registered user.

[0067] The coordination server 108 may also be configured to manage the registration of users. A registered user has a user account which includes details and data of the user. The registration step is called on-boarding. A user may use either the requestor device 102 or the provider device 104 to perform on-boarding to the coordination server 108.

[0068] The on-boarding process for a user is performed by the user through one of the requestor device 102 or the provider device 104. In one arrangement, the user downloads an app (which includes, or otherwise provides access to, the API to interact with the coordination server 108) to the requestor device 102 or the provider device 104. In another arrangement, the user accesses a website (which includes, or otherwise provides access to, the API to interact with the coordination server 108) on the requestor device 102 or the provider device 104. The user is then able to interact with the service provision prediction server 112. The user may be a requestor or a provider associated with the requestor device 102 or the provider device 104, respectively.

[0069] Details of the registration include, for example, name of the user, address of the user, emergency contact, blood type or other healthcare information, next-of-kin contact, permissions to retrieve data and information from the requestor device 102 and / or the provider device 104. Alternatively, another mobile device may be selected instead of the requestor device 102 and / or the provider device 104 for retrieving the details / data. Once on-boarded, the user would have a user account that stores all the details / data.

[0070] It may not be necessary to have a user account at the coordination server 108 to access the functionalities of the coordination server 108. However, there may be functions that are available only to a registered user for example the provision of means to pay after the service request is fulfilled or to pay for a service request using a credit card or an electronic wallet. The term "user" will be used to collectively refer to both registered and non-registered users. A user may interchangeably be referred to as a requestor (e.g. a person who purchases a good or a service and creates a purchase order) or a provider (e.g. a person who provides the good or the service to fulfil the purchase order) .

[0071] The coordination server 108 may be configured to communicate with, or may include, a database 109 via connection 130. The connection 130 may be over a network (e.g., a local area network, a wide area network, the Internet, etc. ) . The database 109 stores user details / data as well as data corresponding to a transaction (or transaction data) . Examples of the 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, User ID (e.g., consumer and driver) , User Name, User Contact, Payment Account ID, as well as locations, time and date relating to the transaction of goods or services.

[0072] A service provision prediction server 112 may be a server that hosts software application programs for predicting a provision of a service. The service provision prediction server 112 may be implemented as shown in Figures 13, 15, and 17.

[0073] The database 113 stores data and information obtained, for example in the form of order requests from a user device (such as the requestor device 102 or the provider device 104. Such data may be geo-tagged with a geographical coordinate (e.g. latitudinal and longitudinal coordinates, geohash) and map-matched to locate a location using location coordinates. The database 113 may be a component of the service provision prediction server 112. In an example, the database 113 may be a database managed by an external entity and the database 113 is a server that, based on a request received from a user device (such as the requestor device 102 or the provider device 104) or the coordination server 108, retrieve data and information associated with the request (e.g., time of receiving a request for a service, location of the service, type of service, requestor of the service, provider of the service, payment type, number of requests for the service, number of available providers for the service, etc. ) and transmit the data to the user device or the coordination server 108. Alternatively, a module such as a data reception module may store the data instead of the database 113, wherein the data reception module may be integrated as part of the service provision prediction server 112, or may be external to the service provision prediction server 112.

[0074] Use of the term 'server' herein can mean a single computing device or a plurality of interconnected computing devices which operate together to perform a particular function. That is, the server may be contained within a single hardware unit or be distributed among several or many different hardware units.

[0075] The requestor device 102 is in communication with the provider device 104 via a connection 114. The connection 114 may be an ad hoc connection (e.g., via NFC communication, Bluetooth, etc. ) or over a network (e.g., the Internet) . The requestor device 102 is also in communication with the service provision prediction server 112 via a connection 122. The connections 114, 122 may be a network connection (e.g., the Internet) . The requestor device 102 may also be connected to a cloud that facilitates the system 100 for predicting a provision of a service. For example, the requestor device 102 can send a signal or data to the cloud directly via an ad hoc connection (e.g., via NFC communication, Bluetooth, etc. ) or over a network (e.g., the Internet) .

[0076] The provider device 104 is in communication with the requestor device 102 as described above, usually via the coordination server 108. The provider device 104 is, in turn, in communication with the acquirer server 106 via a connection 116. The provider device 104 is also in communication with the service provision prediction server 112 via a connection 126. The connections 116 and 126 may be network connections (e.g., provided via the Internet) . The provider device 104 may also be connected to a cloud that facilitates the system 100 for predicting a provision of a service. For example, the provider device 104 can send a signal or data to the cloud directly via an ad hoc connection (e.g., via NFC communication, Bluetooth, etc. ) or over a network (e.g., the Internet) .

[0077] The acquirer server 106, in turn, is in communication with the coordination server 108 via a connection 118. The coordination server 108, in turn, is in communication with an issuer server 110 via a connection 120. The connections 118 and 120 may be over a network (e.g., the Internet) .

[0078] The coordination server 108 is further in communication with the service provision prediction server 112 via a connection 124. The connection 124 may be over a network (e.g., a local area network, a wide area network, the Internet, etc. ) . In one arrangement, the coordination server 108 and the service provision prediction server 112 are combined and the connection 124 may be an interconnected bus.

[0079] The service provision prediction server 112, in turn, is in communication with a database 113 via a connection 128. The connection 128 may be a network connection (e.g., provided via the Internet) . The service provision prediction server 112 may also be connected to a cloud that facilitates the system 100 for predicting a provision of a service. For example, the service provision prediction server 112 can send a signal or data to the cloud directly via a wireless ad hoc connection (e.g., via NFC communication, Bluetooth, etc. ) or over a network (e.g., the Internet) .

[0080] In the illustrative embodiment, each of the devices 102, 104, and the 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 APIs may be part of a user interface that may include graphical user interfaces (GUIs) , Web-based interfaces, programmatic interfaces such as application programming interfaces (APIs) and / or sets of remote procedure calls (RPCs) corresponding to interface elements, messaging interfaces in which the interface elements correspond to messages of a communication protocol, and / or suitable combinations thereof. Examples of APIs include the REST API, and the like. For example, it is possible for at least one of the requestor device 102 and the provider device 104 to receive or submit a request for a service in response to an enquiry shown on the GUI running on the respective API.

[0081] Currently, various products (e.g., goods or services) use marketplace health signals to dynamically and automatically adapt to changes in market conditions. For example, during a surge in food demand coupled with a drop in fulfilment rates, search radius of users could be reduced to limit long-distance demand (e.g., request for a service) , and batching strategies might be adjusted (e.g., by relaxing constraints) to promote more order batching. However, as mentioned above, existing marketplace health signals such as CAR signal rely on historical data (e.g., confirmed allocation of past services) , and has several drawbacks including noise, incomplete coverage, and delayed responses to changes in supply and demand. Specifically, CAR is calculated as the ratio between the number of confirmed service / order allocations and the total number of services / orders (e.g., confirmed service / order allocations and services / orders pending allocation) in the past several minutes, This reliance on historical data results in delayed responses to real-time changes in market conditions. Moreover, CAR has limitations such as incomplete coverage, where the CAR signal becomes null (e.g., 0 / 0) when there are no orders made in the past several minutes (e.g., in areas with sparse demand) , and noise, where the CAR signal fluctuates significantly (e.g., between 0 and 1) depending on the allocation outcomes, particularly in low-demand situations with only a few orders (e.g. fewer than 5 orders) in the past several minutes. To address these limitations, the present invention introduces a machine learning model that takes in real-time supply and demand signals to generate a more accurate and reliable marketplace health indicator (e.g., metric for predicting a provision of a service) . Accordingly, various embodiments described in the present disclosure provides a method and system that can more accurately predict a provision of a service.

[0082] Figure 2 shows a block diagram illustrating various components of a system 200 for predicting a provision of a service according to an embodiment of the present disclosure. The system 200 may comprise a data reception module 202, a metric generation module 204, a data aggregation module 206, a difference determination module 208, a model parameter adjustment module 210, and a required time prediction module 212. In an alternative embodiment, such components or modules are comprised on, or implemented as part of, a processor of the system 200.

[0083] As shown in the exemplified method for predicting a provision of a service in Figure 3 and with reference to the time periods shown in Figure 4, the system 200 or a processor of the system 200, when in operation, is configured to perform the following steps:· step 302: receiving, from a database, data in response to an input request indicating for a service at a target time (e.g., target time 404) , the data indicating information relating to the service at a time of receiving the input request (e.g., time 402) ; and● step 304: generating a metric for predicting the provision of the service based on the data, the metric indicating a probability of provision of the service within a predefined time period (e.g., time period 406-414) from the target time.

[0084] The data reception module 202 is configured to perform step 302, while the metric generation module 204 is configured to perform step 304. The information may include at least one of: a location of the service, a number of requests for the service, and a number of available providers for the service. The metric may comprise at least one of: (i) a probability that the service will be allocated to a provider of the service within the predefined time period, and (ii) a probability that the service will be completed by the provider within the predefined time period. The data in the database may be updated at a predetermined periodicity.

[0085] Additionally or alternatively, the metric generation module 204 may be configured to generate a plurality of metrics based on the data, each of the plurality of metrics indicating a probability of provision of the service within a different predefined time period (e.g., time period 406-414) from the target time, and aggregate the plurality of metrics based on a feature of the service to generate at least one aggregated metric. The feature of the service may include at least one of: a location of the service, a service type, a requestor of the service, a provider of the service, and a payment type.

[0086] Additionally or alternatively, the data aggregation module 206 may be configured to aggregate the data received from the database based on an attribute of the data to generate aggregated data. The metric generation module 204 may then be configured to generate the metric based on the aggregated data. The attribute of the data may include at least one of: a location of the service, a service type, a requestor of the service, a provider of the service, a payment type, and a predefined time interval from the time of receiving the input request.

[0087] Additionally or alternatively, the metric generation module 204 may be configured to generate the metric using parameters of a model, and the difference determination module 208 may be configured to determine a difference between the probability of provision of the service and a reference value representing provision of the service within the predefined time period. Then, the model parameter adjustment module 210 may be configured to adjust the parameters of the model to minimise the difference.

[0088] Additionally or alternatively, the difference determination module 208 and the model parameter adjustment module 210 may be configured to determine the difference and adjust the parameters of the model at a predetermined periodicity.

[0089] Additionally or alternatively, the required time prediction module 212 may be configured to determine at least one of: a predicted time required to provide the service and a predicted range of time required to provide the service from the metric.

[0090] Additionally or alternatively, an allocation module (not shown) may be configured to allocate the service to a provider of the service based on the metric.

[0091] In various embodiments, a model that predicts a provision of a service is provided. In one implementation, the model may predict the provision of the service using a predicted allocation rate (PAR) signal with time bound. The PAR signal represents a probability that the service will be allocated to a provider of the service within a predefined time period, whereby the generalised PAR signal, denoted as PAR (x, y, L) , is defined as the probability that an order, created x minute from the current timestamp and in location L, is allocated within y minutes since creation.

[0092] The PAR signal may be used in allocating the service to the provider of the service. For example, when the PAR is low, the price of the service may increase for users requesting the service. Additionally, the search radius for available service providers (e.g., merchants, drivers, restaurants) may be reduced, resulting in fewer service providers being displayed to the users. In some implementations, service providers located in areas with higher PAR may be ranked higher than other service providers on a listing page displayed to the users. Alternatively, when the PAR is low, the estimated time of arrival (ETA) or estimate time of delivery of the service displayed to the user may be higher.

[0093] In another implementation, the model may predict the provision of the service using a predicted fulfilment rate (PFR) signal with time bound. The PFR signal represents a probability that the service will be fulfilled or completed by a provider of the service within a predefined time period, whereby the generalised predicted fulfilment rate (PFR) , denoted as PFR(x, y, L) , is similarly defined as the probability that an order, created x minute from the current timestamp and in location L, is fulfilled or completed within y minutes since creation.

[0094] In yet another implementation, the model may predict the provision of the service using both PAR and PFR signals with different time bounds simultaneously.

[0095] As an example, the structure of the model may be based on machine learning techniques such as extreme gradient boosting (XGBoost) , long-short term memory (LSTM) or multi-layer perceptron (MLP) .

[0096] The following describes one implementation of the present disclosure, where the model predicts a provision of a service using PAR signals. The operations of the model can be categorised into two main processes - a training process and an inference process.Inference

[0097] Figure 5 shows an inference process implemented by a model 500 for predicting a provision of a service (e.g., by using a PAR signal) according to various embodiments of the present disclosure.

[0098] As an example, steps 702-708 of the inference process (shown in Figure 7) may be implemented by the model 500.

[0099] During the inference process, in response to receiving an input request (e.g., at time 402) indicating for a service at a target time (e.g., target time 404) in step 702, the model 500 may proceed to step 704, where it receives, from a database, data indicating information relating to the service at the time of receiving the input request (e.g., real-time supply and demand signals 502 and contextual information 504) . In step 706, the model 500 may aggregate the received data based on an attribute of the data (e.g., location - geohash 6 512, 514, 516) to generate aggregated data. For example, if the granularity of location L is geohash 6, all geohash 6 may be enumerated, and the corresponding supply and demand information may be collected as features. Then, in step 708, the model 500 may generate a metric (e.g., PAR signal with various time bounds y for each aggregate-level location L) for predicting the provision of the service based on the aggregated data. This metric indicates a probability of provision of the service within a predefined time period (e.g., time period 406) from the target time.

[0100] Although not shown in Figure 7, the model 500 may also generate a plurality of metrics (e.g., PAR signals 506, 508, 510) based on the data, each of the plurality of metrics indicating a probability of provision of the service within a different predefined time period (e.g., time period 406-414) from the target time. These metrics may them be aggregated based on a feature (e.g., location - city) of the service (e.g., combine PARs with different time bounds y according to some pre-specified city-level criteria, such as city-specific time bounds) to generate at least one aggregated metric.Training

[0101] Figure 6 shows a training process implemented by a model 600 for predicting a provision of a service (e.g., by using a PAR signal) according to various embodiments of the present disclosure.

[0102] As an example, steps 702-708 (shown in Figure 7) and steps 802-804 (shown in Figure 8) of the training process may be implemented by the model 600.

[0103] The model 600 may be trained using samples comprising past input request (e.g., order 602 created x minutes ago) . Similar to the inference process, in response to receiving an input request (e.g., order 602 created x minutes ago) indicating for a service at a target time (e.g., current time) in step 702, the model 600 may proceed to step 704, where it receives, from a database, data indicating information relating to the service at the time of receiving the input request (e.g., supply and demand signals 608 and contextual information 610 from x minutes ago) . In step 706, the model 600 may aggregate the received data based on an attribute of the data (e.g., location - geohash 6 604) to generate aggregated data. For example, if the granularity of location L is geohash 6, the supply and demand information at the geohash 6 and geophash 5 level may be considered. Then, in step 708, the model 600 may generate a metric (e.g., PAR signal 612) for predicting the provision of the service based on the aggregated data. This metric indicates a probability of provision of the service within a predefined time period from the target time (e.g., x minutes ago) . Subsequently, the model 600 may carry out step 802, determining a difference (e.g., a loss) between the predicted probability of provision of the service and a reference value representing the actual provision of the service within the predefined time period (e.g., ground truth label 614 of the corresponding (time-bounded) allocation or fulfilment result) , and then adjusts its parameters to minimise this difference in step 804. In various implementations, the model 600 may use binary cross entropy as the loss / objective function to determine the difference between the predicted probability of provision of the service and the reference value.

[0104] With a comprehensive list of time bounds and corresponding PAR predictions, this approach enhances accuracy and offers improved flexibility, and allows for further derivation of average and quantile estimations of time required for allocation to be made easily.

[0105] Specifically, as compared to existing statistical signals, the model of the present disclosure is able to more effectively capture ongoing drifts in the supply and demand conditions and extrapolate these trends into the near future. This results in signals (e.g., PAR and PFR signals) that are both more timely and accurate. For example, unlike the existing CAR signal, which equally weights orders created 40 minutes ago with those created just now, thereby reflecting marketplace condition as it was 20 minutes ago on average, the model can extrapolate based on the changes in supply and demand conditions over the past 40 minutes. This enables the generation of real-time predictions and provides a more immediate and accurate reflection of marketplace conditions in the next several minutes. Additionally, while the existing CAR signal may be unavailable when no bookings occurred during a past period, the PAR signals overcome this limitation by generating meaningful predictions even when supply and demand are sparse. For instance, the model, being trained on a rich historical dataset, can predict allocation rates accurately even in low-demand situations. For example, if there is demand for only 1 order but 10 suppliers are available, the prediction would likely indicate a high allocation rate consistent with expectations. In contrast, the CAR signal would often report a value of 0 in such cases if the specific demand has not yet been allocated. This improving coverage, ensuring that reliable predictions can be generated even in sparse demand conditions. Furthermore, this approach allows for customisation across different cities, taking into account the marketplace conditions and allocation patterns unique to each location. While the CAR signal is defined on a fixed time period and is unable to account for regional differences, the generation of multiple PAR signals across different predefined time periods (e.g., PAR signals with varied time bounds) , allows for the creation of more accurate, location-specific aggregated metrics, such as city-specific signals.Workflow

[0106] The following describes exemplary workflow that may be implanted by the model in the present disclosure.

[0107] In an implementation, the training logic consists of two parts. Figure 9 shows an exemplary training logic 900 according to various embodiments of the present disclosure. In a first part 902, order samples (e.g., order 602) and relevant data (geohash 6 604, timestamp 606, supply and demand signals 608, contextual information 610, label 614) may be prepared at a predetermined periodicity (e.g., daily via a daily airflow data pipeline) for subsequently use in model training. In a second part 904, the model (e.g., PAR model 600) may be trained at another predetermined periodicity (e.g., weekly via a weekly model training pipeline) using the order samples and data collected from step 902, . As an example, the training logic may be implemented using two regular jobs on a machine learning pipeline platform: one for the daily data preparation and another for the weekly training of the PAR model.

[0108] Figure 10 shows an exemplary test time logic 1000 according to various embodiments of the present disclosure. In an implementation, the inference process may be implemented according to test time logic 1000. In test time logic 1000, geohash-level requests to the model may be generated every 1 minute using a function or method that collects and counts the demand and supply information for each geohash in the past several minutes (e.g., using Flink app 1002 in Apache Flink, an open-source stream processing framework) . For each request, the relevant supply and demand signals and data (e.g., real-time supply and demand signals 502 and contextual information 504) may be collected and processed. The PAR signals (e.g., PAR signals 506, 508, 510) are then generated using the PAR model (e.g., PAR model 500, 600) deployed on a model-servicing platform 1004. Finally, the generated PAR signals are published to a feature store 1006, where they are stored for use by downstream applications.Sample and Label

[0109] The following descriptions examples of samples and labels used in the training process.

[0110] For services such as food delivery and ride-hailing, the samples may be based on all relevant service requests (e.g., online food delivery orders or transport bookings) , and the label information may be obtained from the status of the service request (e.g., state of the booking) and the time taken to allocate the service (e.g., time-to-allocate value) . Examples of labels used in the training process may include:· Fulfilment rate (FR) : This label may indicate whether a service request has been successfully completed.· Allocation rate (AR) : This label may indicate whether a service has been successfully allocated to a provider.· Allocation rate (AR) in x minutes: This label may indicate whether the service has been allocated within a specific duration, such as within x minutes from the time of request, with adjustments made to remove invalid samples that involve cancellations before allocation.

[0111] In some implementations, users may submit requests for multiple taxi types (MTT) at the same time. As the fraction of these MTT bookings grows, model training directly with the final taxi types (TT) for such bookings could lead to substantial bias. For example, if many users request for different taxi types such as GrabCar and Taxi, and most of such bookings are marked as GrabCar, the AR for GrabCar may be underestimated, while the AR for Taxi may be overestimated, because the unallocated cases are mostly attributed to GrabCar rather than Taxi. To resolve this issue, it is necessary to evaluate the taxi type-level PAR against booking-level allocation facts. This can be achieved through booking-level PAR aggregation, assuming independence of PAR of different taxi types: Data

[0112] To reduce inference time and improve the efficiency of real-time prediction, only the latest data (e.g., data from the past minute) is used during inference. The data may be aggregated from the past sliding windows (e.g., predefined time interval from the time of receiving an input request) , thereby reducing noise.

[0113] For food delivery services, the data and relevant information include:· Demand information: This includes metrics related to consumer demand, including values associated with a CAR signal and a demand intent signal. This information may be considered at both the geohash 6 level and neighbouring geohash 6 regions, aggregated over one-minute intervals.· Supply information: This includes metrics related to the available supply, including values associated with hierarchical supply signal, such as online time, in-transit time, and fulfilment capacity. This information may be categorised by vehicle types (e.g., four-wheelers, two-wheelers) and aggregated across both time (e.g., one-minute intervals) and spatial dimensions (e.g., geohash 6 and neighbouring geohash 6 regions) .· Contextual information: This includes geographic coordinates (e.g., longitude and latitude) of the centre of geohash 6 regions, time-information such as hour of day and day of the week, city ID, payment methods (e.g., cash or cashless transactions) .

[0114] For ride-hailing services, the data and relevant information include:· Demand Information: This includes metrics related to current demand, such as the number of unique requests (UR) and unique check prices (UCP) for the service. This information may be considered at both the geohash 6 level and its neighbouring geohash 6 regions, aggregated over one-minute intervals.· Supply Information: This includes metrics related to the available supply, similar to those used in food delivery, including values associated with hierarchical supply signal, such as online time, in-transit time, and fulfilment capacity. This information may also be aggregated across both time (e.g., one-minute intervals) and spatial dimensions (e.g., geohash 6 and neighbouring geohash 6 regions) .● Contextual Information: This includes properties of the provider (e.g., taxi type) geographic coordinates (e.g., longitude and latitude) of the centre of geohash 6 regions, time-information such as hour of day and day of the week, city ID, payment methods (e.g., cash or cashless transactions) .

[0115] The following describes implementations of the present disclosure, focusing on induced outputs and downstream applications.City-specific Time-bound

[0116] In one implementation, the model may further generate a metric with city-specific time bounds adjustments (e.g., generating at least one aggregated metric by aggregating a plurality of metrics based on a location of the service) to address the challenge of using CAR or PAR values under a fixed time constraint. This implementation considers that fixed time bounds may not account for the unique characteristics and allocation configurations of different cities (e.g., city-specific information) , which may lead to lack of variation in certain cities.

[0117] To address this issue, city-specific time-bound PAR values may be utilised. For each city, a specific time-bound (e.g., time period 406-414) is determined by analysing the historical data, such as the quantiles of the actual time to allocate (TTA) . This city-specific time-bound is then applied to interpolate the corresponding PAR values from the model’s predictions. Advantageously, the inclusion of city-specific adjustments in such implementations can improve the variability of PAR values and strengthen their correlation with actual (e.g., ground truth) allocation rates and TTA, thereby providing a more accurate metric for predicting provision of a service.Induced TTA (Expected Values)

[0118] In another implementation, the model may further generate the time to allocate (TTA) expected values (EV) (e.g., determining a predicted time required to provide the service) based on an exhaustive list of time bounds (TB) (e.g., time period 406-414) and the corresponding PAR prediction (e.g., metric indicating a probability of provision of the service within the predefined time period from the target time) . In this implementation, it is assumed that there is a uniform probability distribution (e.g., uniform distribution of PAR) between adjacent time bounds. Specifically, the time bounds for PAR predictions (e.g., PAR (1min) , PAR(2min) , PAR (3min) ) are explicitly defined, such as 1 minute, 2 minutes, and 3 minutes. For each pair of adjacent time bounds (e.g., 1 minute and 2 minutes, or 2 minutes and 3 minutes) , a uniform distribution of allocation probability is assumed within the range defined by the adjacent time bounds. For instance, if PAR (1min) = 0.1 and PAR (2min) = 0.2, then the allocation probability at 1.5 minutes (i.e., PAR (1.5min) ) may be calculated as:

[0119] The TTA EV may be calculated by:· Determining the probability of TTA falling within each interval as: p=PAR (TBup) -PAR (TBlo) , where TBup and TBlo represent the upper and lower time bounds in the adjacent time bound pair, respectively.· Computing the average TTA for the interval as:  · Summing the products of p and TTA for all intervals to obtain the TTA EV.

[0120] This implementation assumes boundary conditions where PAR (TB=0) =0, and PAR(TB=1.01h) =1, where h represents hours. In other words, this means that the probability of allocation at 0 minutes is assumed to be 0%, and at 1.01 hours, it is assumed to be 100%.Induced TTA (Quantiles)

[0121] In another implementation, the model may further generate TTA quantiles (q-TTA) (e.g., determining a predicted range of time required to provide a service) . Similar to the previous implementation, this method also relies on an exhaustive list of time bounds (TB) (e.g., time period 406-414) and the corresponding PAR prediction (e.g., metric indicating a probability of provision of the service within the predefined time period from the target time) , and assumes that there is a uniform probability distribution between adjacent time bounds.

[0122] The q-TTA may be calculated by:● Identifying the largest TB where the corresponding PAR is no greater than a quantile (q), and mark this TB and the PAR as TBlo and PAR (TBlo)● Identifying the smallest TB where the corresponding PAR is greater than q, and mark this TB and the PAR as TBup and PAR (TBup) .· Linearly interpolating the q-TTA as:

[0123] Similarly, this implementation also assumes boundary conditions where PAR (TB=0) =0, and PAR (TB=1.01h) =1.

[0124] Figure 11 shows a schematic diagram of a general-purpose computer system 1100 upon which the coordination server 108 of Figure 1 can be practiced. The computer system 1100 includes: a computer module 1101, input devices such as a keyboard 1102, a mouse pointer device 1103, a scanner 1126, a camera 1127, and a microphone 1180; and output devices including a printer 1115, a display device 1114 and loudspeakers 1117. An external Modulator-Demodulator (Modem) transceiver device 1116 may be used by the computer module 1101 for communicating to and from a communications network 1120 via a connection 1121. The communications network 1120 may be a wide-area network (WAN) , such as the Internet, a cellular telecommunications network, or a private WAN. Where the connection 1121 is a telephone line, the modem 1116 may be a traditional "dial-up" modem. Alternatively, where the connection 1121 is a high capacity (e.g., cable) connection, the modem 1116 may be a broadband modem. A wireless modem may also be used for wireless connection to the communications network 1120.

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

[0126] The coordination server 108 uses the communications network 1120 to communicate with the provider device 104, the requestor device 102, the service provision prediction server 112 and the database 109 to receive commands and data. The coordination server 108 also uses the communications network 1120 to communicate with the provider device 104, the requestor device 102, the service provision prediction server 112 and the database 113 to send notification messages or data and information associated with order requests.

[0127] The computer module 1101 typically includes at least one processor unit 1105, and at least one memory unit 1106. For example, the memory unit 1106 may have semiconductor random access memory (RAM) and semiconductor read only memory (ROM) . The computer module 1101 also includes a number of input / output (I / O) interfaces including: an audio-video interface 1107 that couples to the video display 1114, loudspeakers 1117 and microphone 1180; an I / O interface 1113 that couples to the keyboard 1102, mouse 1103, scanner 1126, camera 1127 and optionally a joystick or other human interface device (not illustrated) ; and an interface 1108 for the external modem 1116 and printer 1115. In some implementations, the modem 1116 may be incorporated within the computer module 1101, for example within the interface 1108. The computer module 1101 also has a local network interface 1111, which permits coupling of the computer system 1100 via a connection 1123 to a local-area communications network 1122, known as a Local Area Network (LAN) . As illustrated in Figure 11, the local communications network 1122 may also couple to the wide network 1120 via a connection 1124, which would typically include a so-called "firewall" device or device of similar functionality. The local network interface 1111 may comprise an Ethernet circuit card, a  wireless arrangement or an IEEE 802.11 wireless arrangement; however, numerous other types of interfaces may be practiced for the interface 1111.

[0128] The I / O interfaces 1108 and 1113 may afford either or both of serial and parallel connectivity, the former typically being implemented according to the Universal Serial Bus (USB) standards and having corresponding USB connectors (not illustrated) . Storage devices 1109 are provided and typically include a hard disk drive (HDD) 1110. Other storage devices such as a floppy disk drive and a magnetic tape drive (not illustrated) may also be used. An optical disk drive 1112 is typically provided to act as a non-volatile source of data. Portable memory devices, such optical disks (e.g., CD-ROM, DVD, Blu-ray DiscTM) , USB-RAM, portable, external hard drives, and floppy disks, for example, may be used as appropriate sources of data to the coordination server 108.

[0129] The components 1105 to 1113 of the computer module 1101 typically communicate via an interconnected bus 1104 and in a manner that results in a conventional mode of operation of a computer system known to those in the relevant art. For example, the processor 1105 is coupled to the system bus 1104 using a connection 1118. Likewise, the memory 1106 and optical disk drive 1112 are coupled to the system bus 1104 by connections 1119. Examples of computers on which the described arrangements can be practised include IBM-PC's and compatibles, Sun Sparcstations, Apple MacTM or like computer systems.

[0130] The method of operating the coordination server 108, as shown in the processes of Figures 3, 7, and 8, may be implemented as one or more software application programs 1113 executable within the coordination server 108. In particular, the steps of the processes shown in Figures 3, 7, and 8 are effected by instructions 1131 (see Figure 12) in the software (i.e., computer program codes) 1133 that are carried out within the coordination server 108. The software instructions 1131 may be formed as one or more code modules, each for performing one or more particular tasks. The software may also be divided into two separate parts, in which a first part and the corresponding code modules performs the operation of the coordination server 108 and a second part and the corresponding code modules manages the API and corresponding user interfaces in the provider device 104, the requestor device 102, and on the display 1114. In other words, the second part of the software manages the interaction between (a) the first part and (b) any one of the provider device 104, the requestor device 102, and the operator of the server 108.

[0131] The software may be stored in a computer readable medium, including the storage devices described below, for example. The software is loaded into the coordination server 108 from the computer readable medium, and then executed by the computer system 1100. A computer readable medium having such software or computer program recorded on the computer readable medium is a computer program product. The use of the computer program product in the coordination server 108 preferably effects an advantageous apparatus for receiving / transmitting data and information associated with order requests that may be used for predicting a provision of a service by the service provision prediction server 112.

[0132] The software (i.e., computer program codes) 1133 is typically stored in the HDD 1110 or the memory 1106. The software 1133 is loaded into the computer system 1100 from a computer readable medium (e.g., the memory 1106) , and executed by the processor 1105. Thus, for example, the software 1133 may be stored on an optically readable disk storage medium (e.g., CD-ROM) 1125 that is read by the optical disk drive 1112. A computer readable medium having such software or computer program recorded on it is a computer program product. The use of the computer program product in the coordination server 108 preferably effects an apparatus for receiving / transmitting data and information associated with order requests that may be used for predicting a provision of a service by the service provision prediction server 112.

[0133] In some instances, the application programs 1133 may be supplied to the user encoded on one or more CD-ROMs 1125 and read via the corresponding drive 1112, or alternatively may be read by the user from the networks 1120 or 1122. Still further, the software can also be loaded into the coordination server 108 from other computer readable media. Computer readable storage media refers to 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 1105. Examples of such storage media include floppy disks, magnetic tape, CD-ROM, DVD, Blu-rayTM Disc, a hard disk drive, a ROM or integrated circuit, USB memory, a magneto-optical disk, or a computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external of the computer module 1101. Examples of transitory or non-tangible computer readable transmission media that may also participate in the provision of software, application programs, instructions and / or data to the computer module 1101 include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on Websites and the like.

[0134] The second part of the application programs 1133 and the corresponding code modules mentioned above may be executed to implement one or more API of the coordination server 108 with associated graphical user interfaces (GUIs) to be rendered or otherwise represented upon the display 1114 or the display of the provider device 104 and the requestor device 102. Through manipulation of typically the keyboard 1102 and the mouse 1103, an operator of the server 108 and the application may manipulate the interface in a functionally adaptable manner to provide controlling commands and / or input to the applications associated with the GUI (s) . Similarly, on the provider device 104 and the requestor device 102, a user of those devices 102, 104 manipulate the input devices (e.g., touch screen, keyboard, mouse, etc. ) of those devices 102, 104 in a functionally adaptable manner to provide controlling commands and / or input to the applications associated with the GUI(s) . Other forms of functionally adaptable user interfaces may also be implemented, such as an audio interface utilising speech prompts output via the loudspeakers 1117 and user voice commands input via the microphone 1180. These other forms of functionally adaptable user interfaces may also be implemented on the provider device 104 and the requestor device 102.

[0135] Figure 12 is a detailed schematic block diagram of the processor 1105 and a "memory" 1134. The memory 1134 represents a logical aggregation of all the memory modules (including the HDD 1109 and semiconductor memory 1106) that can be accessed by the computer module 1101 in Figure 11.

[0136] When the computer module 1101 is initially powered up, a power-on self-test (POST) program 1150 executes. The POST program 1150 is typically stored in a ROM 1149 of the semiconductor memory 1106 of Figure 11. A hardware device such as the ROM 1149 storing software is sometimes referred to as firmware. The POST program 1150 examines hardware within the computer module 1101 to ensure proper functioning and typically checks the processor 1105, the memory 1134, and a basic input-output systems software (BIOS) module 1151, also typically stored in the ROM 1149, for correct operation. Once the POST program 1150 has run successfully, the BIOS 1151 activates the hard disk drive 1110 of Figure 11. Activation of the hard disk drive 1110 causes a bootstrap loader program 1152 that is resident on the hard disk drive 1110 to execute via the processor 1105. This loads an operating system 1153 into the RAM memory 1106, upon which the operating system 1153 commences operation. The operating system 1153 is a system level application, executable by the processor 1105, to fulfil various high-level functions, including processor management, memory management, device management, storage management, software application interface, and generic user interface.

[0137] The operating system 1153 manages the memory 1134 to ensure that each process or application running on the computer module 1101 has sufficient memory in which to execute without colliding with memory allocated to another process. Furthermore, the different types of memory available in the server 108 of Figure 11 must be used properly so that each process can run effectively. Accordingly, the aggregated memory 1134 is not intended to illustrate how particular segments of memory are allocated (unless otherwise stated) , but rather to provide a general view of the memory accessible by the server 108 and how such is used.

[0138] As shown in Figure 12, the processor 1105 includes a number of functional modules including a control unit 1139, an arithmetic logic unit (ALU) 1140, and a local or internal memory 1148, sometimes called a cache memory. The cache memory 1148 typically includes a number of storage registers 1144-1146 in a register section. One or more internal busses 1141 functionally interconnect these functional modules. The processor 1105 typically also has one or more interfaces 1142 for communicating with external devices via the system bus 1104, using a connection 1118. The memory 1134 is coupled to the bus 1104 using a connection 1119.

[0139] The application program 1133 includes a sequence of instructions 1131 that may include conditional branch and loop instructions. The program 1133 may also include data 1132 which is used in execution of the program 1133. The instructions 1531 and the data 1132 are stored in memory locations 1128, 1129, 1130 and 1135, 1136, 1137, respectively. Depending upon the relative size of the instructions 1131 and the memory locations 1128-1130, a particular instruction may be stored in a single memory location as depicted by the instruction shown in the memory location 1130. Alternately, an instruction may be segmented into a number of parts each of which is stored in a separate memory location, as depicted by the instruction segments shown in the memory locations 1128 and 1129.

[0140] In general, the processor 1105 is given a set of instructions which are executed therein. The processor 1105 waits for a subsequent input, to which the processor 1105 reacts to by executing another set of instructions. Each input may be provided from one or more of a number of sources, including data generated by one or more of the input devices 1102, 1103, data received from an external source across one of the networks 1120, 1122, data retrieved from one of the storage devices 1106, 1109 or data retrieved from a storage medium 1125 inserted into the corresponding reader 1112, all depicted in Figure 11. The execution of a set of the instructions may in some cases result in output of data. Execution may also involve storing data or variables to the memory 1134.

[0141] The disclosed association management and payment initiation arrangements use input variables 1154, which are stored in the memory 1134 in corresponding memory locations 1155, 1156, 1157. The association management and payment initiation arrangements produce output variables 1161, which are stored in the memory 1134 in corresponding memory locations 1162, 1163, 1164. Intermediate variables 1158 may be stored in memory locations 1159, 1160, 1166 and 1167.

[0142] Referring to the processor 1105 of Figure 11, the registers 1144, 1145, 1146, the arithmetic logic unit (ALU) 1140, and the control unit 1139 work together to perform sequences of micro-operations needed to perform "fetch, decode, and execute" cycles for every instruction in the instruction set making up the program 1133. Each fetch, decode, and execute cycle comprises: a fetch operation, which fetches or reads an instruction 1131 from a memory location 1128, 1129, 1130; a decode operation in which the control unit 1139 determines which instruction has been fetched; and an execute operation in which the control unit 1139 and / or the ALU 1140 execute the instruction.

[0143] Thereafter, a further fetch, decode, and execute cycle for the next instruction may be executed. Similarly, a store cycle may be performed by which the control unit 1139 stores or writes a value to a memory location 1132.

[0144] Each step or sub-process in the processes of Figures 3, 7, and 8 is associated with one or more segments of the program 1133 and is performed by the register section 1144, 1145, 1147, the ALU 1140, and the control unit 1139 in the processor 1105 working together to perform the fetch, decode, and execute cycles for every instruction in the instruction set for the noted segments of the program 1133.

[0145] It is to be understood that the structural context of the coordination server 108 is presented merely by way of example. Therefore, in some arrangements, one or more features of the coordination server 108 may be omitted. Also, in some arrangements, one or more features of the coordination server 108 may be combined. Additionally, in some arrangements, one or more features of the coordination server 108 may be split into one or more component parts.

[0146] Figure 13 shows an alternative computer device to implement the coordination server 108 of Figure 1 (i.e., the computer system 1300) . In the alternative implementation, the coordination server 108 may be generally described as a physical device comprising at least one processor 1302 and at least one memory 1304 including computer program codes. The at least one memory 1304 and the computer program codes are configured to, with the at least one processor 1302, cause the coordination server 108 to facilitate the operations described in the processes of Figures 3, 7, and 8. The coordination server 108 may also include a coordination module 1306. The memory 1304 stores computer program code that the processor 1302 compiles to have each of the modules performs their respective functions.

[0147] With reference to Figure 1, the coordination module 1306 performs the function of communicating with the requestor device 102 and the provider device 104; and the acquirer server 106 and the issuer server 110 to respectively receive and transmit a transaction and data. Further, the coordination module 1306 may provide data and information associated with order requests that may be used for predicting a provision of a service by the service provision prediction server 112.

[0148] Figures 14 shows a schematic diagram of a general-purpose computer system 1400 upon which the service provision prediction server 112 of Figure 1 can be practiced. The computer system 1400 includes: a computer module 1401, input devices such as a keyboard 1402, a mouse pointer device 1403, a scanner 1426, a camera 1427, and a microphone 1480; and output devices including a printer 1415, a display device 1414 and loudspeakers 1417. An external Modulator-Demodulator (Modem) transceiver device 1416 may be used by the computer module 1401 for communicating to and from a communications network 1420 via a connection 1421. The communications network 1420 may be a wide-area network (WAN) , such as the Internet, a cellular telecommunications network, or a private WAN. Where the connection 1421 is a telephone line, the modem 1416 may be a traditional "dial-up" modem. Alternatively, where the connection 1421 is a high capacity (e.g., cable) connection, the modem 1416 may be a broadband modem. A wireless modem may also be used for wireless connection to the communications network 1420.

[0149] The input and output devices may be used by an operator who is interacting with the service provision prediction server 112. For example, the printer 1415 may be used to print reports relating to the status of the service provision prediction server 112.

[0150] The service provision prediction server 112 uses the communications network 1420 to communicate with the provider device 104, the requestor device 102, the coordination server 108, and the database 113 to receive commands and data. The service provision prediction server 112 also uses the communications network 1420 to communicate with the provider device 104, the requestor device 102, the coordination server 108 and the database 113 to send notification messages or data and information associated with order requests.

[0151] The computer module 1401 typically includes at least one processor unit 1405, and at least one memory unit 1406. For example, the memory unit 1406 may have semiconductor random access memory (RAM) and semiconductor read only memory (ROM) . The computer module 1401 also includes a number of input / output (I / O) interfaces including: an audio-video interface 1407 that couples to the video display 1414, loudspeakers 1417 and microphone 1480; an I / O interface 1413 that couples to the keyboard 1402, mouse 1403, scanner 1426, camera 1427 and optionally a joystick or other human interface device (not illustrated) ; and an interface 1408 for the external modem 1416 and printer 1415. In some implementations, the modem 1416 may be incorporated within the computer module 1401, for example within the interface 1408. The computer module 1401 also has a local network interface 1411, which permits coupling of the computer system 1400 via a connection 1423 to a local-area communications network 1422, known as a Local Area Network (LAN) . As illustrated in Figure 14, the local communications network 1422 may also couple to the wide network 1420 via a connection 1424, which would typically include a so-called "firewall" device or device of similar functionality. The local network interface 1411 may comprise an Ethernet circuit card, a  wireless arrangement or an IEEE 802.11 wireless arrangement; however, numerous other types of interfaces may be practiced for the interface 1411.

[0152] The I / O interfaces 1408 and 1413 may afford either or both of serial and parallel connectivity, the former typically being implemented according to the Universal Serial Bus (USB) standards and having corresponding USB connectors (not illustrated) . Storage devices 1809 are provided and typically include a hard disk drive (HDD) 1410. Other storage devices such as a floppy disk drive and a magnetic tape drive (not illustrated) may also be used. An optical disk drive 1412 is typically provided to act as a non-volatile source of data. Portable memory devices, such optical disks (e.g., CD-ROM, DVD, Blu-ray DiscTM) , USB-RAM, portable, external hard drives, and floppy disks, for example, may be used as appropriate sources of data to the service provision prediction server 112.

[0153] The components 1405 to 1413 of the computer module 1401 typically communicate via an interconnected bus 1404 and in a manner that results in a conventional mode of operation of a computer system known to those in the relevant art. For example, the processor 1405 is coupled to the system bus 1404 using a connection 1418. Likewise, the memory 1406 and optical disk drive 1412 are coupled to the system bus 1404 by connections 1419. Examples of computers on which the described arrangements can be practised include IBM-PC's and compatibles, Sun Sparcstations, Apple MacTM or like computer systems.

[0154] The methods of operating the service provision prediction server 112, as shown in the processes of Figures 3, 7, and 8, may be implemented as one or more software application programs 1433 executable within the service provision prediction server 112. In particular, the steps of the processes shown in Figures 3, 7, and 8 effected by instructions (see corresponding component 1131 in Figure 12) in the software (i.e., computer program codes) 1433 that are carried out within the service provision prediction server 112. The software instructions 1131 may be formed as one or more code modules, each for performing one or more particular tasks. The software may also be divided into two separate parts, in which a first part and the corresponding code modules performs the operation of the service provision prediction server 112 and a second part and the corresponding code modules manages the API and corresponding user interfaces in the provider device 104, the requestor device 102, and on the display 1414. In other words, the second part of the software manages the interaction between (a) the first part and (b) any one of the provider device 104, the requestor device 102, and the operator of the service provision prediction server 112.

[0155] The software may be stored in a computer readable medium, including the storage devices described below, for example. The software is loaded into the service provision prediction server 112 from the computer readable medium, and then executed by the computer system 1400. A computer readable medium having such software or computer program recorded on the computer readable medium is a computer program product. The use of the computer program product in the service provision prediction server 112 preferably effects an advantageous apparatus for predicting a provision of a service as well as for receiving / transmitting data and information associated with order requests that may be used for predicting the provision of the service by the service provision prediction server 112.

[0156] The software (i.e., computer program codes) 1433 is typically stored in the HDD 1410 or the memory 1406. The software 1433 is loaded into the computer system 1400 from a computer readable medium (e.g., the memory 1406) , and executed by the processor 1405. Thus, for example, the software 1433 may be stored on an optically readable disk storage medium (e.g., CD-ROM) 1425 that is read by the optical disk drive 1412. A computer readable medium having such software or computer program recorded on it is a computer program product. The use of the computer program product in the service provision prediction server 112 preferably effects an apparatus for predicting a provision of a service as well as for receiving / transmitting data and information associated with order requests that may be used for predicting the provision of the service by the service provision prediction server 112.

[0157] In some instances, the application programs 1433 may be supplied to the user encoded on one or more CD-ROMs 1425 and read via the corresponding drive 1412, or alternatively may be read by the user from the networks 1420 or 1422. Still further, the software can also be loaded into the service provision prediction server 112 from other computer readable media. Computer readable storage media refers to any non-transitory tangible storage medium that provides recorded instructions and / or data to the service provision prediction server 112 for execution and / or processing by the processor 1405. Examples of such storage media include floppy disks, magnetic tape, CD-ROM, DVD, Blu-rayTM Disc, a hard disk drive, a ROM or integrated circuit, USB memory, a magneto-optical disk, or a computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external of the computer module 1401. Examples of transitory or non-tangible computer readable transmission media that may also participate in the provision of software, application programs, instructions and / or data to the computer module 1401 include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on Websites and the like.

[0158] The second part of the application programs 1433 and the corresponding code modules mentioned above may be executed to implement one or more API of the service provision prediction server 112 with associated graphical user interfaces (GUIs) to be rendered or otherwise represented upon the display 1414 or the display of the provider device 104 and the requestor device 102. Through manipulation of typically the keyboard 1402 and the mouse 1403, an operator of the service provision prediction server 112 and the application may manipulate the interface in a functionally adaptable manner to provide controlling commands and / or input to the applications associated with the GUI (s) . Similarly, on the provider device 104 and the requestor device 102, a user of those devices 102, 104 manipulate the input devices (e.g., touch screen, keyboard, mouse, etc. ) of those devices 102, 104 in a functionally adaptable manner to provide controlling commands and / or input to the applications associated with the GUI (s) . Other forms of functionally adaptable user interfaces may also be implemented, such as an audio interface utilising speech prompts output via the loudspeakers 1417 and user voice commands input via the microphone 1480. These other forms of functionally adaptable user interfaces may also be implemented on the provider device 104 and the requestor device 102.

[0159] It is to be understood that the structural context of the coordination server 108 is presented merely by way of example. Therefore, in some arrangements, one or more features of the coordination server 108 may be omitted. Also, in some arrangements, one or more features of the service provision prediction server 112 may be combined. Additionally, in some arrangements, one or more features of the service provision prediction server 112 may be split into one or more component parts.

[0160] Figure 15 shows an alternative computer device to implement the service provision prediction server 112 of Figure 1. In the alternative implementation, the service provision prediction server 112 may be generally described as a physical device comprising at least one processor 1502 and at least one memory 1504 including computer program codes. The at least one memory 1504 and the computer program codes are configured to, with the at least one processor 1502, cause the service provision prediction server 112 of Figure 1 to perform the operations described in the processes of Figures 3, 7, and 8. The service provision prediction server 112 may include various modules 202-212 of the system 200 described in Figure 2. The memory 1504 stores computer program code that the processor 1502 compiles to have each of the modules 202-212 performs their respective functions as described in Figure 2 and its accompanying description.

[0161] The service provision prediction server 112 may also include a data module 1506 configured to perform the functions of receiving data and information associated with order requests from the requestor device 102, provider device 104, coordination server 108, a cloud and other sources of information to facilitate the processes of Figures 3, 7, and 8. For example, the data module 1506 may be configured to receive from one user device (such as the requestor device 102 or the provider device 104) data and information associated with a request that may be used for predicting a provision of a service by the service provision prediction server 112 and provide the data and information to the service provision prediction server 112 for use in predicting the provision of the service.

[0162] Figure 16 shows a schematic diagram of a general-purpose computer system upon which a combined coordination and service provision prediction server 108, 112 of Figure 1 can be practiced. The computer system 1600 includes: a computer module 1601, input devices such as a keyboard 1602, a mouse pointer device 1603, a scanner 1626, a camera 1627, and a microphone 1680; and output devices including a printer 1615, a display device 1614 and loudspeakers 1617. An external Modulator-Demodulator (Modem) transceiver device 1616 may be used by the computer module 1601 for communicating to and from a communications network 1620 via a connection 1621. The communications network 1620 may be a wide-area network (WAN) , such as the Internet, a cellular telecommunications network, or a private WAN. Where the connection 1621 is a telephone line, the modem 1616 may be a traditional "dial-up" modem. Alternatively, where the connection 1621 is a high capacity (e.g., cable) connection, the modem 1616 may be a broadband modem. A wireless modem may also be used for wireless connection to the communications network 1620.

[0163] The input and output devices may be used by an operator who is interacting with the combined coordination and service provision prediction server 108, 112. For example, the printer 1615 may be used to print reports relating to the status of the combined coordination and service provision prediction server 108, 112.

[0164] The combined coordination and service provision prediction server 108, 112 uses the communications network 1620 to communicate with the provider device 104, the requestor device 102, and the databases 109, 113 to receive commands and data. In one example, the databases 109, 113 may be combined, as shown in Figure 16. The combined coordination and service provision prediction server 108, 112 also uses the communications network 1620 to communicate with the provider device 104, the requestor device 102 and the databases 109, 113 to send notification messages or data and information associated with order requests.

[0165] The computer module 1601 typically includes at least one processor unit 1605, and at least one memory unit 1606. For example, the memory unit 1606 may have semiconductor random access memory (RAM) and semiconductor read only memory (ROM) . The computer module 1601 also includes a number of input / output (I / O) interfaces including: an audio-video interface 1607 that couples to the video display 1614, loudspeakers 1617 and microphone 1680; an I / O interface 1613 that couples to the keyboard 1602, mouse 1603, scanner 1626, camera 1627 and optionally a joystick or other human interface device (not illustrated) ; and an interface 1608 for the external modem 1616 and printer 1615. In some implementations, the modem 1616 may be incorporated within the computer module 1601, for example within the interface 1608. The computer module 1601 also has a local network interface 1611, which permits coupling of the computer system 1600 via a connection 1623 to a local-area communications network 1622, known as a Local Area Network (LAN) . As illustrated in Figure 16, the local communications network 1622 may also couple to the wide network 1620 via a connection 1624, which would typically include a so-called "firewall" device or device of similar functionality. The local network interface 1611 may comprise an Ethernet circuit card, a  wireless arrangement or an IEEE 802.11 wireless arrangement; however, numerous other types of interfaces may be practiced for the interface 1611.

[0166] The I / O interfaces 1608 and 1613 may afford either or both of serial and parallel connectivity, the former typically being implemented according to the Universal Serial Bus (USB) standards and having corresponding USB connectors (not illustrated) . Storage devices 1609 are provided and typically include a hard disk drive (HDD) 1610. Other storage devices such as a floppy disk drive and a magnetic tape drive (not illustrated) may also be used. An optical disk drive 1612 is typically provided to act as a non-volatile source of data. Portable memory devices, such optical disks (e.g., CD-ROM, DVD, Blu-ray DiscTM) , USB-RAM, portable, external hard drives, and floppy disks, for example, may be used as appropriate sources of data to the combined coordination and service provision prediction server 108, 112.

[0167] The components 1605 to 1613 of the computer module 1601 typically communicate via an interconnected bus 1604 and in a manner that results in a conventional mode of operation of a computer system known to those in the relevant art. For example, the processor 1605 is coupled to the system bus 1604 using a connection 1618. Likewise, the memory 1606 and optical disk drive 1612 are coupled to the system bus 1604 by connections 1619. Examples of computers on which the described arrangements can be practised include IBM-PC's and compatibles, Sun Sparcstations, Apple MacTM or like computer systems.

[0168] The methods of operating the combined coordination and service provision prediction server 108, 112, as shown in the processes of Figures 3, 7, and 8, may be implemented as one or more software application programs 1633 executable within the combined coordination and service provision prediction server 108, 112. In particular, the steps of the processes shown in Figures 3, 7, and 8 are effected by instructions (see corresponding component 1131 in Figure 12) in the software (i.e., computer program codes) 1633 that are carried out within the combined coordination and service provision prediction server 108, 112. The software instructions 1131 may be formed as one or more code modules, each for performing one or more particular tasks. The software may also be divided into two separate parts, in which a first part and the corresponding code modules performs the operation of the combined coordination and service provision prediction server 108, 112 and a second part and the corresponding code modules manages the API and corresponding user interfaces in the provider device 104, the requestor device 102, and on the display 1614. In other words, the second part of the software manages the interaction between (a) the first part and (b) any one of the provider device 104, the requestor device 102, and the operator of the server 108, 112.

[0169] The software may be stored in a computer readable medium, including the storage devices described below, for example. The software is loaded into the combined coordination and service provision prediction server 108, 112 from the computer readable medium, and then executed by the computer system 1600. A computer readable medium having such software or computer program recorded on the computer readable medium is a computer program product. The use of the computer program product in the combined coordination and service provision prediction server 108, 112 preferably effects an advantageous apparatus for predicting a provision of a service as well as for receiving / transmitting data and information associated with order requests that may be used for predicting the provision of the service by the combined coordination and service provision prediction server 108, 112.

[0170] The software (i.e., computer program codes) 1633 is typically stored in the HDD 1610 or the memory 1606. The software 1633 is loaded into the computer system 1600 from computer readable medium (e.g., the memory 1606) , and executed by the processor 1605. Thus, for example, the software 1633 may be stored on an optically readable disk storage medium (e.g., CD-ROM) 1625 that is read by the optical disk drive 1612. A computer readable medium having such software or computer program recorded on it is a computer program product. The use of the computer program product in the combined coordination and service provision prediction server 108, 112 preferably effects an apparatus for predicting a provision of a service as well as for receiving / transmitting data and information associated with order requests that may be used for predicting the provision of the service by the combined coordination and service provision prediction server 108, 112.

[0171] In some instances, the application programs 1633 may be supplied to the user encoded on one or more CD-ROMs 1625 and read via the corresponding drive 1612, or alternatively may be read by the user from the networks 1620 or 1622. Still further, the software can also be loaded into the combined coordination and service provision prediction server 108, 112 from other computer readable media. Computer readable storage media refers to any non-transitory tangible storage medium that provides recorded instructions and / or data to the combined coordination and service provision prediction server 108, 112 for execution and / or processing by the processor 1605. Examples of such storage media include floppy disks, magnetic tape, CD-ROM, DVD, Blu-rayTM Disc, a hard disk drive, a ROM or integrated circuit, USB memory, a magneto-optical disk, or a computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external of the computer module 1601. Examples of transitory or non-tangible computer readable transmission media that may also participate in the provision of software, application programs, instructions and / or data to the computer module 1601 include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on Websites and the like.

[0172] The second part of the application programs 1633 and the corresponding code modules mentioned above may be executed to implement one or more API of the combined coordination and service provision prediction server 108, 112 with associated graphical user interfaces (GUIs) to be rendered or otherwise represented upon the display 1614 or the display of the provider device 104 and the requestor device 102. Through manipulation of typically the keyboard 1602 and the mouse 1603, an operator of the server 108, 112 and the application may manipulate the interface in a functionally adaptable manner to provide controlling commands and / or input to the applications associated with the GUI (s) . Similarly, on the provider device 104 and the requestor device 102, a user of those devices 102, 104 manipulate the input devices (e.g., touch screen, keyboard, mouse, etc. ) of those devices 102, 104 in a functionally adaptable manner to provide controlling commands and / or input to the applications associated with the GUI (s) . Other forms of functionally adaptable user interfaces may also be implemented, such as an audio interface utilising speech prompts output via the loudspeakers 1617 and user voice commands input via the microphone 1680. These other forms of functionally adaptable user interfaces may also be implemented on the provider device 104 and the requestor device 102.

[0173] It is to be understood that the structural context of the coordination server 108 is presented merely by way of example. Therefore, in some arrangements, one or more features of the coordination server 108 may be omitted. Also, in some arrangements, one or more features of the combined coordination and service provision prediction server 108, 112 may be combined. Additionally, in some arrangements, one or more features of the combined coordination and service provision prediction server 108, 112 may be split into one or more component parts.

[0174] Figure 17 shows an alternative computer device to implement a combined coordination and service provision prediction server 108, 112 of Figure 1. In the alternative implementation, the combined coordination and service provision prediction server 108, 112 may be generally described as a physical device comprising at least one processor 1702 and at least one memory 1704 including computer program codes. The at least one memory 1704 and the computer program codes are configured to, with the at least one processor 1702, cause the combined coordination and service provision prediction server 108, 112 to perform the operations described in the processes of Figures 3, 7, and 8. The combined coordination and service provision prediction server 108, 112 may include various modules 202-212 of the system 200 described in Figure 2. The memory 1704 stores computer program code that the processor 1702 compiles to have each of the modules 202-212 performs their respective functions as described in Figure 2 and its accompanying description.

[0175] The combined coordination and service provision prediction server 108, 112 may also include a coordination module 1708 configured to perform the function of communicating with the requestor device 102 and the provider device 104; and the acquirer server 106 and the issuer server 110 to respectively receive and transmit data and information associated with order requests that may be used for predicting a provision of a service.

[0176] The combined coordination and service provision prediction server 108, 112 may also include a data module 1706 configured to perform the functions of receiving data and information associated with order requests from the requestor device 102, provider device 104, coordination server 108, a cloud and other sources of information to facilitate the processes of Figures 3, 7, and 8. For example, the data module 1706 may be configured to receive from one user device (such as the requestor device 102 or the provider device 104) data and information associated with a request that may be used for predicting a provision of a service by the combined coordination and service provision prediction server 108, 112 and provide the data and information to the combined coordination and service provision prediction server 108, 112 for use in predicting the provision of the service.

[0177] The foregoing describes only some embodiments of the present disclosure, and modifications and / or changes can be made thereto without departing from the scope and spirit of the invention, the embodiments being illustrative and not restrictive.

Claims

1.A method for adaptively predicting a provision of a service, the method comprising:receiving, from a database, data in response to an input request indicating for a service at a target time, the data indicating information relating to the service at a time of receiving the input request; andgenerating, at a processor, a metric for predicting the provision of the service based on the data, the metric indicating a probability of provision of the service within a predefined time period from the target time.2.The method of claim 1, further comprising:generating, at the processor, a plurality of metrics based on the data, each of the plurality of metrics indicating a probability of provision of the service within a different predefined time period from the target time.3.The method of claim 2, further comprising:aggregating, at the processor, the plurality of metrics based on a feature of the service to generate at least one aggregated metric.4.The method of claim 3, wherein the feature of the service includes at least one of: a location of the service, a service type, a requestor of the service, a provider of the service, and a payment type.5.The method of claim 1, further comprising:aggregating, at the processor, the data received from the database based on an attribute of the data to generate aggregated data; andgenerating, at the processor, the metric based on the aggregated data.6.The method of claim 5, wherein the attribute of the data includes at least one of: a location of the service, a service type, a requestor of the service, a provider of the service, a payment type, and a predefined time interval from the time of receiving the input request.7.The method of claim 1, wherein the generating the metric comprises generating the metric using parameters of a model, the method further comprising:determining, at the processor, a difference between the probability of provision of the service and a reference value representing provision of the service within the predefined time period; andadjusting, at the processor, the parameters of the model to minimise the difference.8.The method of claim 1, wherein the data in the database is updated at a predetermined periodicity.9.The method of claim 7, wherein determining the difference and adjusting the parameters of the model are performed at a predetermined periodicity.10.The method of claim 1, further comprising:allocating, at the processor, the service to a provider of the service based on the metric.11.The method of claim 1, further comprising:determining, at the processor, at least one of: a predicted time required to provide the service and a predicted range of time required to provide the service from the metric.12.The method of claim 1, wherein the information includes at least one of: a location of the service, a number of requests for the service, and a number of available providers for the service.13.The method of claim 1, wherein the metric comprises at least one of: (i) a probability that the service will be allocated to a provider of the service within the predefined time period, and (ii) a probability that the service will be completed by the provider within the predefined time period.14.A system for adaptively predicting a provision of a service, the system comprising:at least one processor; andat least one memory including computer program code,the at least one memory and the computer program code configured to, with the at least one processor, cause the system at least to:receive, from a database, data in response to an input request indicating for a service at a target time, the data indicating information relating to the service at a time of receiving the input request; andgenerate a metric for predicting the provision of the service based on the data, the metric indicating a probability of provision of the service within a predefined time period from the target time.15.The system of claim 14, wherein the at least one memory and the computer program code is configured to, with the at least one processor, cause the system at least to, further:generate a plurality of metrics based on the data, each of the plurality of metrics indicating a probability of provision of the service within a different predefined time period from the target time.16.The system of claim 15, wherein the at least one memory and the computer program code is configured to, with the at least one processor, cause the system at least to, further:aggregate the plurality of metrics based on a feature of the service to generate at least one aggregated metric.17.The system of claim 16, wherein the feature of the service includes at least one of: a location of the service, a service type, a requestor of the service, a provider of the service, and a payment type.18.The system of claim 14, wherein the at least one memory and the computer program code is configured to, with the at least one processor, cause the system at least to, further:aggregate the data received from the database based on an attribute of the data to generate aggregated data; andgenerate the metric based on the aggregated data.19.The system of claim 18, wherein the attribute of the data includes at least one of: a location of the service, a service type, a requestor of the service, a provider of the service, a payment type, and a predefined time interval from the time of receiving the input request.20.The system of claim 14, wherein the at least one memory and the computer program code is configured to, with the at least one processor, cause the system at least to, further:generate the metric using parameters of a model;determine a difference between the probability of provision of the service and a reference value representing provision of the service within the predefined time period; andadjust the parameters of the model to minimise the difference.21.The system of claim 14, wherein the data in the database is updated at a predetermined periodicity.22.The system of claim 20, wherein the at least one memory and the computer program code is configured to, with the at least one processor, cause the system at least to, further:determine the difference and adjust the parameters of the model at a predetermined periodicity.23.The system of claim 14, wherein the at least one memory and the computer program code is configured to, with the at least one processor, cause the system at least to, further:allocate the service to a provider of the service based on the metric.24.The system of claim 14, wherein the at least one memory and the computer program code is configured to, with the at least one processor, cause the system at least to, further:determine at least one of: a predicted time required to provide the service and a predicted range of time required to provide the service from the metric.25.The system of claim 14, wherein the information includes at least one of: a location of the service, a number of requests for the service, and a number of available providers for the service.26.The system of claim 14, wherein the metric comprises at least one of: (i) a probability that the service will be allocated to a provider of the service within the predefined time period, and (ii) a probability that the service will be completed by the provider within the predefined time period.

Images