A SYSTEM AND METHOD TO MANAGE DATA EXCHANGE ACROSS A PLURALITY OF DATA ACCESS PORTALS
Field of the Invention
The present invention relates to a system, and method to manage data exchange across a plurality of data access portals.
Background
In the current digital e-commerce landscape, consumers often access aggregator marketplaces like, for example, Amazon, Taobao, Wish, eBay and the like for their shopping. These aggregator marketplaces typically allow access to respective digital merchant stores, and even respective products and services by the merchants globally.
Even though such aggregator marketplaces are convenient for consumers and safe with price transparency/refund policies, the merchants often have to employ strategies to distinguish themselves from one another, and that can be a challenging proposition for some merchants.
Typically, the merchants at the aggregator marketplaces find themselves in competition with one another, and the attrition rate resulting from such competition can be substantial given how highly competitive it is. In addition, when merchants become part of the aggregator marketplaces, they also typically lose the capacity to build up their individual identity and reach consumers directly with personalised offerings since it can be challenging to manage both their aggregator marketplace profile, and their own website. Unfortunately, this also leads to commoditization of the goods and/or services provided by the merchants. Thus, it should be appreciated that this inter-merchant competition may benefit consumers in the short term, but not in the long term as the exit/closure of merchants from the competition will lead to fewer options for consumers. In addition, merchants also do not appear to have an alternative if they choose to be a part of an aggregator marketplace.
Furthermore, the aforementioned issues also apply to vertical marketplaces as well. Typically, vertical marketplaces have a niche target segment and merchants are primarily competing with each other.
In the current business environment, network effects are mechanisms in a product and business where every new user makes the product or service more valuable for related stakeholders in an inter-connected eco-system. This aids in value creation and business sustainability in the hyper-competitive digital world.
It should be appreciated that enabling the network effects is likely to provide positive benefits to the related stakeholders, and such a facility is currently lacking.
Summary
In a first aspect, there is provided a system to manage data exchange across a plurality of data access portals, the system comprising at least one data processor configured to: enable data access to the plurality of data access portals; assess, at a central administrator, respective partners of the plurality of data access portals; transmit, from a customer device, a customer request; transmit, from the central administrator, the customer request to the plurality of data access portals; aggregate, at the central administrator, responses received from the plurality of data access portals; process, at the central administrator, the received responses by ranking the responses in accordance with a profile of the respective partners.
It is preferable that the profile of the respective partners is able to continually evolve in accordance with a linkage density of the respective partners.
In a second aspect, there is a data processor implemented method to manage data exchange across a plurality of data access portals, the method comprising: enabling data access to the plurality of data access portals; assessing, at a central administrator, respective partners of the plurality of data access portals; transmitting, from a customer device, a customer request; transmitting, from the central administrator, the customer request to the plurality of data access portals; aggregating, at the central administrator, responses received from the plurality of data access portals; processing, at the central administrator, the received responses by ranking the responses in accordance with a profile of the respective partners.
It is preferable that the profile of the respective partners is able to continually evolve in accordance with a linkage density of the respective partners.
It will be appreciated that the broad forms of the invention and their respective features can be used in conjunction, interchangeably and/or independently, and reference to separate broad forms is not intended to be limiting.
Brief Description of the Drawings
A non-limiting example of the present invention will now be described with reference to the accompanying drawings, in which: FIG 1 provides a schematic view of partner functionality within an eco-system;
FIG 2 provides a schematic view of customer functionality within an eco-system;
FIG 3 provides a schematic view of central administrator functionality within an ecosystem;
FIG 4 provides screenshots of a partner access portal;
FIG 5 provides screenshots of a central administrator access portal;
FIG 6 provides screenshots of a customer access portal;
FIG 7 is a flow chart of an example of a method to manage data exchange across a plurality of data access portals;
FIG 8 is a schematic diagram of an example of a system to manage data exchange across a plurality of data access portals;
FIG 9 is a schematic diagram showing components of an example user device of the system shown in FIG 8;
FIG 10 is a schematic diagram showing components of an example central server shown in FIG 8;
FIG 1 1 is a flow chart of an example customer process for the present invention; and FIG 12 is a flow chart of an example partner process for the present invention.
Detailed Description
The present invention provides a system and method to manage data exchange across a plurality of data access portals, primarily to enable network effects. The system and method broadly allows a customer to access data from at least one data access portal, whereby pertinent data of the customer pursuant to the customer’s request(s) is then shared among a plurality of data access portals, whereby the customer is then provided with a variety of information for the customer’s consideration. The system and method is able to save the customer a substantial amount of effort and time when seeking, for example, goods and services. In addition, the system and method is able to provide the data access portal owners (for example, partners) an opportunity to be exposed to customers who would otherwise not know about the data access portal owners. For the purpose of illustration, it is assumed that the method can be performed at least in part amongst one or more data processing devices such as, for example, a mobile phone, a central server, or the like. Typically, the central server will be configured to carry out a majority of the processing tasks, with the mobile phone being configured to display outputs from the central server.
In the present invention, an eco-system is interconnected with data systems of both customers and partners. The eco-system can be seen to be made up of nodes and links. Nodes are participants of the eco-system - customers, and partners using their respective devices. It should be noted that partners can also include brokers. Different types of nodes carry out different roles/tasks within the eco-system. Central nodes are nodes in a network with a high number of links and are typically more valuable in a manner which will be explained in a subsequent section. Typically, such nodes are prioritised, which will be explained in a subsequent section. Similarly, marginal nodes have relatively few links and are correspondingly of lower priority, although there can be exceptions. For example, if a marginal node is connected to a few high priority nodes. Determining a value of a node can vary for different eco-systems. The value of a node can be determined by an administrator of the eco-system.
In the eco-system, the interconnectivity of links enable reinforcement and strengthening of connections between related nodes. For example, a customer of a platform who is connected to a plurality of service providers/communities will have the engagement opportunities to form stronger connectivity with the service providers/communities and interactions than if the customer was not on the platform.
It should be appreciated that each link in the eco-system can relate to, for example, transfer of money, information, communication, and anything else that can pass between nodes as they interact. In order to better understand the present invention, further details will be provided on the interface and functionality enabled for each node of the eco-system.
Referring to FIG 1 , there is shown a schematic view of partner functionality within the eco-system. It should be noted that partner can refer to, for example, merchants and brokers. An embodiment of a partner interface 100 is shown. The partner interface 100 can comprise modules shown in FIG 1 , although the partner interface 100 need not comprise only the modules as shown. The partner interface 100 can comprise more or fewer modules, depending on a configuration of the partner interface 100, which can be dependent on the eco-system as configured.
The partner interface 100 can include, for example, an agent module 105, a company information module 1 10, a document template module 1 15, a messaging module 120, a customers module 125, a new business leads module 130, and an account module 135.
Agent module 105 - This module relates to management of a representative of the partner who engages directly with the customer.
Company information module 1 10 - This module relates to management of information pertaining to the partner.
Document template module 1 15 - This module relates to the provision of pertinent documents to ensure that the partner and the customer maintain legally binding obligations to one another when the partner provides a good/service to the customer.
Messaging module 120 - This module provides the partner with a facility to communicate with the customer within the eco-system.
Customers module 125 - This module relates to management of customers who are serviced by the partner. New business leads module 130 - This module relates to management of potential customers arising from engagements arising from within the eco-system.
Account module 135 - This module relates to management of the partner’s account in the eco-system.
It should be appreciated that the partner interface 100 allows partners to carry out at least the following tasks:
- manage resources when servicing a customer(s);
- disseminate information throughout the eco-system;
- ensure that legal obligations are in place within the eco-system;
- communicate with a customer(s);
- managing expectations of a customer(s);
- developing a pipeline of opportunities to be sought; and
- maintaining relevance in the eco-system.
Referring to FIG 2, there is shown a schematic view of customer functionality within the eco-system. It should be noted that customer can refer to, any recipient of a good/service provider by a partner of the eco-system. An embodiment of a customer interface 200 is shown. The customer interface 200 can comprise modules shown in FIG 2, although the customer interface 200 need not comprise only the modules as shown. The customer interface 200 can comprise more or fewer modules, depending on a configuration of the customer interface 200, which can be dependent on the ecosystem as configured.
The customer interface 200 can include, for example, an trigger module 205, a messaging module 210, a payment module 215, a budgeting module 220, a check-list module 225, a proposal module 230, and an community module 235. Trigger module 205 - This module relates to management of a partner who engages directly with the customer to initiate engagement of the good/service.
Messaging module 210 - This module provides the customer with a facility to communicate with the partner within the eco-system.
Payment module 215 - This module relates to a payment facility to enable payment from the customer to the partner and refunds from the partner to the customer.
Budgeting module 220 - This module relates to management of financial resources for the customer.
Check-list module 225 - This module relates to management of task lists for the customer.
Proposal module 230 - This module relates to management of quotations from partners for consideration and acceptance by the customer.
Community module 235 - This module facilitates exchange of information amongst customers and partners in the eco-system.
It should be appreciated that the customer interface 200 allows customers to carry out at least the following tasks:
- initiate engagement with a partner(s) for a good/service;
- communicate with a partner(s);
- make payment to a partner(s);
- financial resource planning;
- project planning;
- consider a proposal(s) from a partner(s);
- share and gather information in the eco-system. Referring to FIG 3, there is shown a schematic view of administrator functionality within the eco-system. It should be noted that administrator can refer to, any entity managing the eco-system. An embodiment of an administrator interface 300 is shown. The administrator interface 300 can comprise modules shown in FIG 3, although the administrator interface 300 need not comprise only the modules as shown. The administrator interface 300 can comprise more or fewer modules, depending on a configuration of the administrator interface 300, which can be dependent on the ecosystem as configured.
The administrator interface 300 can include, for example, a partner management module 305, a service management module 310, an articles management module 315, a customer management module 320, and a proposal management module 325.
Partner management module 305 - This module relates to management of a partner in the eco-system.
Service management module 310 - This module provides the administrator with a facility to communicate with the partner and customer, particularly in the event of any dispute between parties.
Articles management module 315 - This module provides the administrator with a facility to manage information oriented content stored on the eco-system.
Customer management module 320 - This module relates to management of a customer(s) in the eco-system.
Proposal management module 325 - This module relates to management of proposals made to a customer(s) carried out within the eco-system. It should be appreciated that the administrator interface 300 allows the administrator to carry out at least the following tasks:
- manage a partner(s);
- liaise with a partner(s) and a customer(s);
- manage information-oriented content on the eco-system;
- manage a customer;
- managing proposals made in the eco-system; and
- consider a proposal(s) from a partner(s).
Some screenshots of respective portals will now be described for illustrative purposes.
FIG 4 shows some screenshots of a partner portal. FIG 4(A) shows a dashboard of partner activity in the eco-system. For example, a snapshot of partner activity is indicated to provide the partner with an indication of how the partner’s business is tracking.
FIG 4(B) shows a leads management interface. For example, a snapshot of a current status of a lead is indicated.
FIG 4(C) shows information (including requirements and communication history) pertaining to one of the leads, whereby the information is accessible from the leads management interface of FIG 4(B).
FIG 4(D) shows a customer status list. For example, a snapshot of progress made for respective customers is indicated.
FIG 5 shows some screenshots of an administrator portal. FIG 5(A) shows a partner management list. For example, a snapshot of a current status of progress made by respective partners is indicated. FIG 5(B) shows a customer management list. For example, a snapshot of a status of respective customers is indicated.
FIG 5(C) shows an information-oriented contents list. For example, a list of informative content is provided for reference by customers.
FIG 5(D) shows a service type management list. For example, a snapshot of available services provided by partners is indicated.
FIG 6 shows some screenshots of a customer portal. FIG 6(A) shows a dashboard for a customer. For example, the customer is able to obtain a snapshot of ongoing tasks being carried out, completed tasks and personal reminders.
FIG 6(B) shows a project management interface, for example, for inputting personal reminders as shown in FIG 6(A).
FIG 6(C) shows an interface for seeking a detailed proposal from a partner. It should be noted that the listing of partners in the interface is ranked in a manner as described in a subsequent section.
FIGs 6(D) to 6(G) show an interface for entering into an agreement with a partner, whereby FIG 6(D) shows a form for seeking a service from a partner(s), and FIG 6(E) shows a communication (texting) interface. FIGs 6(F) and 6(G) show a snapshot of a proposal for customers’ consideration and the service engagement confirmation signature page respectively.
It should be appreciated that the preceding description is provided to enable a better understanding of the present invention.
An example of a broad overview of a method 700 to manage data exchange across a plurality of data access portals will now be described with reference to FIG 7. In some embodiments, a data access portal can refer to a partner website that is publicly accessible. In some embodiments, the method 700 is carried out within the ecosystem as described in the prior sections.
At step 705, data access to a plurality of data portals is enabled. This can be done using APIs, and is carried out with the consent of owners of the data portals (partners). The data access to the plurality of data portals can be facilitated by a central administrator. The central administrator can be, for example, an aggregator which brings together partners and customers to participate in the eco-system. In the method 700, the central administrator should provide partner functionality as described in relation to FIG 1 , customer functionality as described in relation to FIG 2, and central administrator functionality as described in relation to FIG 3 in order to ensure that the method 700 can be carried out.
At step 710, the central administrator carries out an assessment of respective partners of the plurality of data portals. This can be carried using a profiling methodology and/or a scoring methodology. For example, the partners can be assessed on whether they are a central node in the eco-system. It should be appreciated that the assessment is necessary to provide a desirable outcome for the data exchange across a plurality of data access portals, for example in relation to partner search results provided to customers. It should be noted that step 710 can also be carried out at any juncture after a respective data access portal is on-boarded onto the eco-system.
At step 715, a customer request is transmitted from a customer device to the central administrator. This can be carried out via the interface as shown in FIG 6. The customer device can be, for example, a mobile phone, a tablet, a laptop, and the like. Typically, the customer request includes parameters such as, for example, desired goods/services, date for desired goods/services, cost expectations, and so forth. The customer request can be made when a customer profile stored with the central administrator is active on the user device. The customer profile is advantageous in being able to provide more parameters in the customer request without input by a customer.
At step 720, the customer request is transmitted to the plurality of data portals via the central administrator, whereby the respective data portals process the various parameters of the customer request in order to prepare a proposal in relation to the user request. Each partner is able to manage the customer request via the interface as shown in FIG 4.
At step 725, the central administrator then aggregates responses from the respective data portals. The responses can be, for example, cost quotations, descriptions of goods/services, terms of goods/service delivery, and so forth. The responses are meant for consideration by a user transmitting the user request. The central administrator is able to carry out requisite tasks via the interface as shown in FIG 5.
At step 730, the central administrator further processes the responses by ranking them in accordance with the assessment of respective partners carried out at step 710. By doing so, the customer considering the aggregated responses from the respective data portals would be able to make an easier decision based on an implicit trust in the ranking of the responses.
It should be noted that the method 700 is able to save the user a substantial amount of effort and time when seeking, for example, goods and services. In addition, the method 700 is able to provide the partners an opportunity to be exposed to consumers who would otherwise not know about the partners, for example, due to lack of company recognition or visibility. It should be appreciated that this ties into how partners evolve into central nodes in the eco-system, as their recognition or visibility increases. As mentioned previously, central nodes are nodes in a network with a high number of links and are typically more valuable. Typically, such nodes are prioritised, and given a higher ranking. It should also be noted that the method 700 allows marginal nodes to become central nodes, and this can be perceived to the growth of a business.
An example of a system 800 to manage data exchange across a plurality of data access portals will now be described with reference to FIG 8.
In this example, the system 800 includes one or more user devices 820, a communications network 850, a third party portal 880 (eg. a partner’s website), and a central server 860 (eg. an eco-system central administrator). The one or more user devices 820 and the one or more third party portals 880 communicate with the central server 860 via the communications network 850. The communications network 850 can be of any appropriate form, such as the Internet and/or a number of local area networks (LANs). Further details of respective components of the system 800 will be provided in a following portion of the description. It will be appreciated that the configuration shown in FIG 8 is not limiting and for the purpose of illustration only.
User Device 820
The user device 820 of any of the examples herein may be a handheld computer device such as a smart phone with a capability to access the internet and/or download and operate mobile applications, while being connectable to the communications network 850. The user device 820 should be able to run the interface of FIG 6 when it is used by a customer. In addition, the user device 820 should also be able to run the interface of FIG 4 when it is used by a partner. Similarly, the user device 820 is also able to run the interface of FIG 5 when it is used by a central administrator. Thus, it should be appreciated that the user device 820 can be used by any of customer, partner or central administrator when using the method 700 in the eco-system.
The user device 820 can also be a tablet or a laptop. An exemplary embodiment of the user device 820 is shown in FIG 8. As shown, the user device 820 includes the following components in electronic communication via a bus 91 1 : 1. a display 902;
2. non-volatile memory 903;
3. random access memory ("RAM") 904;
4. data processor(s) 901 ;
5. a transceiver component 905 that includes a transceiver(s);
6. an image capture module 910; and
7. input controls 907.
In some embodiments, an app 909 stored in the non-volatile memory 903, is required to enable the user device 820 to operate in a desired manner. For example, the app 909 can provide user interfaces as described in FIGs 4-6. In addition, the app 909 can also be configured to provide the functionalities as described in FIGs 1 -3.
Although the components depicted in FIG 9 represent physical components, FIG 9 is not intended to be a hardware diagram; thus many of the components depicted in FIG 9 may be realized by common constructs or distributed among additional physical components. Moreover, it is contemplated that other existing and yet-to-be developed physical components and architectures may be utilized to implement the functional components described with reference to FIG 9.
Central Server 860
The central server 860 is a hardware and software suite comprised of preprogrammed logic, algorithms and other means of processing information coming in, in order to send out information which is useful to the objective of the system 800 in which the central server 860 resides. For the sake of illustration, hardware which can be used by the central server 860 will be described briefly herein.
The central server 860 can broadly comprise a database which stores pertinent information, and processes information packets from the user devices 820. In some embodiments, the central administrator access portal runs on the central server 860. The central server 860 can be operated from a commercial hosted service such as Amazon Web Services.
In one possible embodiment, the central server 860 is represented in a form as shown in FIG 10.
The central server 860 is in communication with a communications network 850, as shown in FIG 4. The central server 860 is able to communicate with the user devices 820, and/or other processing devices, as required, over the communications network 850. In some instances, the user devices 820, communicate via a direct communication channel (LAN or WIFI) with the central server 860.
The components of the central server 860 can be configured in a variety of ways. The components can be implemented entirely by software to be executed on standard computer server hardware, which may comprise one hardware unit or different computer hardware units distributed over various locations, some of which may require the communications network 850 for communication.
In the example shown in FIG 10, the central server 860 is a commercially available computer system based on a 32 bit or a 64 bit Intel architecture, and the processes and/or methods executed or performed by the central server 860 are implemented in the form of programming instructions of one or more software components or modules 1002 stored on non-volatile computer-readable storage 1003 associated with the central server 860.
The device 860 includes at least one or more of the following standard, commercially available, computer components, all interconnected by a bus 1005:
1. random access memory (RAM) 1006; and
2. at least one central processing unit (CPU) 1007. Although the components depicted in FIG 10 represent physical components, FIG 10 is not intended to be a hardware diagram; thus many of the components depicted in FIG 10 may be realized by common constructs or distributed among additional physical components. Moreover, it is contemplated that other existing and yet-to-be developed physical components and architectures may be utilized to implement the functional components described with reference to FIG 10.
Third party portal 880
The respective third party portals 880 can be operated from a commercial hosted service such as Amazon Web Services or from a server similar to the central server 860. It should be appreciated that the respective third party portals 880 can be company webpages that may have an e-commerce component that can operate independently of the central server 860.
It should be appreciated that the system 800 enables benefits for both customers and partners, particularly when the system 800 is used to carry out the method 700. It should be noted that the system 800 is able to save the customer a substantial amount of effort and time when seeking, for example, goods and services. In addition, the system 800 is able to provide the data access portal owners (for example, partners) an opportunity to be exposed to customers who would otherwise not know about the partners, for example, due to lack of company recognition or visibility. It should be appreciated that this ties into how partners evolve into central nodes in the ecosystem, as their recognition or visibility increases. As mentioned previously, central nodes are nodes in a network with a high number of links and are typically more valuable. Typically, such nodes are prioritised, and given a higher ranking. It should also be noted that the system 800 allows marginal nodes to become central nodes, and this can be perceived to the growth of a business. Referring to FIG 11 , there is shown an example of a customer process 1 100 for the present invention. The process 1 100 is able to provide a perspective of a customer experience in relation to the present invention and how the customer is able to benefit from the process 1 100.
At step 1 105, the customer accesses a eco-system using either an app or a webpage on their user device. Typically, the customer accesses the eco-system seeking a good/service. For the sake of illustrating the process 1100, the customer can be seeking a service provider for international home relocation services. Typically, the customer interacts with the interface of FIG 6.
At step 1 1 10, the customer then provides parameters for the required good/service, the parameters being, for example, dates for the good/service, add-ons to the good/service, cost constraints for the good/service and so forth. For the sake of illustration, the parameters are departure date for new resident country, arrival date at new resident country, need for pet moving support, need for pet quarantine support, cost expectation, and so forth.
Once the parameters are entered, the customer then receives a listing of available goods/services for consideration on their user device at step 1 1 15. It should be noted that the customer may be presented with a selection of goods/services by providers from different industries. For example, the selection can include moving companies, pet moving companies, and other companies as required pursuant to the parameters provided by the user. It should be appreciated that step 11 15 can be nearly instantaneous after step 1 1 10, or it can occur after a period of time. It should be appreciated that the customer may not realise that the listing of available goods/services is ranked in accordance with the parameters that were input and also in accordance with a rank of a partner in the eco-system.
At step 1 120, the customer then proceeds to select the required good/service, and in some embodiments, payment can be made at the juncture of selecting the required good/service. The payment can be in part or in full and can be carried out at the interface of FIG 6.
Based on the preceding paragraphs pertaining to process 1 100, it should be noted that the eco-system is a “one-stop shop” for the customer, and is able to provide appropriate choices for the customer’s consideration, similar to a premium concierge service which provides bespoke recommendations based on the parameters entered earlier.
Referring to FIG 12, there is shown an example of a partner process 1200 for the present invention. The process 1200 is able to provide a perspective of a partner experience in relation to the present invention and how the partner is able to benefit from the process 1200.
At step 1205, the partner receives a request from the central administrator, the request being generated by a customer seeking a good/service. Typically, the customer accesses the eco-system seeking a good/service. For the sake of illustrating the process 1200, the customer can be seeking a service provider for international home relocation services.
At step 1210, upon receiving the request, the partner then puts together a proposal pursuant to parameters for the good/service provided in the request, the parameters being, for example, dates for the good/service, add-ons to the good/service, cost constraints for the good/service and so forth. For the sake of illustration, the parameters are departure date for new resident country, arrival date at new resident country, need for pet moving support, need for pet quarantine support, cost expectation, and so forth. After the proposal is put together, it is then sent to the central administrator to be forwarded to the customer. It should be noted that step 1210 can be nearly instantaneous after step 1205, or it can occur after a period of time. In addition, It should be appreciated that the proposal is ranked in accordance with the parameters that were input by the customer and a ranking of the partner. In this regard, the merchant has a tangible motivation to improve their ranking to improve their own commercial interests.
Subsequently, the partner then waits for an engagement response from the customer at step 1215 after the customer has made their choice(s).
Based on the preceding paragraphs pertaining to process 1200, it should be noted that the eco-system provides a pool of customers for the merchant who may not be familiar with the partner, and the eco-system is able to enable a premium concierge service which provides bespoke recommendations based on the parameters entered by the customer. In addition, the importance of a partner ranking means that their customers also benefit from a need for the merchant provide desirable goods/services in order to maintain or improve their ranking, the ranking being adversely affected by negative feedback for the merchant. It should be appreciated that this ties into how partners evolve into central nodes in the eco-system, as their recognition or visibility increases. As mentioned previously, central nodes are nodes in a network with a high number of links and are typically more valuable. Typically, such nodes are prioritised, and given a higher ranking. It should also be noted that the method 1200 allows marginal nodes to become central nodes, and this can be perceived to the growth of a business.
Throughout this specification and claims which follow, unless the context requires otherwise, the word “comprise”, and variations such as “comprises” or “comprising”, will be understood to imply the inclusion of a stated integer or group of integers or steps but not the exclusion of any other integer or group of integers.
Persons skilled in the art will appreciate that numerous variations and modifications will become apparent. All such variations and modifications which become apparent to persons skilled in the art, should be considered to fall within the spirit and scope that the invention broadly appearing before described.