WO2022248904A1

WO2022248904A1 - Method of cost optimisation

Info

Publication number: WO2022248904A1
Application number: PCT/IB2021/054478
Authority: WO
Inventors: Ernest KETCHA NGASSAM; Sylvester HATSU
Original assignee: Ketcha Ngassam Ernest
Priority date: 2021-05-24
Filing date: 2021-05-24
Publication date: 2022-12-01

Abstract

This invention relates to a method of cost optimisation, more particularly a method of cost optimisation for purchasing and selling products and services online, the method including the steps of: a first customer identifying an offer present on a system, the system presenting the offer to a number of potential wholesale suppliers, the suppliers being provided an opportunity to present competing tenders, the system identifying at least one promising tender, the system sending the identified tender to a number of potential third-party customers, the third-party customers being provided an opportunity to accept at least part of the tender, the system facilitating a transaction between the supplier and the customers in order to provide an optimal profit to the supplier at an optimal cost to the customer

Description

METHOD OF COST OPTIMISATION FIELD OF THE INVENTION This invention relates to a method of cost optimisation, more particularly a method of cost optimisation for purchasing and selling products and services online. BACKGROUND TO THE INVENTION The rapid expansion of digitization in the global economy has significantly increased the reliance of people towards the use of digital media to perform various transactions that traditionally were performed through physical interactions. The process of buying and selling products and services over the internet, referred to as eCommerce is materialised through the enablement of an open marketplace with registered participants. Using a computing device connected to the internet, participants would register in the marketplace to advertise their services for provisioning and/or request service for consumption. The eCommerce marketplace is regarded as a key enabler of the digital economy and a prominent mechanism for its maturity. Thanks to this paradigm, digital transformation has become crucial for the survival of many organizations across industries. As such, the sustainability of many businesses would have a strong reliance on the materialization to their presence in the digital world by exposing their products and services in their ecommerce portal for real-time interaction with consumers. This phenomenon is further extended to individual consumers with the exponential growth of mobile money and mobile finance in the fintech industry. Mobile apps, ecommerce web portals for marketplace are all instruments for facilitating transactions on the web for the purpose of creating value. The traditional mode of operating in this case, no matter the kind of transaction being performed is based on one single business model: Advert–Request–Provision–Settlement. As such, any marketplace has products and services advertised at an appropriate cost. The consumer, after exploring interested services or products would initiate a service request if satisfied with terms and conditions. The provider will then pick the request and render the service with settlement performed either upfront or post-rendering to the satisfaction of the consumer. This traditional approach can be referred-to as the traditional ecommerce business model. Currently, all ecommerce marketplaces have adopted this traditional business model. The likes of eBay^TM, Amazon^TM, Alibaba^TM, sasayez^TM, Uber^TM have adopted this traditional approach to doing business on the web. Furthermore, multiple organizations have adopted the same model by linking their web portal to a so-called online store whereby their products are advertised with the possibility of customers to make purchases online and delivery at their doorstep. United States patent application number US 2020/0202401 A1 entitled: “System and method for obtaining competitive pricing for vehicle services” in the name of McQuade describes obtaining competitive pricing for vehicle servicing, a pricing service provider is used to obtain pricing data from a plurality of service vendors. In at least some embodiments, one or more of the following types of additional information for each vendor will be provided along with the pricing data, to enable the consumer (the owner or operator of the vehicle) to make an informed selection: a rating of the vendor, a relative distance between the consumer (or known vehicle location) and the vendor, and a time period defining when the vendor will be able to accommodate the service. In at least some embodiments, a pricing service provider hosts a reverse auction for the benefit of the consumer. In at least some embodiment, the pricing service provider hosts a webpage upon which results of the service requests from the plurality of vendors are displayed. McQuade describes obtaining competitive quotes for the servicing of a vehicle. OBJECT OF THE INVENTION It is an object of this invention to provide method of cost optimisation which, at least partially, alleviates some of the above-mentioned difficulties. SUMMARY OF THE INVENTION In accordance with this invention there is provided a method of cost optimisation, the method including the steps of: a first customer identifying an offer present on a system, the system presenting the offer to a number of potential wholesale suppliers, the suppliers being provided an opportunity to present competing tenders, the system identifying at least one promising tender, the system sending the identified tender to a number of potential third-party customers, the third-party customers being provided an opportunity to accept at least part of the tender, the system facilitating a transaction between the supplier and the customers in order to provide an optimal profit to the supplier at an optimal cost to the customer. The method further including the step where the system is an e-commerce system. The method further including the step where the offer is for that of a product or a service, the invention is not limited in this regard. The method including the steps of tracking the behaviour of the customers and the suppliers. The method further including the step wherein payment is made through the system. The method further including the step wherein the system deducts a facilitation fee from the amount paid by the customer before transferring payment to the supplier. The method further including the step wherein the third-party customers are retail outlets. The invention further provides for a method of cost optimisation, the method including the steps of: a customer identifying an offer present on a system, the system presenting the offer to a number of potential suppliers, the suppliers being provided an opportunity to present competing tenders, the system identifying at least one promising tender, the system facilitating a transaction between the supplier and the customer in order to provide an optimal profit to the supplier at an optimal cost to the customer. These and other features of the invention are described in more detail below. BRIEF DESCRIPTION OF THE DRAWINGS One embodiment of the invention is described below, by way of example only, with reference to the drawings in which: Figure 1 shows a schematic representation of a method of cost optimisation wherein an offer is identified and relayed to potential suppliers; Figure 2 shows a supplier responding with a promising counteroffer; Figure 3 shows payment being affected through the system; Figure 4 shows delivery of the product or service; Figure 5 shows the method of cost optimisation in a diagram form; and Figure 6 shows a logical component diagram of the method of cost optimisation. Figure 7 shows the overall architecture of the exobe opportunity algorithm of which the three main environments are similar to those described in Figure 6. DETAILED DESCRIPTION OF THE DRAWINGS With reference to the drawings, a method of cost optimisation is generally depicted by reference numeral 1. The method 1 includes in a first instance a step of a customer identifying an offer 3 for a product present on a system 4. The system 4 in a next step presents 5 the offer 4 to a number of potential wholesale suppliers 6. The suppliers 6 then has an opportunity to present competing tenders or competing offerings of similar products. The system will then identify at least one promising tender 8. This promising tender 8 will comprise a competing offer which is at a lower price than the original offer 3, however it may be at a wholesale price, or at a discounted price for a bulk order. The system 4 then sends 9 the identified tender 8 to a number of potential third-party customers 10, the third-party customers 10 being provided an opportunity to accept at least part of the tender, or in other words, part of the bulk offering made as part of the promising tender 8. The system 4 will facilitate a transaction between the supplier 7 and the customers 2,10 in order to provide an optimal profit to the supplier 7 at an optimal cost to the customers 2,10. This could mean that the supplier 7 sells a bulk order, and the customers 2,10 receive a number of items less than offered at the bulk or discounted price as part of the tender 8. In this embodiment, the method 1 is used for cost optimisation of a product, however the invention is not limited to the sale of products and can easily be used in the rendering of services. Where the system 4 is used to facilitate payment from the customers 2,7 to the supplier 7, the system 4 deducts a facilitation fee or percentage of the amount paid. This facilitation fee is paid over to the owner of the system 4 as remuneration for the use of the system 4. The supplier 7 will receive the remainder of the amount paid. The third-party customers 10, is other customers who have identified offers similar to the offer 3 which was identified by the first customer 2. The invention also provides for a situation where a potential wholesale supplier 6 provides a competing tender which directly competes with the offer 3 identified by the user 2. This will happen where the competing offer is not subject to a bulk discount or presented at a wholesale price. The method 1 is not limited to the use of selling products in an e-commerce environment and can be implemented in any number of appropriate environments: The method can be implemented in a rental environment for example renting of goods or property such as vehicles, housing, or industrial properties. The method can also be implemented to assist in the facilitation of loans, where more than one person can take out part of a larger loan offered at lower rates because the capital sum is larger. Transport of goods or people can by facilitated by means of the method. People looking to travel from similar departure point to similar destinations or any point on the route, can share the fare to allow drivers or shuttle companies to still make a profit whilst the passengers pay a diluted amount for the distance shared with other passengers. This can also be beneficial for courier, delivery or logistical companies to ensure that there is always a full delivery at a lower price to customers. In the following example the method is referred to as “EXOBE” (Exponential Open Business Ecosystem). The exponential open business ecosystem (exobe) as a 3-layered model, is a combination of a service development framework (Layer1), an application development platform (Layer 2), and an ecommerce marketplace (Layer 3) - realized by a mobile application and a web portal -, for co-creating value amongst participants. The ecosystem is context sensitive, trusted and secured by-design at all layers. In layer 3 (the exobe ecommerce marketplace - exobe application and exobe web portal), participants consist of registered trusted service requestors and service providers. Upon a service request, the opportunity algorithm is invoked to deliver optimal value to participants. The algorithm exploits the context, and the locality of reference of participants (including associated resources and transactions) in the marketplace for decision making. The second layer referred to as the exobe application development platform, is used to create and maintain mobile applications and web portals for the formation of ecommerce marketplaces that rely on the opportunity algorithm. In this layer, registered trusted developers would build and deploy custom applications powered by exobe to be consumed by service requestors and providers in layer 3 for value co- creation. The platform is source for exponential business creation. In fact, there is no limit on the number and kind of applications and logic thereof, that could be derived from the platform by developers. In the scope of this invention, a limited number of features of the exobe application will be registered. However, any developer making use to the platform resources may create more sophisticated applications and web portals beyond the scope of this invention. The service development framework, which is the first layer in the ecosystem, is used for the development and advertisement of atomic (Well-defined, self-contained function that does not depend on the context or state of other services) and complex (an assembly of atomic or other composite services) services used by exobe developers in layer 2 for applications and web portal development. Exposed services in this layer can also be consumed by third party application development platforms for the creation of third-party applications beyond the scope of this invention. The kind of services exposed in this layer are automatic, hybrid, and manual services. Figure 5 depicts the overall context diagram of the EXOBE ecosystem. The description and role of components in the diagram alphabetically annotated from 101 to 107 are better described through the following three process flows for value co-creation in the invention: Process flow 1: Step 201 to 210 – After the creation and advertisement of atomic and complex services in the exobe service development framework (101) by service developers, application developers will make use of the exobe application development platform (102) for the development of the Exobe application (103) deployed in application stores and downloaded by services providers and service requestors (201, 202, 203). A service requestor would then make use of the application to request for the service of which the opportunistic algorithm would make use to determine the optimal provider (204, 203). The provider will then render the service and value will be created (104) for all participants, namely satisfaction for the requestor, reward for the provider and reward for exobe (205, 206, 207, 208). Process flow 2: Step 301 to 304 – similar to the previous process flow, a developer would make use of the exobe application development platform (102) to develop and deploy custom applications (105) in application stores for usage by registered service providers and requestors (301, 302). The usage of the customs application would create value (104) for all stakeholders in the value chain with reward to the exobe application development platform (303, 304). Process flow 3: Step 401 to 405 – for this last process flow, application developers using third party platform for development (106) would consume services available in the Exobe service development framework in order to create third party applications (107) for usage by registered service providers and requestors (401, 402). The consumption of the service the developed application would create value (104) for all stakeholders, including a reward to the exobe service development framework (403, 404). EXOBE PROCESSES: EXOBE KNOWLEDGE BASE MANAGER (507) The Exobe Knowledge Base Manager (“EKBM”) plays a pivotal role in the entire exobe value chain at all layers. As already alluded herein, it provides real-time information for supporting the effectiveness and efficiency of activities in the exobe ecosystem. The specification of the EKBM in support of each layer on the exobe is provided in the following sub-sections: TRACKING THE PERFORMANCE OF EXOBE SERVICES The EKBM would gather information regarding the consumption and usage of each service in the registry. As such, each exobe service would be equipped with a sensor that frequently send the relevant information to the Knowledge Base repository for further analysis and decision making. Decision making would vary depending on the outcome of the analysis of the information gathered, ranging from enhancing the quality of service rendered by the service to that of improving its security because of control bypass by intruders. Beside improving the quality of the service, the outcome of the analysis by the EKBM would also help improve processes and functionalities in the service development framework for the purpose of making the entire service development lifecycle seamless. TRACKING THE PERFORMANCE OF EXOBE APPS Similar to the previous discussion, mobile application and web portal powered by the exobe application development platform are equipped with sensors feeding the EKBM with critical application performance metrics that are further analysed for decision making ranging from application feature enhancement to business process improvement or platform functionalities improvement. 360-DEGRE ON ECOMMERCE MARKETPLACE Tracking the performance of the exobe ecommerce marketplace would entail equipping the exobe application with a sensor collecting relevant key performance indicators on the behaviour of all stakeholders in the marketplace for analysis and further feature enhancement. Unlike the previous metric that are mostly geared toward technology. The metrics in this section tend to be more behavioural centric for the purpose of enhancing the quality of service rendered to end-user. For example, the outcome of an analysis by the EKBM may reveal that a user has a particular request/provisioning pattern that could be relied upon for the personalisation of service offering in order to improve user experience.

INPUT TO THE OPPORTUNITY ALGORITHM

The inference rule contributing to optimal decision making in the opportunity algorithm will be used as input into the knowledge base manager to: 1) ascertain the validity of the request made by the service requestors; 2) invite service providers to participate in the transaction; 3) invite additional potential requestors to participate in the transaction; 4) select providers and requestors matching the transaction; 5) render the service; 6) update trust and security score of participants.

Let SR (respectively SP) be the list of service requestors (resp. service providers) onboarded and active in the exobe marketplace. For n > 1 service providers (resp. requestors) in the marketplace, we will denote by SR_i(resp. SP_i i = 1.. n ), the i^th service requestor (resp. provider) in the list of providers (resp. requestors) in the marketplace. The list of providers and supplier is thus represented as follow: SR =

A participant (service requestor or provider) is eligible to transact in the marketplace if an only if the expression (i) below holds true.

[P(profile), T (trust), S(security), C (context), SL(Location), TL(Time)] =

(i) The expression consists of number of Boolean expressions that must

each be true before a participant qualifies for being party to a transaction in the marketplace. Most of those expressions described below, are also used for the 360- degree tracking of user performance in the marketplace.

• The expression P(SR_i) (resp. P(SP_i)) is used to determine whether the user profile is valid or not. The validity of a use profile would entail determining whether all the required KYC information regarding the user is valid and that there is nothing that required further update by the user. This assurance enables the EKBM to always make sure that participants” KYC are always up to date and that the latest update have been made by gathering the necessary intelligence. • T ( SR_i ) (resp. T ( SP_i )) enables to ascertain that the participant is still within the trust threshold as estimated from time to time by the EKBM. The participant would not be eligible if its trust score is less than the threshold. • The security assurance of participants provided by the expression S (SR_i ) (resp.S( SP_i )) enables the EKBM to determine if at the specific time of making a transaction and within that specific context and at that precise location, the participant’s security posture is guaranteed. • The context of the participant also plays an important role when performing a transaction, the EKBM will use C (SR_i ) (resp. C ( SP_i )) to determine the validity of the user context. • The spatial reference of the user determined by SL (SR_i ) (resp. SL ( SP_i )) is used to determine whether a current geographical location of the user is favourable to performing a transaction in the marketplace or not. • Similar to the previous expression, TL ( SR_i ) (resp. TL ( SP_i )) would be relied upon by the EKBM to ascertain whether the time window reserved for the transaction can be adhered to by the user or not. Based on the forgoing, after a full computation of E_p (SR_i ) (resp. E_p ( SP_i )) by the exobe knowledge base manager, the input to the opportunistic algorithm would be in the form of a set of providers (resp. requestors) that qualify to participate in the transaction. That’s when further steps in the algorithm would ensure that participants engage in the transaction for value co-creation. As discussed in this section, the knowledge base manager plays a central role in the entire exobe value chain and provide the required cognitive input to various components on exobe for intelligent decision making. EXOBE VALUE COORDINATOR (505) / DISTRIBUTE VALUE (504) The most important differentiator in exobe is value co-creation amongst participants. The co-creation of value beside the reliance on the opportunity algorithm for optimization entails gratification expectation by the service provider. In addition, the platform would also require some gratification as well as the various participants in the service rendering value chain. To avoid complexity, we will not handle the gratification of intermediaries. Therefore, the exobe value coordinator would typically have to perform three type of settlements once a transaction is completed. The expression ( ii ) below depicts what is used by the exobe value coordinator to perform a settlement.

The above expression demonstrates that the exobe value coordinator maintains a virtual wallet ( ^^ ^^) for all participants in the exobe ecosystem. The value ^^, of the service rendered by the provider to the requestor will then be deducted from the requestor’s virtual wallet and credited into the service provider’s virtual wallet with a transaction cost ^^ negotiated in advance when inviting the provider debited from that cost by the coordinator and credited to the exobe virtual wallet. This should be in principle how exobe generates revenue in the marketplace. The above equation is also true when dealing with custom applications powered by exobe in the sense that the business model remains unchanged. The value coordinator also handles the tracking of exobe service usage in third party applications powered by third party application development platforms. Through the EKBM and based on the business model between exobe and the third party, the coordinator will frequently receive the usage count of exobe service, associate the cost per usage and automatically calculate the value generated. Appropriate mechanism will be used to finalise settlement using conventional settlement channels integrated to exobe and beyond the scope of this invention. SERVICE DEVELOPMENT AND DEPLOYMENT (501) The exobe service development and deployment component is a framework whereby experts perform the development of native exobe services that guarantee trust, security and autonomy. The framework consists of engines that would be used for testing the developed services, ensure that their inherent properties are maintained before exposure (3) into the registry for consumption by exobe developers or third parties. The framework is also made of specialized engines for facilitating operation on services to produce complex services (2) from existing atomic services (601). Those operations include: aggregation, composition and integration. In addition to those, the EKBM feeds critical performance information to this component for further usage and decision making by its analytics sub-component (604). APPLICATION DEVELOPMENT AND PUBLISHING (502) This component is as platform for facilitating the development of native exobe applications (605) using native exobe services exposed in (501). The core exobe application integral to this invention will be built through this platform as well as improvement and future releases (607). Furthermore, custom applications will also be built and published (606) through the platform. The platform is also supplied with performance related feed from the EKBM for analytics (608) and decision making on future enhancements. TRANSACT IN MARKETPLACE (503) This component represents the usage of application or web portal functionalities of the exobe ecommerce marketplace, or any other marketplace powered by exobe. Whether an ecommerce transaction is performed within the native or custom app, the operational model remains the same. The transaction would then consist of the use of the opportunity algorithm that would perform intelligent service request and provisioning to deliver optimized value to participants. The analytics sub-component provides insights on the performance of participants in the marketplace. Outcome of analytics are exploited for the enhancement of the applications as well as the improvement of the entire exobe ecosystem. THE EXOBE OPPORTUNITY ALGORITHM The exobe opportunity algorithm’s objective is to ensure that all participants in the marketplace achieve optimal value when engaging in a transaction. The algorithm is triggered whenever a requestor perceives a need in the marketplace and initiates the request for the service to be rendered. The algorithm is then invoked for the purpose of making sure that the requestor is provided with the best possible deal along with other participants that would be interested in such deal. This is achieved by going to the service providers to seek for a better deal under certain conditions. Once the service providers are recruited, the exobe algorithm has at its disposal a list of qualifying service providers with their conditions to offer the service. Next, the algorithm invites additional requestors to participate in the deal under a range of conditions in alignment to those of the selected providers. The outcome of such invitation results in exobe having a list of requestors interested in participating in the listed deals. The algorithm then produces a set of transaction pairs consisting of a requestor and a provider under the agreed conditions and the rendering part of the service starts. Upon completion of the rendering, the distribution of value to all participants takes place and the deal is concluded. Note the following observation from this narrative: • The initial service requestor is guaranteed that the advertised cost relied upon to initiate the deal would likely end up being cheaper after concluding the transaction. • The transaction would end up being between a provider to many requestors (including the initial requestor) • For other participants, the deal’s cost may be higher than that of the initial requestor. Nonetheless, there would always be value realisation in the deal compared to the original cost advertised to the initial requestor. EXOBE OPPORTUNITY ALGORITHM: OVERVIEW Figure 7 depicts the overall architecture of the exobe opportunity algorithm of which the three main environments are similar to those described in Figure 6. Components in the algorithm such as the exobe knowledge base manager, the service provider and requestor DB definition and description remain unchanged. Participants in the exobe application user pane is made up of the initial service requestor, invited service providers as well as additional service requestors invited and approved as participants to the current transaction. In addition to already described repositories, the algorithm would maintain a table of optimized deals that have been concluded in the marketplace with relevant data sent to the EKBM for further analytics. EXOBE OPPORTUNITY ALGORITHM: PRE-CONDITIONS The following preconditions have to be met before the exobe algorithm is executed. • Exobe Application or Exobe web portal: This is the medium relied upon to participate in the exobe ecommerce marketplace. This is achieved by using the exobe application accessible through a mobile phone after being downloaded from an application store. An alternative would be to access the ecommerce marketplace through the exobe web portal from any web browser though an endpoint connected to the internet. • Exobe use cases: for the purpose of this invention, the exobe application and web portal would deliver the following use cases: Buy, sell, rent, borrow, donate, commute, transport, courier, exchange, learn. Therefore, a user accessing the native exobe marketplace may be able to perform any of the foregoing transactions provided a successful registration and onboarding. Any additional use case would be delivered through custom applications powered by exobe. The custom application would rely on the same exobe business model but will not be a feature of the native exobe app. • User onboarding: Service providers and requestors will be onboarded in the application following an appropriate vetting process revealing the user’s initial trust and security score. A user can be onboarded as a provider and a requestor. As such, a user may act in either capacity as needed. A service provider can be an individual or an organization of any size represented by an individual. In exobe an individual can grow from offering only a single service to offering multiple services and thereby becoming an organization of significant size. Target organizations to participate in the exobe ecosystem fall under any industry without restriction, provided that they can consume or provide native targeted services in the marketplace. • User Eligibility: A participant must be eligible to take part in a transaction in the marketplace. As already discussed, the following must hold: E_p ( SR_i) = true (resp. E_p ( SP_i ) = true ) for a given service requestor (resp. provider) EXOBE OPPORTUNITY ALGORITHM: PROCESSES As previously discussed, the exobe knowledge base manager plays a pivotal role in the entire exobe ecosystem. Therefore, any processed discussed in this section would have a feed to the EKBM in order to ensure that the cognitive aspect of the algorithm and inference rules are as accurate as possible to facilitate decision making. The algorithm starts with a trigger from a user requesting for a service. The service request can be any service that form part of the native exobe marketplace. Moreover, any other service available as part of custom-built marketplace would follow the same approach. OPPORTUNITY ALGORITHM PROCESS: SERVICE REQUEST-PROVISIONING In the marketplace, services are advertised for each category as well as associated condition of service. If for example a user wants to buy an item in the marketplace, by going into the buy functionality of the app, a catalogue of goods, their cost and the SLA attached to such purchase will be presented to the end user who will then agree and trigger the rendering of the service. The service request is thus performed in the following steps: • Step 1: Access the marketplace with appropriate credentials, saysSR_i ; • Step 2: Explore advertised services and condition of services; • Step 3: Identify desired services and conditions thereof; • Step 4: EKBM gets participant’s information from the knowledge base as well as required real-time information; • Step 5: EKBM computes E_p ( SR_i ): o Step 5.1: if E_p ( SR_i ) = false, theen the service requestor is not eligible to perform this service; reasons for non-eligibility are provided. The service requestors may then go and fix any issue regarding eligibility and go back to step 1 if so which; o Step 5.2: if E_p (SR_i ) = true , then the service requestor is eligible to proceed to step 6; • Step 6: call supplier and potential consumer invitation process for the purpose of optimal value creation to the service requestor as well as value optimization to the potential consumers and providers; • Step 7: perform provisioning services by eligible service providers to the updated list of consumers including the initial the service requestor; and • Step 8: Update Knowledge base

Algorithm 1: Service request and provisioning process OPPORTUNITY ALGORITHM PROCESS: PROVIDER INVITATION This process is triggered once an opportunity is perceived in the marketplace by the EKMB upon a successful eligibility of the service requestor. Given r_i(SR_i , c_i), a service request r_i initiated by the service requestor SR_i at the cost of c_i, the provider invitation process will explore the service provider database to determine the set of providers that may offer the required service to the consumers. Then would request for a better deal should the number of consumers increases. The service provider would then respond to the invitation by releasing the triplet r_i( SP _k, rc_k, min_k ). Meaning that, the provider SP_k would be able to render the service r_i at a reduced cost rc _k ≤ c_i, provided that a minimum of min_k services are signed up for. The process will then generate a list of such eligible service providers capable of rendering the service to available consumer within the required time windows and geographical location at variable costs and minimum sin-up values. The process is summarized in the following steps: • Step 1: Open the service provider database; • Step 2: select service providers capable of offering the service requested; • Step 3: Send a request for cost optimization to the service provider; • Step 4: receive the provider’s cost of service and the minimum threshold for provisioning; • Step 5: update the list of invited service providers;

Algorithm 2: Service Provider invitation OPPORTUNITY ALGORITHM PROCESS: CONSUMER INVITATION Once the commitment is concluded with the service providers, the next step is to invite additional consumers of the services. Of course, the worst-case scenario would be that the service is rendered by a default supplier to the initial requestor with no cost reduction. For simplicity, we order the service providers offerings from the most competitive offer to the least competitive offer, knowing that even the least competitive would be of value to the initial requestor. The invitation of additional consumers would then be done sequentially, by first advertised to most competitive offer before moving to the next offer. Service will be rendered on a first accepted first serve basis provided that the minimum threshold required for rendering the service is met. • Step 1: get the most competitive offer from the list of invited eligible service providers; • Step 2: send the offer to eligible requestors and invite to participate; • Step 3: Receive response from eligible requestors; • Step 4: Update the consumers of services from the current most competitive provider; • Step 5: move to step 1 until the list is exhausted;

Algorithm 3: Consumer invitation process OPPORTUNITY ALGORITHM PROCESS: SERVICE PROVISIONING Once the list pairing invited service providers to invited service consumers as well as the various conditions around the service offering is available, the next step is to trigger the provisioning of the service. One or more suppliers would then render the service ^^ _^^ to one or more consumers of the service as follow: • Step 1: Get the list of confirmed triplets (provider, consumer, condition); • Step 2: Request the provider to render the service to the consumer; o Step 2.1: track the rendering process and supplied KPI information to the KB; o Step 2.2: If there is an exception throughout the rendering process trigger mitigation plan; • Step 3: get completion notification from provider; • Step 4: get completion confirmation from consumer; and • Step 5: Update knowledge base with consumer and provider KPIs.

Algorithm 4: Service provisioning process OPPORTUNITY ALGORITHM PROCESS: VALUE DISTRIBUTION This is the last process of the opportunity algorithm that consists of distributing agreed value to the various participants in the value chain. As discussed herein, the distribution of reward is straightforward and entails depleting the virtual wallet of the consumer and crediting that of the suppliers and exobe. Note that in the opportunity algorithm, we only cater for the distribution of value to participants in the native exobe marketplace as well as marketplaces powered by exobe. The value distribution resulting from the consumption of exobe services is not part of the opportunity algorithm and should be handled following commonly agreed reward mechanism between the consumer of exobe service and third-party developers. As previously discussed, the EKBM has the ability to track of the consumption KPIs from third party in order to make an informed decision regarding the cost generated. It is in envisaged that the method will become part of a larger ‘reverse online trading platform’ to allow users to input information regarding a vast array of products sought. Online auction houses enjoy a large portion of the world wide web and this reverse auction method could easily become part thereof. It will be appreciated by those skilled in the art that the invention is not limited to the precise details as described herein. The method does not need to be used for a profit and can be used for donations or exchange of goods or services. The method can also incorporate a user inputting what they require to have an array of suppliers respond with tenders which they are willing to offer.

Claims

CLAIMS 1. A method of cost optimisation, the method including the steps of: a first customer identifying an offer present on a system, the system presenting the offer to a number of potential wholesale suppliers, the suppliers being provided an opportunity to present competing tenders, the system identifying at least one promising tender, the system sending the identified tender to a number of potential third-party customers, the third-party customers being provided an opportunity to accept at least part of the tender, the system facilitating a transaction between the supplier and the customers in order to provide an optimal profit to the supplier at an optimal cost to the customers. 2. The method according to claim 1 wherein the system is an e-commerce system. 3. The method according to any of the preceding claims wherein the offer is for a product. 4. The method according to any of the preceding claims wherein the offer is for a service. 5. The method according to any of the preceding claims wherein payment is made through the system. 6. The method according to any of the preceding claims wherein the system deducts a facilitation fee from the amount paid by the customer before transferring payment to the supplier. 7. The method according to any of the preceding claims wherein the third- party customers are retail outlets. 8. A method of cost optimisation, the method including the steps of: a customer identifying an offer present on a system, the system presenting the offer to a number of potential suppliers, the suppliers being provided an opportunity to present competing tenders, the system identifying at least one promising tender, the system facilitating a transaction between the supplier and the customer in order to provide an optimal profit to the supplier at an optimal cost to the customer.