Method and system for adaptively adjusting a price for a service

Abstract

The present disclosure provides methods and systems for adaptively adjusting a price for a service. In some examples, there is provided a method comprising: determining, by a processor, for a price that is set for a service within an area, whether a demand for the service within the area matches a supply of the service within the area, the determination being based on a difference between a number of requests within the area for the service and a number of providers within the area providing the service, and a ratio between the number of providers and the number of requests; and adjusting, by the processor, the price for the service within the area based on the determination.

Description

[0001] Description

[0002] Title of Invention: Method and System for Adaptively Adjusting A Price For A Service

[0003] FIELD OF INVENTION

[0004] [1] The present disclosure relates broadly, but not exclusively, to methods and systems for adaptively adjusting a price for a service.

[0005] BACKGROUND

[0006] [2] Platforms that offer a service such as a ride or a delivery have to ensure that a suitable price is set based on supply (e.g., a number of providers providing the service) and demand (e.g., a number of requests for the service) of a service, so that demand and supply can be balanced. Various metrics relating to the supply and demand may be utilized to set and adjust a price for a service.

[0007] [3] However, traditional solutions largely focus on metrics like Fulfillment Rate (FR), Allocation Rate (AR), and surge values which are ineffective for identifying instances of, for example, over-conversion or under-conversion of demand. Furthermore, price adjustments based on the above metrics by traditional solutions are typically delayed and do not adaptively respond to market changes., A price that is adjusted based on such traditional solutions tend to be inaccurate, inefficient and less responsive also for balancing supply and demand for a service.

[0008] [4] A need therefore exists to provide methods and systems that seek to overcome or at least minimize the above mentioned challenges. SUMMARY

[0009] [5] According to a first aspect of the present disclosure, there is provided a method for adaptively adjusting a price for a service, the method comprising: determining, by a processor, for a price that is set for a service within an area, whether a demand for the service within the area matches a supply of the service within the area, the determination being based on a difference between a number of requests within the area for the service and a number of providers within the area providing the service, and a ratio between the number of providers and the number of requests; and adjusting, by the processor, the price for the service within the area based on the determination.

[0010] [6] According to a second aspect of the present disclosure, there is provided a system for adaptively adjusting a price for a service, 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: determine, for a price that is set for a service within an area, whether a demand for the service within the area matches a supply of the service within the area, the determination being based on a difference between a number of requests within the area for the service and a number of providers within the area providing the service, and a ratio between the number of providers and the number of requests; and adjust the price for the service within the area based on the determination. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] [7] 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:

[0012] [8] Fig. 1 illustrates a system for adaptively adjusting a price for a service according to various embodiments of the present disclosure.

[0013] [9] Fig. 2 is a schematic diagram of a pricing server, according to various embodiments of the present disclosure.

[0014]

[0010] Fig. 3A depicts an exemplary illustration of a supply smoothing kernel according to various embodiments of the present disclosure.

[0015]

[0011] Fig. 3B depicts an exemplary illustration of demand conversion score (DCS) and demand conversion ratio (DCR) distribution according to various embodiments of the present disclosure.

[0016]

[0012] Fig. 4 depicts an exemplary illustration of how a number of drivers that are available for providing a ride may be determined according to various embodiments

[0017]

[0013] Fig. 5 depicts an exemplary illustration of how a price check signal may be generated according to various embodiments.

[0018]

[0014] Fig. 6A depicts an exemplary illustration of a pricing simulation result for a service in Klang Valley according to various embodiments.

[0019]

[0015] Fig. 6B depicts an exemplary illustration of a manual multiplier set for pricing for a service in Klang Valley according to various embodiments.

[0020]

[0016] Fig. 6C depicts an exemplary illustration of a multiplier simulation result for a service on a workday at 8am morning peak hour according to various embodiments.

[0017] Fig. 6D depicts an exemplary illustration of a multiplier simulation result for a service on a workday at 6pm evening peak hour according to various embodiments.

[0021]

[0018] Fig. 6E depicts an exemplary illustration of a multiplier simulation result for a service at 12am according to various embodiments.

[0022]

[0019] Fig. 6F depicts an exemplary illustration of a multiplier simulation result for a service at 2pm according to various embodiments.

[0023]

[0020] Fig. 7 illustrates an example flow diagram for adaptively adjusting a price for a service according to various embodiments.

[0024]

[0021] Fig. 8A is a schematic block diagram of a general purpose computer system upon which the pricing server shown in Figs. 1 and 2 can be practiced.

[0025]

[0022] Fig. 8B is a schematic block diagram of a general purpose computer system upon which a combined transaction processing and pricing server of Fig. 1 can be practiced.

[0026]

[0023] Fig. 9 shows an example of a computing device to realize the transaction processing server shown in Fig. 1.

[0027]

[0024] Fig. 10 shows an example of a computing device to realize the pricing server shown in Figs. 1 and 2.

[0028]

[0025] Fig. 11 shows an example of a computing device to realize a combined transaction processing and pricing server shown in Fig. 1.

[0029]

[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.

[0030] DETAILED DESCRIPTION

[0031] Terms Description

[0027] A platform refers to a set of technologies that is used as a base for facilitating exchanges between two or more interdependent servers, entities and / or devices, for example between a requestor device (of a product or service) and a provider device (of the product or service). For example, a platform may offer a service provided by a provider such as a ride, delivery, or other similar services to a requestor. The requestor can typically access the platform via a website, an application, or other similar methods in order to make a request for the service. Further, a requestor may also submit a request for a price check for a service to the platform. It will be appreciated that, although a ride or delivery are used as examples for a service in the present disclosure, the methods disclosed herein adaptively adjusting a price may also be applicable to other types of services or even products, and the above examples are not exhaustive.

[0032]

[0028] A price for a service refers to an amount of currency that a requestor requesting a service is required to pay in order to receive the service. The currency may be money that is a currency of a country, or a cryptocurrency, a currency that is specific to at least the platform offering the service (e.g., tokens, credits, points, or other similar forms of inapplication currency specific to the platform), or other similar forms of currency. The price for a service may be set or adjusted (e.g., increased or decreased) adaptively according to methods discussed in the present disclosure. Depending on an area (a part or region in a town, city, country, or the world) in which a service is provided, a price that is set for a service may be bounded by a minimum price limit (e.g., a price limit at which the price cannot fall below) or bounded by a maximum price limit (e.g., a price limit at which the price cannot exceed).

[0033]

[0029] A demand for a service refers to a number of requests for a service, and a supply of the service refers to a number of providers for a service. Accordingly, the demand for the service matches the supply of the service if the number of requests for the service is the same as the number of providers of the service, and all requests for the service are successfully provided (e.g., each request is successfully converted into a paid and completed ride or delivery). A number of requests for a service within an area may be based on a maximum number of genuine requests for the service within the area (e.g., not including mere price checks, requests that are cancelled within a certain period of time, repeated requests for a same service from a same user within a period of time, or other similar requests). A number of providers for a service within an area at a time period may be based on a maximum number of providers who are available at the area at the time period to provide the service (e.g., not including providers who are offline, not located within the area at the time period, still handling a current service request, or other similar status). A determination of whether the demand for the service matches the supply for the service may be made for each of one or more areas within which the service is provided and / or requested. For example, the determination may be based on a difference between a number of requests within the area for the service and a number of providers within the area providing the service (e.g., a demand conversion score (DCS)), as well as a ratio between the number of providers and the number of requests within the area (e.g., a demand conversion ratio (DCR)). In an example, the difference or ratio between supply and demand for a service in an area may be calculated based on a smoothed supply, in which the supply of the service within the area is processed by a smoothing function (e.g., a supply smoothing kernel, or other similar function) that takes into account supply of the service in one or more other areas. In another example, instead of utilizing a historical data based supply smoothing kernel, another way to consider a nearby area's supply of a service is to utilize a weighted sum of each area’s supply based on a probability of being allocated to a specific area's demand in real time.

[0034]

[0030] In at least some embodiments, a user may be any suitable type of entity, which may include a person, a consumer looking to purchase or order a product or service via a transaction processing server, a seller or merchant looking to sell a product or service via the transaction processing server, a motorcycle driver or pillion rider in a case of the user looking to book or provide a motorcycle ride via the transaction processing server, a car driver or passenger in a case of the user looking to book or provide a car ride via the transaction processing server, and other similar entity that selects or orders an item on the platform. A user who is registered to the transaction processing server will be called a registered user. A user who is not registered to the transaction processing server will be called a non-registered user. 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 requests for a product or service) or a provider (e.g. a person who provides the requested product or service to the requestor).

[0035]

[0031] In at least some embodiments, a pricing server is a server that hosts software application programs for adaptively adjusting a price for a service. The pricing server may be implemented as shown in the schematic diagram of Fig. 2.

[0032] In at least some embodiments, a transaction processing server is a server that hosts software application programs for processing payment transactions for, for example, a travel-ordination request, purchasing of a good or a service (e.g., resulting from a request for the service) by a user, and other similar services. The transaction processing server communicates with any other servers (e.g., a pricing server) concerning processing payment transactions relating to the purchasing of the good or service. For example, data relating to a purchase of a service or an item (e.g. a price for the service or item, a name of the item, a time stamp indicating date and time of purchase, session ID, item ID, user ID, country / city ID, a price, and other similar data) may be provided to the pricing server for processing and / or storing. The transaction processing server may use a variety of different protocols and procedures in order to process the payment and / or travel coordination requests. It will be appreciated that purchasing and ordering may be used interchangeably.

[0036]

[0033] Transactions that may be performed via a transaction processing server include product or service purchases, credit purchases, debit transactions, fund transfers, account withdrawals, etc. Transaction processing servers may be configured to process transactions via cash-substitutes, which may include payment cards, letters of credit, checks, payment accounts, etc.

[0037]

[0034] In at least some embodiments, the transaction processing server is usually managed by a service provider that may be an entity (e.g. a company or organization) which operates to process transaction requests (e.g., for ordering an item) and / or travel co-ordination requests. The transaction processing server may include one or more computing devices that are used for processing transaction requests and / or travel coordination requests.

[0038]

[0035] In at least some embodiments, a transaction account is an account of a user who is registered at a transaction processing server. The user can be a customer, a merchant providing a product for sale on a platform and / or for onboarding the platform, a hail provider (e.g., a driver), or any third parties (e.g., a courier) who want to use the transaction processing server. In certain circumstances, the transaction account is not required to use the transaction processing server. A transaction account includes details (e.g., name, address, vehicle, face image, user ID, etc.) of a user. The transaction processing server manages the transaction.

[0039]

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

[0040]

[0037] 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.

[0041]

[0038] Unless specifically stated otherwise, and as apparent from the following, it will be appreciated that throughout the present specification, discussions utilizing terms such as “extracting”, “processing”, “identifying”, “generating”, “detecting”, “grouping”, “ungrouping”, “regrouping”, “determining”, “merging”, “deleting”, “associating”, “selecting”, “calculating”, “storing”, “indicating”, “discerning”, 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.

[0042]

[0039] 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 scope of the specification.

[0043]

[0040] 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 hardwired 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.

[0044]

[0041] As previously mentioned, traditional solutions largely focus on metrics like Fulfillment Rate (FR), Allocation Rate (AR), and surge values. While these metrics provide valuable insights into pricing performance, they fall short of giving a holistic, granular view of the balance of demand and supply. These metrics often struggle to adapt to real-time changes and distinctly isolate the impacts of dynamic pricing from other influential factors. As such, they are not equipped to provide a nuanced understanding at an area and minute-level, limiting their effectiveness in identifying instances of over-conversion or under-conversion of demand. Further, a pricing system needs to give a price of a service quoted to a user before the user makes a request for the service. From high intent sessions (e.g., sessions involving a user checking the price of the service repeatedly) to real demand (e.g., the user making a request for a service) that needs to be fulfilled, the pricing system needs to predict what would happen in a near future (e.g., estimating the number of requests that are eventually made for the service) to determine a suitable price. Therefore, there may be uncertainty or bias existing from existing prediction or forecasting models, and a mechanism needs to be developed to help automatically correct decisions made by the pricing system in those underperforming scenarios. This thus forms the motivation behind the demand conversion index (DCI) and Pricing DCI (PDCI) as will be further discussed in the present disclosure. By offering a more granular, real-time view of demand conversion performance at the micro-level, DCI and PDCI can efficiently respond to real-time changes in one or more areas in which a service is provided. This novel approach optimizes demand conversion measurement and provides a more sophisticated understanding of marketplace balance, thereby advantageously enhancing the overall efficiency and pricing strategies for a service.

[0045]

[0042] Furthermore, traditional solutions often require significant manual effort for fare adjustments. This not only consumes valuable time but also introduces the risk of human error. Thus, a Flexi-Adaptive Demand Conversion Indices Tracking Controller (FACT-C) is proposed herein to address this issue by automating the price adjustment process, thereby reducing the need for manual intervention. In a fast-paced market, delays in adjusting prices can lead to missed opportunities and potential revenue loss. FACT-C tackles this issue by leveraging real-time DCI and pricing data to make immediate price adjustments. Furthermore, without an adaptive system, pricing can become inefficient and unresponsive to market changes. FACT-C overcomes this by making the pricing system auto-adaptive, allowing it to advantageously respond swiftly and effectively to changes in demand conversion indices, thus enhancing the efficiency and responsiveness of pricing adjustments, ultimately leading to improved revenue generation and customer satisfaction.

[0046]

[0043] The proposed DCI and PDCI metrics provide a unique way to categorize one or more areas (e.g., geohash6x1 minute instances, or other similar forms of areas) into, for example, Over-conversion (e.g., demand for a service is greater than supply for the service), Under-conversion (e.g., supply for a service is greater than demand for the service), and Sold Off statuses (e.g., demand for a service matches the supply for the service). These categories can indicate whether too many, too few, or just the right amount of demand instances are converted into a successful provision of the service, respectively. Taking this a step further, PDCI advantageously provides an additional layer of specificity by detecting whether over-conversion or under-conversion of an area is caused by dynamic pricing. DCI and PDCI thus enables the locating of conversion-related issues within any given timeframe and area.

[0047]

[0044] Unlike traditional solutions, the proposed solution offers room for dynamic, realtime responsiveness to fluctuations in demand and supply across specific areas and, for example, geohash 5 levels. As such, the DCI and PDCI advantageously enhance adaptability in adjusting a price for a service, making it possible to enact precise price changes in real-time to ensure optimal demand conversion rates.

[0045] Additionally, the use of DOI and PDCI allows for insightful retrospection, enabling reassessment and refinement of overarching pricing strategies and supply shaping efforts. This makes the proposed solution a powerful tool for the proactive management of conversion rates and continual improvement of how a service may be supplied and priced in relation to demand.

[0048]

[0046] Further, the implementation of FACT-C, with its ability to leverage real-time DCI and pricing data, enables immediate fare adjustments which is a significant improvement over the traditional slower, manual methods. By doing so, the time and effort required for fare adjustments is advantageously reduced, and the risk of human error is minimized. Another one of the key advantages of FACT-C is its ability to mitigate opportunity loss. In a fast-paced market, delays in fare adjustments can lead to missed opportunities. FACT-C addresses this issue by providing quicker responses, thereby reducing the chance of missed revenue-generating opportunities.

[0049]

[0047] Furthermore, FACT-C enhances the efficiency of pricing adjustments by making the system auto-adaptive, such that it can respond swiftly and effectively to changes in demand conversion indices. This feature advantageously ensures that the pricing system remains competitive and relevant in a dynamic market.

[0050]

[0048] Fig. 1 illustrates a block diagram of an example system 100 for adaptively adjusting a price for a service. In some embodiments, the system 100 enables a payment transaction for an item, a good or service, and / or a request for a ride or delivery of a physical item (e.g. one or more items) by a user (e.g., between a requestor and a provider).

[0051]

[0049] The system 100 comprises a requestor device 102, a provider device 104, an acquirer server 106, a transaction processing server 108, an issuer server 110, a pricing server 140 and a reference database 150.

[0052]

[0050] The requestor device 102 is in communication with a provider device 104 via a connection 112, and may be associated with a user. The connection 112 may be wireless (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 pricing server 140 via a connection 121, wherein the pricing server 140 may be configured to receive data relating to a request for a service or a price check request from the requestor device 102. The connection 121 may be via a network (e.g., the Internet). The requestor device 102 may also be connected to a cloud that facilitates the system 100 for adaptively adjusting a price for a service. For example, the requestor device 102 can send a signal or data to the cloud directly via a wireless connection (e.g., via NFC communication, Bluetooth, etc.) or over a network (e.g., the Internet).

[0053]

[0051] The provider device 104 is in communication with the requestor device 102 as described above, usually via the transaction processing server 108, and may be associated with a provider of a service (e.g. a driver responding to a request for a ride or delivery). The provider device 104 is, in turn, in communication with an acquirer server 106 via a connection 114. The provider device 104 is also in communication with the pricing server 140 via a connection 123, wherein the pricing server 140 may be configured to receive data relating to a request for a service or a price check request from the provider device 104. The connections 114 and 123 may be via a network (e.g., the Internet). The provider device 104 may also be connected to a cloud that facilitates the system 100 for adaptively adjusting a price for a service. For example, the provider device 104 can send a signal or data to the cloud directly via a wireless connection (e.g., via NFC communication, Bluetooth, etc.) or over a network (e.g., the Internet).

[0054]

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

[0055]

[0053] The transaction processing server 108 is further in communication with the pricing server 140 via a connection 120. The connection 120 may be over a network (e.g., a local area network, a wide area network, the Internet, etc.). In one arrangement, the transaction processing server 108 and the pricing server 140 are combined and the connection 120 may be an interconnected bus.

[0056]

[0054] The pricing server 140, in turn, is in communication with the reference database 150 via respective connection 122. The connection 122 may be over a network (e.g., the Internet). The pricing server 140 may also be connected to a cloud that facilitates the system 100 for adaptively adjusting a price for a service. For example, the pricing server 140 can send a signal or data to the cloud directly via a wireless connection (e.g., via NFC communication, Bluetooth, etc.) or over a network (e.g., the Internet).

[0055] The reference database 150 may comprise data that is utilized by the pricing server 140 for adaptively adjusting a price for a service. For example, data relating to a price that is set for a service within each of one or more areas, a minimum and / or maximum price limit that may be set in each of the one or more areas, a number of providers and requestors for the service within each of the one or more areas, a number of price checks received for a service, or other similar data may be stored in the reference database 150. Further, data relating to a price that is set or adjusted, a price check for a service, an updated number of requests for a service, an updated number of providers for the service, or other similar data, may be transmitted in real time (e.g., transmitted when a user inputs a request for a service such as a ride, delivery, or other similar service, or inputs a request for a price check for a service, or other similar action) and stored in the reference database 150. In an implementation, the reference database 150 may be combined with the pricing server 140. In an example, the reference database 150 may be managed by an external entity.

[0057]

[0056] The pricing server 140 may be configured to determine, for a price that is set for a service within an area, whether a demand for the service within the area matches a supply of the service within the area, the determination being based on a difference between a number of requests within the area for the service and a number of providers within the area providing the service, and a ratio between the number of providers and the number of requests. The pricing server 140 may then be configured to adjust the price for the service within the area based on the determination.

[0058]

[0057] Determining whether the demand for the service within the area matches the supply of the service within the area may comprise: determining that the demand exceeds the supply of the service when the difference between the number of requests and the number of providers exceed a first threshold value (e.g., 1 or other value), and the ratio between the number of providers and the number of requests exceed a second threshold value (e.g., 110% or other value), and adjusting the price based on the determination; and / or determining that the supply exceeds the demand for the service when the difference between the number of requests and the number of providers is less than a third threshold value (e.g., -1) and the ratio between the number of providers and the number of requests is less than a fourth threshold value (e.g., 90% or other value), and adjusting the price based on the determination. Determining whether the demand for the service within the area matches the supply of the service within the area may comprise setting the price based on a number of checks received for a price of the service within the area.

[0059]

[0058] The pricing server 140 may be further configured to calculate the difference and the ratio for each of a plurality of areas comprising the area, and determine a percentage of areas of the plurality of areas in which the demand for the service exceeds or is less than the supply for the service based on the calculated difference and ratio. The pricing server 140 may be further configured to apply a weight on each area of the plurality of areas based on the price that is set for the service in each area of the plurality of areas. The percentage of areas in which the demand for the service exceeds the supply for the service may be determined based on the applied weight, wherein the price that is set for the service is not bounded by a minimum price limit. The percentage of areas in which the supply for the service exceeds the demand for the service may be determined based on the applied weight, wherein the price that is set for the service is not bounded by a maximum price limit. The pricing server 140 may be further configured to determine a percentage of prices that are set in each of the plurality of areas that are bounded by a price limit, and adjust the price limit based on the determined percentage.

[0060]

[0059] In an implementation, there may be more than one reference databases, in which the pricing server 140 may be configured to determine which database to use for each step during the process of adjusting a price for a service. Alternatively, one or more modules may store the above-mentioned data instead of the reference database 150, wherein the module may be integrated as part of the pricing server 140 or external from the pricing server 140.

[0061]

[0060] In the illustrative embodiment, each of the devices 102, 104, and the servers 106, 108, 110, 140, and / or reference database 150 provides an interface to enable communication with other connected devices 102, 104 and / or servers 106, 108, 110, 140, and / or reference database 150. Such communication is facilitated by an application programming interface (“API”). Such 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. For example, it is possible for the requestor device 102 to send data relating to a requested service such as a ride, delivery or other similar service, or relating to a price check for a service, and for the provider device 104 to send data relating to acceptance or rejection of a ride or delivery request, in response to an enquiry shown on the GUI running on the respective API. It is also possible for the requestor device 102 and / or the provider device 104 to send data in real-time relating to a selection or order of an item or service by a user, for example in a real-time stream.

[0062]

[0061] 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.

[0063]

[0062] The pricing server 140 is associated with an entity (e.g. a company or organization or moderator of the service). In one arrangement, the pricing server 140 is owned and operated by the entity operating the transaction processing server 108. In such an arrangement, the pricing server 140 may be implemented as a part (e.g., a computer program module, a computing device, etc.) of the transaction processing server 108.

[0064]

[0063] The transaction processing server 108 may also be configured to manage the registration of users. A registered user has a transaction account (see the discussion above) which includes details 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 onboarding to the transaction processing server 108.

[0065]

[0064] It may not be necessary to have a transaction account at the transaction processing server 108 to access the functionalities of the transaction processing server 108. However, there may be functions that are only available to a registered user (e.g., only allowing a registered user to access more functions and capabilities relating to a request for a service or a price check request utilizing the pricing server 140, or other similar arrangements).

[0066]

[0065] 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 the API to interact with the transaction processing server 108) to the requestor device 102 or the provider device 104. In another arrangement, the user accesses a website (which includes the API to interact with the transaction processing server 108) on the requestor device 102 or the provider device 104. The user is then able to interact with the pricing server 140. The user may be a requestor or a provider associated with the requestor device 102 or the provider device 104, respectively.

[0067]

[0066] Details of the registration may 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 or receive data and information from the requestor device 102 and / or the provider device 104 for adaptively adjusting a price for a service, such as permission to receive data relating to a request for a service, a price check request for a service, selection or order of an item or service from the requestor device 102 and / or the provider device 104, or other similar data and information. Alternatively, another mobile device may be selected instead of the requestor device 102 and / or the provider device 104 for retrieving the data. Once on-boarded, the user would have a transaction account that stores all the details.

[0068]

[0067] The requestor device 102 is associated with a customer (or requestor) who is a party to a transaction that occurs between the requestor device 102 and the provider device 104, or between the requestor device 102 and the pricing server 140. 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. The requestor device 102 may be associated with a user who initiates a request for a ride or delivery, or a user who selects or orders an item.

[0069]

[0068] The requestor device 102 includes transaction credentials (e.g., a payment account) of a requestor to enable the requestor device 102 to be a party to a payment transaction. If the requestor has a transaction account, the transaction 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 transaction account of the customer stored in the mobile device.

[0070]

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

[0071]

[0070] The provider device 104 is associated with a provider who is also a party to the transaction request 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. The provider device 104 may be associated with a provider of a ride or delivery (e.g. a driver or deliverer responding to the request for the ride or delivery), or a user who selects or orders an item.

[0072]

[0071] Hereinafter, the term “provider” refers to a service provider and any third party associated with providing a product or service for purchase, or a travel or ride or delivery service via the provider device 104. Therefore, the transaction account of a provider refers to both the transaction account of a provider and the transaction account of a third party (e.g., a travel co-ordinator or merchant) associated with the provider.

[0073]

[0072] If the provider has a transaction account, the transaction 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 the transaction account of the provider stored in the mobile device.

[0074]

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

[0075]

[0074] The acquirer server 106 is associated with an acquirer who may be an entity (e.g. a company or organization) which issues (e.g. establishes, manages, administers) a payment account (e.g. a financial bank account) of a merchant. Examples of the acquirer include a bank and / 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 transaction processing 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 request (e.g., in relation to an order of an item) or a request for a ride to the transaction processing server 108.

[0076]

[0075] The transaction processing server 108 is configured to process processes relating to a transaction account by, for example, forwarding data and information associated with a transaction for, for example, a travel-ordination request, purchasing of a good or a service (e.g., resulting from a request for a service) to the other servers in the system 100 such as the pricing server 140. In an example, the transaction processing server 108 may, instead of the requestor device 102 or provider device 104, transmit data relating to a purchase of a service or an item (e.g. a price for the service or item, a name of the item, a time stamp indicating date and time of purchase, session ID, item ID, user ID, country / city ID, a price, and other similar data), to the pricing server 140. The transaction processing server 108 may use a variety of different protocols and procedures in order to process the payment and / or travel co-ordination requests. It will be appreciated that payment for a transaction may be made via a variety of methods such as credit cards, debit cards, digital wallets, buy-first pay-later schemes, and other similar payment methods.

[0077]

[0076] The 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 organization) 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 transaction processing server 108) by exchanging messages with and / or passing information to the other server.

[0078]

[0077] The reference database 150 is a database or server associated with an entity (e.g. a company or organization) which manages (e.g. establishes, administers) data relating to users, transactions, products, services, and other similar data, for example relating to the entity. In an arrangement, the reference database 150 may comprise data that is utilized by the pricing server 140 for adaptively adjusting a price for a service. For example, data relating to a price that is set for a service within each of one or more areas, a minimum and / or maximum price limit that may be set in each of the one or more areas, a number of providers and requestors for the service within each of the one or more areas, a number of price checks received for a service, or other similar data may be stored in the reference database 150. Further, data relating to a price that is set or adjusted, a price check for a service, an updated number of requests for a service, an updated number of providers for the service, or other similar data, may be transmitted in real time (e.g., transmitted when a user inputs a request for a service such as a ride, delivery, or other similar service, or inputs a request for a price check for a service, or other similar action) and stored in the reference database 150. In an implementation, the reference database 150 may be combined with the pricing server 140. In an example, the reference database 150 may be managed by an external entity.

[0079]

[0078] Advantageously, the system 100 provides a more granular, real-time view of demand conversion performance to efficiently respond to real-time changes in one or more areas in which a service is provided, enhancing the overall efficiency and pricing strategies for a service. Further, the system 100 can advantageously respond swiftly and effectively to changes in demand conversion indices, thus enhancing the efficiency and responsiveness of pricing adjustments, ultimately leading to improved revenue generation and customer satisfaction.

[0080]

[0079] Fig. 2 illustrates a schematic diagram of an example pricing server 140 according to various embodiments. The pricing server 140 may comprise a data module 260 configured to receive data and information from the requestor device 102, provider device 104, transaction processing server 108, reference database 150, a cloud and other sources of information to adjust a price for a service. For example, the data module 260 may be configured to receive data and information required for: determining, for a price that is set for a service within an area, whether a demand for the service within the area matches a supply of the service within the area, the determination being based on a difference between a number of requests within the area for the service and a number of providers within the area providing the service, and a ratio between the number of providers and the number of requests, and adjusting the price for the service within the area based on the determination; determining that the demand exceeds the supply of the service when the difference between the number of requests and the number of providers exceed a first threshold value (e.g., 1 or other value), and the ratio between the number of providers and the number of requests exceed a second threshold value (e.g., 110% or other value); determining that the supply exceeds the demand for the service when the difference between the number of requests and the number of providers is less than a third threshold value (e.g., -1 or other value) and the ratio between the number of providers and the number of requests is less than a fourth threshold value (e.g., 90% or other value); determining whether the demand for the service within the area matches the supply of the service within the area comprises setting the price based on a number of checks received for a price of the service within the area; calculating the difference and the ratio for each of a plurality of areas comprising the area, and determining a percentage of areas of the plurality of areas in which the demand for the service exceeds or is less than the supply for the service based on the calculated difference and ratio; applying a weight on each area of the plurality of areas based on the price that is set for the service in each area of the plurality of areas; determining a first percentage of areas in which the demand for the service exceeds the supply for the service based on the applied weight, wherein the price that is set for the service is not bounded by a minimum price limit; determining a second percentage of areas in which the supply for the service exceeds the demand for the service based on the applied weight, wherein the price that is set for the service is not bounded by a maximum price limit; adjusting the price further based on a difference between the first percentage and the second percentage; determining a multiplier value based on the difference between the first percentage and the second percentage; and adjust the price according to the multiplier value; determining a percentage of prices that are set in each of the plurality of areas that are bounded by a price limit, and adjusting the price limit based on the determined percentage; and other similar processes, from the requestor device 102, the provider device 104, transaction processing server 108, reference database 150, and / or other sources of information. The data module 260 may be further configured to send information relating to data retrieved in response to a request for a service or a price check made by a user to the requestor device 102, the provider device 104, the transaction processing server 108, or other destinations where the information is required.

[0081]

[0080] The pricing server 140 may comprise a index module 262 that is configured for determining, for a price that is set for a service within an area, whether a demand for the service within the area matches a supply of the service within the area, the determination being based on a difference between a number of requests within the area for the service and a number of providers within the area providing the service, and a ratio between the number of providers and the number of requests; determining that the demand exceeds the supply of the service when the difference between the number of requests and the number of providers exceed a first threshold value (e.g., 1 or other value), and the ratio between the number of providers and the number of requests exceed a second threshold value (e.g., 110% or other value); determining that the supply exceeds the demand for the service when the difference between the number of requests and the number of providers is less than a third threshold value (e.g., -1 ) and the ratio between the number of providers and the number of requests is less than a fourth threshold value (e.g., 90% or other value); calculating the difference and the ratio for each of a plurality of areas comprising the area, and determining a percentage of areas of the plurality of areas in which the demand for the service exceeds or is less than the supply for the service based on the calculated difference and ratio; applying a weight on each area of the plurality of areas based on the price that is set for the service in each area of the plurality of areas; determining a first percentage of areas in which the demand for the service exceeds the supply for the service based on the applied weight, wherein the price that is set for the service is not bounded by a minimum price limit; determining a second percentage of areas in which the supply for the service exceeds the demand for the service based on the applied weight, wherein the price that is set for the service is not bounded by a maximum price limit; adjusting the price further based on a difference between the first percentage and the second percentage; determining a multiplier value based on the difference between the first percentage and the second percentage; and adjust the price according to the multiplier value; determining a multiplier value based on the difference between the first percentage and the second percentage; and adjust the price according to the multiplier value; determining a percentage of prices that are set in each of the plurality of areas that are bounded by a price limit, and other similar processes. This process is further explained in Figs. 3A-6F.

[0082]

[0081] The pricing server 140 may also comprise a pricing module 264 that is configured for adjusting a price for a service within an area or each of a plurality of areas based on a determination whether a demand for the service within the area matches a supply of the service within the area; setting a price for a service based on a number of checks received for a price of the service within the area; setting or adjusting a price limit based on a determined percentage of prices that are set in each of a plurality of areas that are bounded by a price limit, and other similar processes. This process is further explained in Figs. 3A-6F.

[0082] Each of the data module 260, index module 262 and pricing module 264 may further be in communication with a processing module (not shown) of the pricing server 140, for example for coordination of respective tasks and functions during the process. The data module 260 may be further configured to communicate with and store data and information for each of the processing module, index module 262 and pricing module 264. Alternatively, all the tasks and functions required for adaptively adjusting a price for a sevice may be performed by a single processor of the pricing server 140.

[0083]

[0083] In the present disclosure, DCI as implemented herein may be configured to operate by quantifying the percentage of a plurality of areas (e.g., such as geohash-1 min instances or other similar implementations of area over time instance) associated with supply and demand for a service weighted based on a number of price checks for a service (e.g., also referred to herein as unique check price or UCP). It assesses a balance between a conversion of demand (e.g., a number of requests for a service) and an available supply (e.g., supply of providers for the service), indicating if a conversion of demand for a service (e.g., conversion of a request for a service to a successfully completed service such as a ride or a delivery) is just right, exceeding, or failing short of the estimated fulfillment capacity. Building upon this, PDCI specifically examines whether pricing leads to over or under-conversion by weighting UCP that is not bounded by minimum or maximum constraints (e.g., a minimum price limit or maximum price limit respectively). This gives us an accurate overview of a pricing impact on demand and conversion rates.

[0084]

[0084] DCI is built on the top of demand conversion score (DCS) and demand conversion ratio (DCR). DCS may refer to a difference between a number of requests for a service within an area and a number of providers for the service within the area. For example, DCS may refer to a difference between a smoothed available supply and a converted demand for each geohash-1 minute bucket, or other similar implementation. The smoothing function for the supply may be represented by a 9x5 matrix, which corresponds to 45 geohashes and covers a 3-kilometer allocation radius, such as shown in matrix 300 of Fig. 3A. The matrix 300, which may be referred to as a 'Supply Smoothing Kernel', may be subjected to timely updates (e.g., weekly, monthly, bi-monthly, yearly, or other similar implementation). These updates are anchored on location data of allocated drivers from the preceding month for an area. For example, for each geohash-1 minute bucket, DCS = Smoothed Supply - Total Demand. For smoothed supply, a fulfillment capacity (FFC) signal may be used as a count of supply, defined as a maximum number of providers of a service (e.g., drivers that can provide a ride or a delivery in response to a request for a ride or a delivery) that can be used to fulfill bookings. In an implementation, depending on a status of a provider (e.g., whether the provider is in transit to a destination that is the same as a destination indicated in a request for a service, in the middle of providing a service, or other similar status, herein referred to as a MD status), the provider may only be considered as half of an available FFC. Hence, the available FFC for each instance may be calculated as follows: Available FFC = FFC x (1 - online MD driver / online driver x MD_penalty_coeff), where MD_penalty_coeff = 1- MD_utilisation_rate / utilisation_rate. Further, Total Demand maybe estimated based on a total number of requests for a service that are either pending for allocation or just got allocated a provider for the service. For example, an area 302 of the plurality of areas associated with the matrix 300 may have a smoothed supply FFC of 0.208505. Utilizing a smoothing function for supply advantageously provides a more accurate representation of the number of providers for the service which also leads to a more accurate DCI.

[0085]

[0085] On the other hand, the DCR may be calculated as a ratio between a number of requests for a service and a number of providers for the service. In an implementation, for each area (e.g., for each geohash-1 minute bucket or other similar area format), DCR = Smoothed Supply

[0086] Total Demand. For example, if Demand = 0 but Smoothed Supply >= 1, then DCR = Smoothed Supply / 1. If Demand = 0 but Smoothed Supply < 1,then DCR = 1. Advantageously, ratios ease the comparison of data across different times (e.g., hours of a day or other similar time), regardless of demand density during each time. In dense demand and supply areas and times, DCS may be high, e.g., DCS =2, indicating there is supply surplus, but DCR may be of a reasonable value, e.g., DCR = 1.05, indicating that sufficient demand is being converted into successful provision of a service. Thus, when determining if a particular instance is under-converted or not, both DCS and DCR may be considered for a fair judgment.

[0087]

[0086] Based on the DCS and DCR, an area may be divided into 3 categories:

[0088] Under-conversion: DCS > 1 and DCR > 110%

[0089] Over-conversion: DCS <- 0. 5

[0090] Soldoff: the rest

[0091] The objective of the metrics is to state a ground truth about supply and demand for a service. For each area (e.g., each geohash6 evaluated at a one-minute interval, or other similar area format) of a plurality of areas, if the smoothed supply surpasses the demand by one unit and the smoothed supply constitutes 110% of the demand, this instance may be categorised as under-converted. It is thus presumed that there is untapped potential to fulfill more demand in this scenario. By including DCR, the risk of overestimating underconverted instances in areas with high demand and supply density can advantageously be mitigated.

[0092]

[0087] For example, consider an instance where the smoothed supply is 17.2 and the demand is 16, yielding a DCS of 1.2 and a DCR of 1.075. Albeit the performance of demand conversion seems satisfactory overall, failing to consider DCR might erroneously lead to this instance being flagged as under-converted. Similarly, if DCS < -0.5, the instance may be considered as over-converted because the demand converted surpasses the supply available leading to the increase in unallocated bookings. The rest of the scenarios are considered as ‘soldoff’, indicating that a right amount of demand is converted into successful service provision via right-pricing. An example of DCS and DCR distribution calculated for a particular day is shown in table 304 of Fig. 3B. For example, the median values of DCS & DCR are 0.56 and 1.0, respectively. This means that the market balance is well maintained on average with the pricing system. However, there still exist extreme low or high DCS & DCR values in the table 304 which indicates there is still some room for improvement e.g., via implementation of FACT-C.

[0093]

[0088] Demand Conversion Indices (DCI), derived based on DCS and DCR, may be composed of 3 sub metrics as follows:

[0094] 1. Underconversion ratio: percentage (%) of a plurality of areas that are underconverted (e.g., under-converted geohash6-1 minute instances or other similar area format), weighted by UCP.

[0095] 2. Overconversion ratio: percentage (%) of the plurality of areas that are overconverted (e.g., over-converted geohash6-1 minute instances or other similar area format), weighted by UCP.

[0096] 3. Soldoff ratio: percentage (%) of the plurality of areas that are considered as soldoff (e.g., sold-off geohash6-1 minute instances or other similar format), weighted by UCP.

[0097]

[0089] The formulas for calculating the above ratios may be as follows: Owrconwrt ratio = 2 H S Jf}I7CP

[0098] Undercan t ratio = i f 1 / 1 f}(JCP;

[0099] S doff ratio = 1-Owrconvert ratfo-Underconwt ratio

[0100] where M is the total number of instances, M1 is the number of over-converted instances and M2 is the number of under-converted instances. It is clear that Underconversion ratio + Overconversion ratio + Soldoff ratio = 100%. In the calculation of DCI, it is advantageous to use UCP as weightage to reduce the impact of areas in which demand or supply are sparse which may skew the results.

[0101]

[0090] In some oversupply markets, there may be a high underconversion ratio for a service, and the price that is set for the service may be adjusted by, for example, lowering a minimum price limit for the service. In order to understand if the root cause of demand under-conversion is due to insufficient engaged users, a new metric may be introduced e.g., %lnstance with UCP lower than supply to identify if a underconversion issue stems from a number of price checks for a service is lower than an available supply for the service. On the other hand, for example for undersupplied markets where there may be a high overconversion ratio for a service, the price that is set for the service may be adjusted by, for example, increasing a minimum price limit and / or a maximum price limit for the service. The metric may thus indicate the needs of a marketing push for acquiring new or resurrecting dormant users e.g., users who may be interested but not motivated to request for a service.

[0102]

[0091] In order to understand if a minimum price limit or maximum price limit work efficiently, a %UCP may be calculated for one or more areas in which a price for a service is capped by the minimum price limit and / or maximum price limit. If any of the following metrics are high, the corresponding price limit may be adjusted to shape the DCI portfolio to a healthy level:

[0103] - %UCP Capped by Max Surge

[0104] %UCP Capped by Min Surge

[0105] - %UCP Capped by minEffperKM

[0106] - %UCP Capped by maxEffperKM

[0107] - %UCP Capped by MinFareGuarantee

[0108] - %UCP Capped by MaxFareCap %UCP Capped by SurgeAndSurchargeCap

[0109]

[0092] A minimum or maximum (min / max) surge may refer to min / max bounds on a surge value of a price, for example 1.0 & 2.0, respectively, meaning that a final price for a service after a surge cannot be lower than a base price (due to min surge 1.0), and also cannot be higher than two times of the base price (due to max surge 2.0). A min / max effective fare per kilometre (km) may refer to bounds on a price per km (=final price / trip distance). It may be an absolute value, for example if we set the bounds as 0.5 & 2.0, then for a 10km trip, the fare should be within the range 5 to 20. MinFareGuarantee & MaxFareCap may refer to bounds that are implemented on the total trip price. Further, SurgeAndSurchargeCap may be used to limit the total amount of surge and surcharge applied to a price. This is particularly relevant in regions with regulatory requirements, such as Thailand, where there is a legal cap on the maximum allowable surge and surcharge. The definition of Pricing DCI (PDCI) is similar to DCI. The only difference is that the metrics are weighted by the UCP that is not capped by a price limit. The rationale behind this is to understand the DCI portfolio that is affected by dynamic pricing components only. If the portfolio is healthy, it may not be necessary to tune dynamic pricing components first:

[0110] 1. Pricing Underconversion ratio: percentage (%) of a plurality of areas that are under-converted (e.g., under-converted geohash6-1 minute instances or other similar area format), weighted by UCP that is not capped by a price limit (e.g., a first percentage of areas in which the demand for the service exceeds the supply for the service based on an applied weight, wherein the price that is set for the service is not bounded by a minimum price limit).

[0111] 2. Pricing Overconversion ratio: percentage (%) of the plurality of areas that are over-converted (e.g., over-converted geohash6-1 minute instances or other similar area format), weighted by UCP that is not capped by a price limit (e.g., a second percentage of areas in which the supply for the service exceeds the demand for the service based on the applied weight, wherein the price that is set for the service is not bounded by a maximum price limit).

[0112] 3. Pricing Soldoff ratio: percentage (%) of the plurality of areas that are considered as sold-off (e.g., sold-off geohash6-1 minute instances or other similar format), weighted by UCP that is not capped by a price limit.

[0093] The formulas for calculating the above ratios may be as follows:

[0113] taram f

[0114]

[0115] ja caused by dynamic pricing

[0116] [tafem t«rt Jfotie mused

[0117]

[0118] pricing

[0119]

[0120]

[0121] = 1 — y^dermnwrt ffatio caused by dynamic pricing - 0verco ®rt fiat is caused by dynamic pricing

[0122] In the above formula, M refers to a plurality of areas (e.g., a plurality of geohash 6x1 minute instances or other similar area format), M1 refers to the overconverted instances and M2 refers to the underconverted instances.

[0123]

[0094] Given by the PDCI Overconvert Ratio (OCR) and Underconvert Ratio (UCR) observation at a timestamp t, an error e(t) may be determined at the same timestamp as

[0124]

[0125] Where s(t) = OCR- UCR at timestamp t (e.g., determine a difference between the first percentage and the second percentage), and DZmin and DZmax are the min / max bounds for the deadzone that FACT-C is safe to keep muted. Then, the FACT-C multiplier u(t) (e.g., a multiplier value for adjusting a price for a service) may be determined by the formula:

[0126]

[0127] Where K, K. & Kd represent the coefficients for the proportional, integral, and derivative terms, respectively, in a PID controller.

[0128]

[0095] A PID Controller (Proportional, Integral, Derivative Controller) is a control loop mechanism widely used in industrial control systems and a variety of other applications requiring continuously modulated control. It is a type of feedback controller whose action is based on the error, the difference between the desired setpoint and the measured process variable. The controller attempts to minimize the error by adjusting the process control inputs. The PID controller is named after its three correcting terms, whose sum constitutes the manipulated variable (MV). Proportional provides a change in output that is proportional to the current error value. It determines the reaction to the current error. Integral provides a change based on the accumulation of past errors. It determines the reaction based on the sum of recent errors. Derivative provides a change in output based on the rate of change of the error with time. It determines the reaction to the rate at which the error has been changing. For example, consider an exemplary cruise control system in a car. The PID controller may act as the system managing the car's speed. A set point may refer to a speed that a driver of the car wants to move. A process variable for the PID controller may be the car’s current speed. A control variable for the PID controller may be an amount of pressure applied to the car throttle. If the car is going slower than the desired speed (error in the process variable), the PID controller may increase the throttle to speed up (Proportional). If the car does not reach the desired speed quickly enough, it may continue to increase the throttle based on the accumulated error (Integral). If the car is approaching the desired speed rapidly, it may ease off the throttle to avoid overshooting (Derivative).

[0129]

[0096] The derivative term Kd may amplify high-frequency noise in the error signal, which can lead to large and potentially destabilizing control actions. This is especially problematic in systems with a lot of sensor noise. Moreover, the derivative term can sometimes introduce a delay due to the differentiation process, which might lead to phase lag. Therefore, it may be possible to ignore the derivative term first for simplicity, and also introduce a "decay" factor A to prevent the integral term from growing indefinitely. Thus, the final PI controller may be represented as:

[0130]

[0131] In the given equation, Umin & Umax denote the lower and upper bounds of the FACT-C multiplier respectively. Furthermore, a constant term, 1, is integrated into the formula. This adjustment advantageously allows us to confidently assign positive values to both Kp & Ki., considering the error term is positive for over-conversion scenarios and negative for under-conversion scenarios. Consequently, this also enables us to effectively impose a surcharge (where the multiplier > 1 ) in situations of over-conversion and provide a discount (where the multiplier < 1) in cases of under-conversion, by adjusting a price for a service according to the multiplier value (e.g., adjusting a price for a service based on a determination of whether a demand for the service matches a supply for the service).

[0132]

[0097] Upstream key signals for computing the DCS may refer to any real time booking signals (e.g., referred to herein as unique request UR), real time supply capacity signal (e.g., fulfillment capacity FFC), real time fare check session signal (e.g., unique check price UCP), or other similar signals. Referring to illustration 400 of Fig. 4, in determining FFC, it may be assumed that the fulfillment capacity aggregation is based on a location of a provider for a service (e.g., a driver who can provide a ride or delivery service) based on the provider’s last location or state update close to end time t, regardless of where the provider is at time t-1. In illustration 400, FFC is the maximum number of drivers that can be used to fulfill bookings within time period T (denoted as FFCr). Available supply refers to a number of available drivers at a snapshot of a given timestamp t, denoted as St. Replenished supply refers to a number of allocatable supply changes within time period T, including previously offline drivers who are now online, and in-transit drivers completing rides or receiving back to back job (B2BJ) rides, denoted as delta ST. Allocated supply refers to a number of supply that is allocated within time period, denoted as ST. The above-mentioned sub-signals’ relationship may be described using the following formulas:

[0133]

[0134] Thus, in the example for illustration 400:

[0135] 1. Available supply for timestamp t-1 is 10, and timestamp t is 6

[0136] 2. Replenished supply for time period T is 1 +2+5-2 = 6

[0137] 3. FFC for time period T is 10+6 = 16

[0138] 4. Allocated supply for time period T is 16-6=10

[0139]

[0098] UR may be identified by, for example, a series of booking codes that belong to a same user (e.g., a user requesting for a service) and have similar pick-up and drop-off locations (e.g., lat-long coordinates with 3 decimal places precision, with approximately 110m granularity, or other similar coordinates). In an example, UR may remain the same until one of the following conditions is met:

[0140] 1. The requests for a service are successfully converted into provisions of the service. 2. The concerned user does not make another request for a service within a period of time (e.g., within the next 30 minutes, or other time configuration), indicating that the request has expired or the user has given up in requesting for the service.

[0141]

[0099] Further, a UCP signal may be generated when a user (e.g., identified based on an identifier such as a paxID or other similar format) checks the price for a service such as a specific ride multiple times within a short period of time. The UCP may be identified for the same pickup and drop-off locations (e.g., geohash6 or other similar area format), or if the pickup-dropoff pair is, for example, a recommendation for a ride (e.g., predicting a likely dropoff location for the passenger, and checking and showing a price for the suggested trip). The UCP session may end if the next fare check is beyond 30 minutes. Advantageously, this signal is useful for deduplication of a price check (referred to as fare check or FC in illustration 500 of Fig. 5) and more accurately reflects a passenger's intention to book a ride. For example, referring to illustration 500 of Fig. 5, a user requests for a FC in a step 502. At step 504, the FC is dropped if information associated with the FC (e.g., a Sourcetag or other similar information) indicates that there is no actual travel intention. At step 506, a new UCP is created if there is no active UCP with a same pickup and dropoff location (e.g., geohash or other similar area format), otherwise the UCP with the same pickup and dropoff location are aggregated. At step 508, a UCP is terminated if it is inactive for a period of time (e.g., 30 minutes or other configured time period). At step 510, the UCP is used for applying weights for calculation of DCI. An UCP may be configured to last for more than 30 minutes or other set time, as it would not be terminated unless it is inactive for a certain time period. In order to understand how much intended demand (e.g., actual number of requests for a service) is generated every minute, UCPs that are not only ongoing (e.g., not terminated yet), but also updated (e.g., having new price checks) in a specific minute may be counted..

[0142]

[0100] In an example, an area A may be overconverting with 10 UCP, an area B is soldoff with 20 UCP, and an area C is underconverting with 5 UCP. Therefore, the DCI OCR = 10 / (10+20+5) = 0.286, DCI UCR = 5 / 35 =0.143, DCI SOR = 20 / 35 = 0.571. Further, among the 5 UCP in area C, if there are 2 UCP hitting a min price bound, then the pricing system cannot lower the price further. Therefore, although DCI UCR = 5 / 35 = 0.143, but PDCI UCR should be (5-2) / 35 = 0.086. Furthermore, among the 10 UCP in area A, if there are 5 UCP hitting a max price bound, then the pricing system cannot increase the price further even though it is overconverting in area A. Therefore, although DCI OCR = 10 / 35 = 0.286, but PDCI OCR should be (10-5) / 35 = 0.143.

[0143]

[0101] Figs 6A-6F are provided herein for illustration of simulations performed using the techniques discussed herein. In these examples, fulfillment rate (FR) refers to a ratio between the number of completed services and the number of service requests. This metric assesses the ability to fulfill requests for a service, indicating the efficiency and reliability of services provided by the concerned platform. Further, allocation rate (AR) refers to a ratio between the number of allocated bookings (e.g., number of service requests that are allocated to providers for the service) and the total number of service requests. This metric evaluates how effectively requests for a service are being allocated to providers for the service, regardless of whether the request was ultimately completed or canceled. For example, referring to illustration 600 of Fig. 6A depicting a pricing simulation result for a service in Klang Valley (KV), FACT-C significantly increases a price for a service during the wee hours and early morning (3-6 am local time) due to extremely over-conversion conditions. During this time period, there is a fulfillment rate (FR) and allocation rate (AR) dip, although the AR recovers much earlier than the FR. Further, FACT-C increases the price for the service during the evening peak (7~8 pm) when AR / FR are still healthy, then switches to slightly reduce the price during late-night hours, despite the FR dip (which is still > 80%). Further, illustration 602 of Fig. 6B shows the corresponding manual configurations that are set for the same KV high demand cluster areas. It is evident that the decisions made by FACT-C more or less align with these manual confi urations, which increases the price for the service at specific hours: 7~8pm, 0-1 am, and 4~6am, while the manual configuration shows a 1.2* increase from 5pm to 12am on Sunday, and at 1am and 6am on Monday. This observation likely indicates that FACT-C has the potential to account for pre-scheduled manual configurations, particularly in scenarios where there are frequent FR / AR drops in high-demand density areas during certain time periods.

[0144]

[0102] Referring to illustration 604 of Fig. 6C, FACT-C introduces a high pax fare multiplier (e.g., increasing the price for the service) for residential areas such as Punggol & Choa Chu Kang (e.g., in area 606) during the morning peak. This makes sense as working individuals are likely to require more rides to their workplaces, leading to over-conversion scenarios. In illustration 608 of Fig. 6D, FACT-C imposes a mild surcharge on Jurong West (e.g., in area 610), a high surcharge on the Sentosa area (e.g., in area 612), and a significant discount on CBD areas (e.g., in area 614). The surcharge in Jurong West aligns with expectations of working individuals taking more rides home. However, the underconversion and low FR issue in CBD areas might be caused by factors outside of the pricing domain. In illustration 616 of Fig. 6E, FACT-C determines a high surcharge for geohash w21z3 (e.g., in area 618) late at night, which covers Queenstown, Clementi, and the West Coast. In illustration 620 of Fig. 6F, FACT-C appropriately remains muted during off-peak hours, as the market maintains a healthy balance during these periods (e.g., no price adjustments are introduced as demand is matched with supply for all areas).

[0145]

[0103] Fig. 7 illustrates an example flow diagram for a method 700 for adaptively adjusting a price for a service according to various embodiments. In a step 702, it is determined, for a price that is set for a service within an area, whether a demand for the service within the area matches a supply of the service within the area, the determination being based on a difference between a number of requests within the area for the service and a number of providers within the area providing the service, and a ratio between the number of providers and the number of requests. In a step 704, the price for the service within the area is adjusted based on the determination.

[0146]

[0104] Fig. 8A depicts an example computer system 1400, in accordance with which the pricing server 140 described can be practiced. The computer system 1400 includes a computer module 1401. 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.

[0147]

[0105] The computer module 1401 typically includes at least one processor unit 1405, and a memory unit 1406. For example, the memory unit 1406 may have semiconductor random access memory (RAM) and semiconductor read only memory (ROM). The computer module 1401 also includes an interface 1408 for the external modem 1416. 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 Fig. 8A, 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 Bluetooth® wireless arrangement or an IEEE 802.11 wireless arrangement; however, numerous other types of interfaces may be practiced for the interface 1411.

[0148]

[0106] The I / O interfaces 1408 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 1409 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, USB-RAM, portable, external hard drives, and floppy disks, for example, may be used as appropriate sources of data to the system 1400.

[0149]

[0107] The components 1405 to 1412 of the computer module 1401 typically communicate via an interconnected bus 1304 and in a manner that results in a conventional mode of operation of the computer system 1400 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 practiced include IBM-PC’s and compatibles, Sun Sparcstations, Apple or like computer systems.

[0150]

[0108] The method 700, where performed by the pricing server 140 may be implemented using the computer system 1400. The processes may be implemented as one or more software application programs 1433 executable within the computer system 1400. In particular, the method 700 are effected by instructions in the software 1433 that are carried out within the computer system 1400. The software instructions 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 method 700 and a second part and the corresponding code modules manage a user interface between the first part and the user.

[0151]

[0109] The software may be stored in a computer readable medium, including the storage devices described below, for example. The software is loaded into the computer system 1400 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 computer system 1400 preferably effects an advantageous apparatus for a pricing server 140.

[0152]

[0110] The software 1433 is typically stored in the HDD 1410 or the memory 1406. The software is loaded into the computer system 1400 from a computer readable medium, and executed by the computer system 1400. Thus, for example, the software 1433 may be stored on an optically readable disk storage medium (e.g., 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 computer system 1400 preferably effects an apparatus for a pricing server 140.

[0153]

[0111] 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 computer system 1400 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 computer system 1400 for execution and / or processing. Examples of such storage media include floppy disks, magnetic tape, optical 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.

[0154]

[0112] The second part of the application programs 1433 and the corresponding code modules mentioned above may be executed to implement one or more graphical user interfaces (GUIs) to be rendered or otherwise represented upon a display. Through manipulation of typically a keyboard and a mouse, a user of the computer system 1400 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). Other forms of functionally adaptable user interfaces may also be implemented, such as an audio interface utilizing speech prompts output via loudspeakers and user voice commands input via a microphone.

[0155]

[0113] It is to be understood that the structural context of the computer system 1400 (i.e., the pricing server 140) is presented merely by way of example. Therefore, in some arrangements, one or more features of the computer system 1400 may be omitted. Also, in some arrangements, one or more features of the computer system 1400 may be combined together. Additionally, in some arrangements, one or more features of the computer system 1400 may be split into one or more component parts.

[0156]

[0114] Fig. 9 shows an implementation of the transaction processing server 108. In this implementation, the transaction processing server 108 may be generally described as a physical device comprising at least one processor 802 and at least one memory 804 including computer program codes. The at least one memory 804 and the computer program codes are configured to, with the at least one processor 802, cause the transaction processing server 108 to facilitate the operations described in method 700. The transaction processing server 108 may also include a transaction processing module 806. The memory 804 stores computer program code that the processor 802 compiles to have transaction processing module 806 perform the respective functions.

[0157]

[0115] With reference to Fig. 1, the transaction processing module 806 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 for ordering an item, a request for a ride or delivery, or other similar messages. The transaction processing module 806 may be configured to process processes relating to a transaction account by, for example, forwarding data and information associated with a transaction for, for example, a travel-ordination request, purchasing of a good or a service (e.g., resulting from a request for a service) to the other servers in the system 100 such as the pricing server 140. In an example, the transaction processing server 108 may, instead of the requestor device 102 or provider device 104, transmit data relating to a purchase of a service or an item (e.g. a price for the service or item, a name of the item, a time stamp indicating date and time of purchase, session ID, item ID, user ID, country / city ID, a price, and other similar data), to the pricing server 140. The transaction processing server 108 may use a variety of different protocols and procedures in order to process the payment and / or travel co-ordination requests. It will be appreciated that payment for a transaction may be made via a variety of methods such as credit cards, debit cards, digital wallets, buy-first pay-later schemes, and other similar payment methods. It will be appreciated that payment for a transaction may be made via a variety of methods such as credit cards, debit cards, digital wallets, buy-first pay-later schemes, and other similar payment.

[0158]

[0116] Fig. 10 shows an alternative implementation of the pricing server 140 (i.e., the computer system 1400). In the alternative implementation, pricing server 140 may be generally described as a physical device comprising at least one processor 902 and at least one memory 904 including computer program codes. The at least one memory 904 and the computer program codes are configured to, with the at least one processor 902, cause the pricing server 140 to perform the operations described in the method 700. The pricing server 140 may also include a data module 906, a index module 908 and a pricing module 910. The memory 904 stores computer program code that the processor 902 compiles to have each of the modules 906 to 910 performs their respective functions.

[0159]

[0117] With reference to Figs. 1 to 7, the index module 908 performs the function of determining, for a price that is set for a service within an area, whether a demand for the service within the area matches a supply of the service within the area, the determination being based on a difference between a number of requests within the area for the service and a number of providers within the area providing the service, and a ratio between the number of providers and the number of requests; determining that the demand exceeds the supply of the service when the difference between the number of requests and the number of providers exceed a first threshold value (e.g., 1 or other value), and the ratio between the number of providers and the number of requests exceed a second threshold value (e.g., 110% or other value); determining that the supply exceeds the demand for the service when the difference between the number of requests and the number of providers is less than a third threshold value (e.g., -1 ) and the ratio between the number of providers and the number of requests is less than a fourth threshold value (e.g., 90% or other value); calculating the difference and the ratio for each of a plurality of areas comprising the area, and determining a percentage of areas of the plurality of areas in which the demand for the service exceeds or is less than the supply for the service based on the calculated difference and ratio; applying a weight on each area of the plurality of areas based on the price that is set for the service in each area of the plurality of areas; determining a first percentage of areas in which the demand for the service exceeds the supply for the service based on the applied weight, wherein the price that is set for the service is not bounded by a minimum price limit; determining a second percentage of areas in which the supply for the service exceeds the demand for the service based on the applied weight, wherein the price that is set for the service is not bounded by a maximum price limit; adjusting the price further based on a difference between the first percentage and the second percentage; determining a multiplier value based on the difference between the first percentage and the second percentage; and adjust the price according to the multiplier value; determining a percentage of prices that are set in each of the plurality of areas that are bounded by a price limit, and other similar processes.

[0160]

[0118] With reference to Figs. 1 to 7, the pricing module 910 performs the function of adjusting a price for a service within an area or each of a plurality of areas based on a determination whether a demand for the service within the area matches a supply of the service within the area; setting a price for a service based on a number of checks received for a price of the service within the area; setting or adjusting a price limit based on a determined percentage of prices that are set in each of a plurality of areas that are bounded by a price limit, and other similar processes.

[0161]

[0119] With reference to Figs. 1 to 7, the data module 906 performs the functions of receiving data and information from the requestor device 102, provider device 104, transaction processing server 108, reference database 150, a cloud and other sources of information to build a knowledge graph. For example, the data module 260 may be configured to receive data and information from the requestor device 102, provider device 104, transaction processing server 108, reference database 150, a cloud and other sources of information to adjust a price for a service. For example, the data module 906 may be configured to receive data and information required for: determining, for a price that is set for a service within an area, whether a demand for the service within the area matches a supply of the service within the area, the determination being based on a difference between a number of requests within the area for the service and a number of providers within the area providing the service, and a ratio between the number of providers and the number of requests, and adjusting the price for the service within the area based on the determination; determining that the demand exceeds the supply of the service when the difference between the number of requests and the number of providers exceed a first threshold value (e.g., 1 or other value), and the ratio between the number of providers and the number of requests exceed a second threshold value (e.g., 110% or other value); determining that the supply exceeds the demand for the service when the difference between the number of requests and the number of providers is less than a third threshold value (e.g., -1) and the ratio between the number of providers and the number of requests is less than a fourth threshold value (e.g., 90% or other value); determining whether the demand for the service within the area matches the supply of the service within the area comprises setting the price based on a number of checks received for a price of the service within the area; calculating the difference and the ratio for each of a plurality of areas comprising the area, and determining a percentage of areas of the plurality of areas in which the demand for the service exceeds or is less than the supply for the service based on the calculated difference and ratio; applying a weight on each area of the plurality of areas based on the price that is set for the service in each area of the plurality of areas; determining a first percentage of areas in which the demand for the service exceeds the supply for the service based on the applied weight, wherein the price that is set for the service is not bounded by a minimum price limit; determining a second percentage of areas in which the supply for the service exceeds the demand for the service based on the applied weight, wherein the price that is set for the service is not bounded by a maximum price limit; adjusting the price further based on a difference between the first percentage and the second percentage; determining a multiplier value based on the difference between the first percentage and the second percentage; and adjust the price according to the multiplier value; determining a percentage of prices that are set in each of the plurality of areas that are bounded by a price limit, and adjusting the price limit based on the determined percentage; and other similar processes, from the requestor device 102, the provider device 104, transaction processing server 108, reference database 150, and / or other sources of information. The data module 906 may be further configured to send information relating to data retrieved in response to a request for a service or a price check made by a user to the requestor device 102, the provider device 104, the transaction processing server 108, or other destinations where the information is required.

[0162]

[0120] Fig. 8B depicts a general-purpose computer system 1500, upon which a combined transaction processing server 108 and pricing server 140 described can be practiced. The computer system 1500 includes a computer module 1501. An external Modulator-Demodulator (Modem) transceiver device 1516 may be used by the computer module 1501 for communicating to and from a communications network 1520 via a connection 1521. The communications network 1520 may be a wide-area network (WAN), such as the Internet, a cellular telecommunications network, or a private WAN. Where the connection 1521 is a telephone line, the modem 1516 may be a traditional “dialup” modem. Alternatively, where the connection 1521 is a high capacity (e.g., cable) connection, the modem 1516 may be a broadband modem. A wireless modem may also be used for wireless connection to the communications network 1520.

[0163]

[0121] The computer module 1501 typically includes at least one processor unit 1505, and a memory unit 1506. For example, the memory unit 1506 may have semiconductor random access memory (RAM) and semiconductor read only memory (ROM). The computer module 1501 also includes an interface 1508 for the external modem 1516. In some implementations, the modem 1516 may be incorporated within the computer module 1501, for example within the interface 1508. The computer module 1501 also has a local network interface 1511, which permits coupling of the computer system 1500 via a connection 1523 to a local-area communications network 1522, known as a Local Area Network (LAN). As illustrated in Fig. 8D, the local communications network 1522 may also couple to the wide network 1520 via a connection 1524, which would typically include a so-called “firewall” device or device of similar functionality. The local network interface 1511 may comprise an Ethernet circuit card, a Bluetooth® wireless arrangement or an IEEE 802.11 wireless arrangement; however, numerous other types of interfaces may be practiced for the interface 1511.

[0164]

[0122] The I / O interfaces 1508 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 1509 are provided and typically include a hard disk drive (HDD) 1510. Other storage devices such as a floppy disk drive and a magnetic tape drive (not illustrated) may also be used. An optical disk drive 1512 is typically provided to act as a non-volatile source of data. Portable memory devices, such optical disks, USB-RAM, portable, external hard drives, and floppy disks, for example, may be used as appropriate sources of data to the system 1500.

[0165]

[0123] The components 1505 to 1512 of the computer module 1501 typically communicate via an interconnected bus 1504 and in a manner that results in a conventional mode of operation of the computer system 1500 known to those in the relevant art. For example, the processor 1505 is coupled to the system bus 1504 using a connection 1518. Likewise, the memory 1506 and optical disk drive 1512 are coupled to the system bus 1504 by connections 1519. Examples of computers on which the described arrangements can be practised include IBM-PC’s and compatibles, Sun Sparcstations, Apple or like computer systems.

[0166]

[0124] The steps of the method 700 performed by the pricing server 140 and facilitated by the transaction processing server 108 may be implemented using the computer system 1500. For example, the steps of the method 700 as performed by the pricing server 140 may be implemented as one or more software application programs 1533 executable within the computer system 1500. In particular, the steps of the method 700 are effected by instructions in the software 1533 that are carried out within the computer system 1500. The software instructions 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 steps of the method 700 and a second part and the corresponding code modules manage a user interface between the first part and the user.

[0167]

[0125] The software may be stored in a computer readable medium, including the storage devices described below, for example. The software is loaded into the computer system 1500 from the computer readable medium, and then executed by the computer system 1500. 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 computer system 1500 preferably effects an advantageous apparatus for a combined transaction processing and pricing server.

[0126] The software 1533 is typically stored in the HDD 1510 or the memory 1506. The software is loaded into the computer system 1500 from a computer readable medium, and executed by the computer system 1500. Thus, for example, the software 1533 may be stored on an optically readable disk storage medium (e.g., CD-ROM) 1525 that is read by the optical disk drive 1512. 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 computer system 1500 preferably effects an apparatus for a combined transaction processing and pricing server.

[0168]

[0127] In some instances, the application programs 1533 may be supplied to the user encoded on one or more CD-ROMs 1525 and read via the corresponding drive 1512, or alternatively may be read by the user from the networks 1520 or 1522. Still further, the software can also be loaded into the computer system 1500 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 computer system 1500 for execution and / or processing. Examples of such storage media include floppy disks, magnetic tape, optical 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 1501. 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 1501 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.

[0169]

[0128] The second part of the application programs 1533 and the corresponding code modules mentioned above may be executed to implement one or more graphical user interfaces (GUIs) to be rendered or otherwise represented upon a display. Through manipulation of typically a keyboard and a mouse, a user of the computer system 1500 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). Other forms of functionally adaptable user interfaces may also be implemented, such as an audio interface utilizing speech prompts output via loudspeakers and user voice commands input via a microphone.

[0129] It is to be understood that the structural context of the computer system 1500 (i.e., combined transaction processing and pricing server 1500) is presented merely by way of example. Therefore, in some arrangements, one or more features of the server 1500 may be omitted. Also, in some arrangements, one or more features of the server 1500 may be combined together. Additionally, in some arrangements, one or more features of the server 1500 may be split into one or more component parts.

[0170]

[0130] Fig. 11 shows an alternative implementation of combined transaction processing and pricing server (i.e., the computer system 1500). In the alternative implementation, the combined transaction processing and pricing server may be generally described as a physical device comprising at least one processor 1002 and at least one memory 904 including computer program codes. The at least one memory 1004 and the computer program codes are configured to, with the at least one processor 1002, cause the combined transaction processing and pricing server to perform the operations described in the steps of the method 700. The combined transaction processing and pricing server may also include a transaction processing module 806, a data module 906, a index module 908 and a pricing module 910. The memory 1004 stores computer program code that the processor 1002 compiles to have each of the modules 806 to 912 perform their respective functions. The transaction processing module 806 performs the same functions as described for the same transaction processing module in Fig. 9. The data module 906, index module 908 and pricing module 910 perform the same functions as described for the same corresponding modules in Fig. 10.

[0171]

[0131] It will be appreciated by a person skilled in the art that numerous variations and / or modifications may be made to the present disclosure as shown in the specific embodiments without departing from the scope of the specification as broadly described. The present embodiments are, therefore, to be considered in all respects to be illustrative and not restrictive.

Claims

CLAIMSWhat is claimed is:

1. A method for adaptively adjusting a price for a service, comprising:determining, by a processor, for a price that is set for a service within an area, whether a demand for the service within the area matches a supply of the service within the area, the determination being based on a difference between a number of requests within the area for the service and a number of providers within the area providing the service, and a ratio between the number of providers and the number of requests; andadjusting, by the processor, the price for the service within the area based on the determination.

2. The method of claim 1, wherein determining whether the demand for the service within the area matches the supply of the service within the area comprises: determining that the demand exceeds the supply of the service when the difference between the number of requests and the number of providers exceed a first threshold value, and the ratio between the number of providers and the number of requests exceed a second threshold value, andadjusting the price based on the determination.

3. The method of claim 1, wherein determining whether the demand for the service within the area matches the supply of the service within the area comprises: determining that the supply exceeds the demand for the service when the difference between the number of requests and the number of providers is less than a third threshold value, and the ratio between the number of providers and the number of requests is less than a fourth threshold value, andadjusting the price based on the determination.

4. The method of claim 1, wherein determining whether the demand for the service within the area matches the supply of the service within the area comprises setting the price based on a number of checks received for a price of the service within the area.

5. The method of claim 1, further comprising:calculating the difference and the ratio for each of a plurality of areas comprising the area, anddetermining a percentage of areas of the plurality of areas in which the demand for the service exceeds or is less than the supply for the service based on the calculated difference and ratio.

6. The method of claim 5, further comprising applying a weight on each area of the plurality of areas based on the price that is set for the service in each area of the plurality of areas.

7. The method of claim 6, further comprising:determining a first percentage of areas in which the demand for the service exceeds the supply for the service based on the applied weight, wherein the price that is set for the service is not bounded by a minimum price limit; determining a second percentage of areas in which the supply for the service exceeds the demand for the service based on the applied weight, wherein the price that is set for the service is not bounded by a maximum price limit;adjusting the price further based on a difference between the first percentage and the second percentage.

8. The method of claim 7, further comprising determining a multiplier value based on the difference between the first percentage and the second percentage; and adjusting the price according to the multiplier value.

9. The method of claim 5, further comprising determining a percentage of prices that are set in each of the plurality of areas that are bounded by a price limit, and adjusting the price limit based on the determined percentage.

10. A system for adaptively adjusting a price for a service, 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 at least one processor, cause the system at least to:determine, for a price that is set for a service within an area, whether a demand for the service within the area matches a supply of the service within the area, the determination being based on a difference between a number of requests within the area for the service and a number of providers within the area providing the service, and a ratio between the number of providers and the number of requests; andadjust the price for the service within the area based on the determination.

11. The system of claim 10, wherein determining whether the demand for the service within the area matches the supply of the service within the area comprises: determining that the demand exceeds the supply of the service when the difference between the number of requests and the number of providers exceed a first threshold value, and the ratio between the number of providers and the number of requests exceed a second threshold value, andadjusting the price based on the determination.

12. The system of claim 10, wherein determining whether the demand for the service within the area matches the supply of the service within the area comprises: determining that the supply exceeds the demand for the service when the difference between the number of requests and the number of providers is less than a third threshold value, and the ratio between the number of providers and the number of requests is less than a fourth threshold value, andadjusting the price based on the determination.

13. The system of claim 10, wherein determining whether the demand for the service within the area matches the supply of the service within the area comprises setting the price based on a number of checks received for a price of the service within the area.

14. The system of claim 10, further configured to:calculate the difference and the ratio for each of a plurality of areas comprising the area, anddetermine a percentage of areas of the plurality of areas in which the demand for the service exceeds or is less than the supply for the service based on the calculated difference and ratio.

15. The system of claim 14, further configured to apply a weight on each area of the plurality of areas based on the price that is set for the service in each area of the plurality of areas.

16. The system of claim 15, further configured to:determine a first percentage of areas in which the demand for the service exceeds the supply for the service based on the applied weight, wherein the price that is set for the service is not bounded by a minimum price limit;determine a second percentage of areas in which the supply for the service exceeds the demand for the service based on the applied weight, wherein the price that is set for the service is not bounded by a maximum price limit;adjust the price further based on a difference between the first percentage and the second percentage.

17. The system of claim 15, further configured to determine a multiplier value based on the difference between the first percentage and the second percentage; and adjust the price according to the multiplier value.

18. The system of claim 14, further configured to determine a percentage of prices that are set in each of the plurality of areas that are bounded by a price limit, and adjusting the price limit based on the determined percentage.

Images