HK1181520A - Recognizing missing offerings in a marketplace - Google Patents

Description

Identifying missing offerings in a marketplace

Technical Field

The invention relates to identifying missing offerings in a marketplace.

Background

Software applications consume various types of input data. With the advent of internet-based, always-on computing, the amount of data available to applications and the types of applications used to process that data has grown tremendously. Cloud computing is an emerging trend for distributed data computing and for accessing data. The data may include information such as zip codes for address verification, translation information for language, corporate revenue or other statistics for a company, employment information for personnel, social network relationships for people, and any other type of information. The build application is typically custom built either in such a way that this data is built in or some hard-coded well-known access location is used to retrieve this data at runtime. When an application needs a new data type, the available sources for that data are typically searched by the software developer and the data is purchased on a one-time or subscription basis.

Such as Microsoft Windows^TMAZURE^TMThe DataMarket, such as the DataMarket, is emerging as a common source for finding and purchasing various types of data used by end users or software programs. As more and more users begin to learn and use datamarkets and their competing products from cloud computing providers, datamarkets and competing products are inserting data that can be used to drive strategic management of content and to identify applications that need to be built to utilize this content. For example, someone viewing weather information in a data marketplace may notice that there are not many good applications for displaying weather data. In contrast, an application developer who wants to write a weather application may find that the data that the developer needs is not available in the marketplace.

When people search on these emerging data markets, the content they are looking for is often not found because the data is not present or is not yet publicly available. This would result in people looking for alternative private sources of this data or people creating their own proprietary data stores for collecting and using this data. Some people may do so simultaneously so that there is a lot of redundant work in collecting and storing data. While some people may choose to share this data in the data marketplace and may profit from the work they spend in collecting the data, others will keep the data private. Although data marketplace providers know what data people buy and use, the marketplace is generally unaware of what data people want but do not find, or the data in the marketplace would be more useful if additional data were placed or supplemented in a different format.

Disclosure of Invention

A data fulfillment system is described herein for identifying data needs of data market consumers and actively finding and attempting to fulfill those needs by adding new data and data providers to the market. In some embodiments, the system captures a consumer's search for data. After the user enters a search, the system captures the search terms. If no matching data is found, the data fulfillment system presents the consumer with a screen suggesting a new data offer and providing a description of the data sought by the consumer. The description may also include web services or applications that the consumer is looking for to consume specific data. The system then mines these consumer ideas to programmatically find their partners by looking at who holds this data or runs in this space. The system can also feed this consumer-thought information to business development teams and content management (advertising), who today know a good chance to provide specific data or applications as needed. Thus, the data fulfillment system provides consumers with implicit and explicit methods for providing information describing the data offerings they want and potential providers with implicit and explicit ways to learn about opportunities to remedy current data gaps.

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

Drawings

Figure 1 is a block diagram that illustrates components of the data perfection system, in one embodiment.

FIG. 2 is a flow diagram that illustrates the processing of a consumer data query by the data perfection system in one embodiment, wherein the result of at least one query is no match data.

FIG. 3 is a flow diagram that illustrates a process by which the data perfection system provides information regarding data perfection opportunities to data providers that use the data marketplace, in one embodiment.

Detailed Description

A data fulfillment system is described herein for identifying data needs of data market consumers and actively finding and attempting to satisfy those needs by adding new data and data providers to the market. In some embodiments, the system captures a consumer's search for data. After the user enters a search, the system captures the search terms. If no matching data is found, the data fulfillment system presents the consumer with a screen suggesting a new data offer and providing a description of the data sought by the consumer, rather than a "not found" response as in the prior systems. The data may also include web services or applications that the consumer is looking for to consume specific data. The system then mines these consumer ideas to programmatically find their partners by looking at who holds this data or runs in this space. The system can also feed this consumer-thought information to business expansion teams and content management (and potentially Independent Software Vendors (ISVs)), who now know a good opportunity to provide specific data or applications as needed. This flow and experience allows marketers of the marketplace provider to optimize (both public and private to the driver ecosystem) to connect buyers and sellers of data and data-consuming applications.

The data perfection system provides a user experience (UX) for allowing a user to suggest data offerings when nothing is found. The user can provide detailed information about the data searched by the user. The system automatically classifies searches as types of applications or data sets based on semantics and well-known classification techniques (e.g., searching for "fuel prices" would result in adding navigation, transmission, and categories of oil and gas) using relevant service queries as well as name matching, pattern matching, and allowing users to suggest other data categories. In some embodiments, the system automatically shows the user possible data sets that do not yet exist in the marketplace and asks the user which, if available, the user will purchase. At the back end, the system uses the user-thought data to create a consumption survey (lead generation) for market teams and partners (partners are soon able to run their own private markets, using this consumption survey as an important discriminator of what they collect and show to customers). The system may also provide a survey score relative to the current opportunity for persistent storage of searches performed by the user. For example, if a business development and content team has providers of navigation, crime, and weather data from a Customer Relationship Management (CRM) scheme, adding simple scores or indicators (red, green, yellow) to this data can be used to help them prefer one partner over the other — based on the availability of content in the marketplace, the price currently offered, and so on. Thus, the data fulfillment system provides consumers with implicit and explicit methods for providing information describing the data offerings they want and potential providers with implicit and explicit methods for learning opportunities to remedy current data gaps.

The following paragraphs provide an overview of the data perfecting system in one embodiment. The system maintains a supply database of supplies in the marketplace and a demand database for capturing items that are searched but not found (note that while these are separate databases in the overview, they may be hosted by the same database instance). As data is searched and found, the popularity index of the content rises in the provisioning database. In addition, the user can either privately or publicly review the offer (data or application) to provide negative feedback if, for example, the price is too high, the application is unstable, terms are not accepted, or how to provide feedback or suggestions, such as "wish to be able to also enable mobile scenarios". The system automatically gathers perspectives from notes and feedback and provides a qualitative overview of how the data set behaves and sales and other quantitative measures in the marketplace. The system may provide a purchase history for the offering (data, web services, applications, etc.) so that the consumer can see which data sets are interesting. The user may also provide private or public feedback about the categories, such as whether the category lacks data, whether the category is missing, whether the category contains useful data or is useful for their work, and so forth.

When data is used, the data fulfillment system records and aggregates data query patterns in the provisioning database. The system then analyzes these usage patterns to determine which portions of the existing data are most frequently used. The system also analyzes the usage patterns to determine which data to use with which other types of data, and thus which new offerings, if created, would be useful.

When data is searched but not found, the system records the queries and terms in the requirements database. The system records contextual information about the search, such as what products, web pages, or other interfaces were used for the query. The contextual information may distinguish between user types (e.g., developers or data analysts) or may suggest other distinctions of different target content. User telemetry through the marketplace can also be recorded to ensure that the data being searched does not actually exist in the marketplace, rather than simply categorizing it in a manner that is not intended by the user. The system may use a dictionary and web services for related searches to classify terms. The system also provides the user with a user interface for capturing more information about the content the user wants, such as the desired data set, the scenario the user wants to enable, and optionally other data sets and data and application categories the user wants to view (e.g., the user can provide the name of the company or specific offers from the company).

The data fulfillment system uses web services and/or backlogs to provide users with a list of offers that are currently working or available through other content providers. The user may select whether one of these offers will provide the information that the user is searching for. This data is periodically compared to the supply database to create a survey for the business development team, assist the currently preferred partners and provide opportunities that the team can pursue and the possibility to complete the transaction based on data from the supply database (e.g., historical data about what types of companies they have closed, in what areas, at what price points) and the data from the demand database.

In some embodiments, partners receive data from supply and demand databases in an attempt to ensure that the marketplace has a balanced content economy. This enables partners to improve their offerings or consider showing new offerings in the marketplace.

Figure 1 is a block diagram that illustrates components of the data perfection system, in one embodiment. The system 100 includes a supply data store 100, a demand data store 120, a data request component 130, a data identification component 140, an unavailability detection component 150, a demand capture component 160, a provider reporting component 170, and a consumer perfection component 180. Each of these components is discussed in more detail herein.

The offer data store 110 stores information describing one or more data offers available to data consumers and provided by data providers in the data marketplace. Provisioning data store 110 may include one or more files, file systems, hard drives, databases, storage area networks, cloud-based storage services, or other facilities for persisting and providing access to data. In some embodiments, a system100 is provided and built on a similar Microsoft Windows operating system^TMAZURE^TMThe web services platform of (1) a cloud-based data marketplace built on the web services platform of (2). The provisioning data store 110 may include information related to each data provisioning, such as a description of available data, sample data, fee/subscription information to acquire the data, format of the data, and so forth. The provider provides new data offerings to the provisioning data store 110 to make them available to the consumer, and the consumer browses and searches the provisioning data store 110 to find data for data and applications that accomplish a particular task.

The demand data store 120 stores information describing one or more failed attempts to access data from the supply data store 110, where a failure indicates that the data is not available or is not available in the form requested by the consumer. In some embodiments, the system cooperates with an affiliate to track and store demand data in an intermediary model. The demand data store 120 tracks what the user desires to be available in the form of applications and data from the supply data store 110 and provides a quantifiable record of demand for new data that can be reported to the provider to allow the provider to fill gaps in the type of data available and promote a healthier market.

The data request component 130 receives a query from a data consumer to identify one or more matching data offerings in the offer data store. The query may include a text query string specifying one or more keywords against which to match the available data offerings. The component 130 may provide a user interface in the form of a web page, a mobile application, a desktop application, or a programming Application Programming Interface (API) through which a consumer may submit requests. The data request component 130 can capture additional information in the query, such as the category in which the search is conducted, the particular provider of the consumer's preferences, and so forth. In some examples, the system may store user profile information about consumers and providers that provide additional information, which the data request component 130 may use to process the query.

The data identification component 140 identifies data offerings that match the received query and reports any matching data offerings to the consumer. For example, the system 100 can store an index of available data offerings and applications for consuming data sets, and can use the index to look up keywords in queries to identify matching data offerings. Component 140 can match data offerings based on data offering descriptions, provider information, or any other information associated with a particular data offering. The consumer may indicate whether any particular offer satisfies the consumer's request by purchasing the offer or by making another indication (e.g., a checkbox next to the offer) that shows the consumer's interest in the offer.

The unavailability detection component 150 detects a query that does not return any available data offerings or that the consumer indicates that none of the returned data offerings satisfies one or more criteria of the consumer. The component 150 can detect searches with zero results or can investigate the consumer after each search to ask if the consumer found the data that the consumer searched at the time. The component 150 can also use other techniques for identifying user disappointment or dissatisfaction, such as repeated queries with slight modifications, paging back and forth between result pages, and so forth. Upon detecting these conditions, the component 150 may display a dialog box or other user interface to the consumer to ask the consumer if it is difficult to find a matching data offer.

The requirements capture component 160 records information describing failed queries detected in the requirements data store. Over time, as many consumers query the supply data store and a percentage fail to identify a matching data supply, the demand data store 120 accumulates a certain amount of useful information about consumer demand. This information can be aggregated and sorted to bring the most demanding data supply ahead. In some cases, the system 100 applies human expertise or automated analysis to identify data queries that identify the same unavailable data, even though the consumer may use different query terms or provide different descriptions of the data that the consumer searched. The demand capture component 160 aggregates this information and tracks the information for reporting to providers in the demand data store 120.

Provider reporting component 170 provides a user interface through which potential data providers can access demand data stores to identify one or more data provisioning opportunities based on previous customer data requests. The provider reporting component 170 may provide a web page, mobile application, desktop application, or programming interface through which an analysis application used by the provider or providers may access the requirements database to identify data providing opportunities. The interface may provide classification and filtering options so that, for example, a provider may look for data offerings in a particular category with which the provider is familiar and for which there is sufficient demand to justify efforts to generate new data offerings. In response, the data provider may go out and create or obtain the requested data from other sources and supply the data in the marketplace. This makes the market more complete and provides ready incentive to fill any gaps in the available data and provide the data in the format that the consumer requests the most.

The consumer perfection component 180 optionally notifies a consumer of a matching data offering when a new data offering is available in response to a previous query by the consumer that failed to previously find the data offering. Based on user profile information or information captured at the time of a failed request, the system 100 may have stored contact information for the consumer, such as an email address, by which the system 100 may notify the consumer. The system 100 may also provide notifications via push notifications provided through the device platform, text messages, or other notification methods used in the art. This helps encourage consumers to return to the data market and recognizes that system operators are working to ensure that consumers find the data they are looking for.

The computing device on which the data fulfillment system is implemented may include a central processing unit, memory, input devices (e.g., keyboard and pointing devices), output devices (e.g., display devices), and storage devices (e.g., disk drives or other non-volatile storage media). The memory and storage devices are computer-readable storage media that may be encoded with computer-executable instructions (e.g., software) that implement or enable the system. Further, the data structures and message structures may be stored on a computer-readable storage medium. Any computer readable media claimed herein includes only those media that fall within the statutory patentable category. The system may also include one or more communication links over which data may be communicated. Various communication links may be used, such as the Internet, a local area network, a wide area network, a point-to-point dial-up connection, a cellular telephone network, and so forth.

Embodiments of the system may be implemented in various operating environments that include personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, programmable consumer electronics, digital cameras, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, set top boxes, systems on a chip (SOCs), and so on. The computer system may be a cellular telephone, personal digital assistant, smart phone, personal computer, programmable consumer electronics, digital camera, or the like.

The system may be described in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Typically, the functionality of the program modules may be combined or distributed as desired in various embodiments.

FIG. 2 is a flow diagram that illustrates the processing of a consumer data query by the data perfection system in one embodiment, where at least one query results in no matching data. Beginning in block 210, the system receives a consumer data query requesting one or more matching data sets from a data marketplace containing a data supply from a data provider. Data supplies may include a wide variety of data types and content, including text, tabular, audiovisual, or other types of data relating to a wide variety of topics, from natural gas prices to stock information to enterprise employees to government information. The query may include one or more keywords or other types of query information, and may also include filtering information including one or more data categories in which the consumer desires to find a matching data set.

Continuing in block 220, the system performs a search to identify one or more matching datasets. The search may consult an index or other data structure to efficiently match the consumer's data query with potentially many data offerings stored in the data store. The system identifies matching datasets based on dataset descriptions, information submitted by the provider of the datasets, embedded content in the datasets, or by other matching tools. For most queries, the system may identify one or more matching datasets, while for a small percentage of queries or query categories, the system may not find any matching available datasets.

Continuing in decision block 230, if the system determines that no matching data sets are found that satisfy the received data query, the system continues at block 240, else the system provides the set of search results to the consumer, selects an available data set from, and then ends the search. Even when available data sets are found, the data sets may fail to satisfy the consumer for one reason or another. In this case, the system may detect this condition (e.g., by querying the consumer) and proceed with the following steps to report the unavailability of the matching data.

Continuing in block 240, the system detects the unavailability of a data set that matches the received data query. As mentioned above, this may occur because the search did not return any data sets or because the consumer indicated dissatisfaction with the available data sets returned. The system captures this information and tracks the unavailability of the data in the demand data store, as described in detail herein.

Continuing in block 250, the system receives user command information describing data sets that the consumer cannot find in the data marketplace. When the unavailability of particular data is detected, the system may display a form or other user interface for the consumer to fill in. The form includes fields that request specific information from the consumer that details what the consumer wants. This information may include textual descriptions, categories, sample data such as what the consumer wants, known alternative sources of data, and so forth.

Continuing in block 260, the system stores the demand record in a demand data store that persists the received user demand information for later analysis. The requirements record may include information related to the user, such as an identifier of a contact information or user profile record, consumer provided requirements information, category information of the requirements record, historical/statistical information quantifying related requests, and so forth. In some cases, the system may display other received demand information to the consumer and ask the user whether the other demand information matches the data the user is searching for. After block 260, these steps conclude.

FIG. 3 is a flow diagram that illustrates a process by which the data perfection system provides information regarding data perfection opportunities to data providers that use the data marketplace, in one embodiment. Upon opening in block 310, the system receives consumer demand data from one or more consumers who have failed to search for data from the data marketplace. The received demand data may include a description of the information desired by the consumer, the category associated with the information, the number of consumers looking for the information, the frequency with which the data is requested, and so forth.

Continuing in block 320, the system receives a provider report request that describes information for one or more opportunities to provision data in response to an unsuccessful customer data request. The provider request may identify one or more categories that are used to filter the demand data as well as other provider criteria, such as an opportunity size based on a threshold number of consumers of the request, and so forth. The system may receive the request through a user interface provided by the system, which the provider may access or log in to search for available opportunities. In some embodiments, the system may sell access to opportunity information and check provider subscriptions or other payment verifications before providing access to demand data.

Continuing in block 330, the system accesses demand data received from a demand data store that stores the received consumer demand data. The provider reporting and demand storage functions of the system may be performed together or may be separate. For example, demand requests may be directed to a particular management access server, while demand data may be stored in a cloud-based database that receives incoming customer requests. Thus, the system may access local or remote demand data in response to received provider requests.

Continuing in block 340, the system identifies one or more opportunities indicated by the demand data that are responsive to the received provider report request. The system may apply a threshold to eliminate insufficient consumer requests to report and may filter according to categories or other received provider criteria to forward the most relevant opportunities to the provider.

Continuing in block 350, the system reports the identified matching opportunities to the provider. The system may display a user interface (e.g., via a web page), send the report to the provider (e.g., via email), or provide the report in some other manner. The report may include text, graphics, or other information to convey each possible opportunity to the provider, as well as related information associated with the opportunity, such as the size of the consumer's needs, individual consumer reviews describing the requested data, and so forth.

Continuing in block 360, the system optionally receives a new data feed from the provider in response. Based on the truly identified consumer needs, the provider can devote its time to providing those types of data that are requested the most and therefore most profitable to the provider. Accordingly, the provider may engage in responding to the identified consumer demand and provide the target data supply in response to the demand data.

Continuing in block 370, the system enumerates the new data offerings received in the marketplace, so that subsequent consumer requests for the same data will find new available offerings. In this way, the system compensates for previously failed consumer requests by encouraging provider interaction with the system. The system may also proactively notify consumers who have previously searched for data offerings similar to the new offering submitted by the provider. After block 370, these steps conclude.

As described herein, the data fulfillment system provides a positive feedback loop in which the consumer needs to drive the provider supply. Providers receive targeted information about what consumers want, while consumers can directly provide information about what they need if they do not find existing satisfactory data. In addition, the system can also track the successful use of data so that the provider receives feedback as to what data has been available that the consumer finds particularly useful. During the sales/thinking phase, the provider may query the system for interests, and during the feature modification phase, the provider may query for desired features. A provider that is not yet associated with the system may decide to join the marketplace to provide the unavailable data, or may decide to collaborate with another provider to supplement the available data with new information.

In some embodiments, the data perfection system detects data that is typically used with other data. For example, the system may note that demographic data sets are often purchased along with criminal data sets. The system may also note that consumers of these data sets often add similar additional fields. For example, the system may observe that zip code information is often added to the crime data. This information allows the system to provide additional information to the provider in the provider report described herein. For example, the system may suggest that two providers work together to provide a unified data set or add missing data that costs the consumer repetitive labor. The system may also observe which data sets are purchased with which data consuming applications to make relevant reports for the provider. The system anonymizes consumer information so that personal consumer data is not presented to the provider unless the consumer specifically chooses to do so.

In some embodiments, the data fulfillment system may proactively or reactively provide reports to the provider. Reactive reporting is described herein in which a provider accesses a system through a specific request to receive a report. The system may also proactively provide suggestions to the provider, such as sending reports via email, notifying the provider of aggregate consumer needs related to the area of interest to them, and so forth. In some cases, the system may report the amount of data used in the data set to the provider. For example, the system may determine that a consumer typically purchases a large data set but only uses a few rows thereafter. In these cases, the provider may be better served by serving a reduced data set or by splitting the data set into separate offerings that would each be more attractive to a larger consumer population (licensed to consumers that find large data sets too expensive).

In some embodiments, the data fulfillment system provider provides the consumer with a vote for a suggested or available data offering. For example, the system may present two possible data supplies to the consumer in the form of A/B style tests. The system receives votes from the consumer indicating which data set the consumer is more likely to purchase. The system may investigate the consumer conducting the search or via contact information provided to the marketplace. In some cases, the system may collect demographic information to determine which data offerings are preferred by a consumer population.

In some embodiments, the data fulfillment system provides one or more feeds to which providers and consumers can subscribe to learn about demand and new data offerings. For example, the system may provide one or more Really Simple Syndication (RSS) feeds that indicate when new information is available. The system can provide feeds according to categories or other filtering so that providers and consumers can monitor the feeds that best suit them.

In some embodiments, a data fulfillment system provides a private marketplace for an enterprise. Although the system described herein is generally applied to the public data market, the system may also examine consumer requests and provider demand reports for private data within the enterprise. In this way, information technology personnel within an organization can learn what data users in their organization want to be able to use and can find out possible private sources of that data that are not available in the public marketplace and cannot be made available (e.g., for privacy or other reasons).

From the foregoing, it will be appreciated that, although specific embodiments of the data fulfillment system have been described herein for purposes of illustration, various modifications may be made without deviating from the spirit and scope of the invention. Accordingly, the invention is not limited except as by the appended claims.

Claims (15)

1. A computer-implemented method for processing consumer data queries, wherein at least one query does not result in matching data, the method comprising:

receiving (210) a consumer data query requesting one or more matched data sets from a marketplace containing a supply from a provider;

performing (220) a search to identify one or more matching datasets;

detecting (240) an unavailability of a data set matching the received data query;

receiving (250) user demand information, the user demand information describing data sets that the consumer cannot find in a data marketplace; and

storing (260) a demand record in a demand data store that persists received user demand information for later analysis,

wherein the foregoing steps are performed by at least one processor.

2. The method of claim 1, wherein receiving a consumer data query comprises receiving one or more keywords that describe data, applications, application programming interfaces, or visualizations that the consumer is looking for.

3. The method of claim 1, wherein receiving a consumer data query comprises filtering information comprising one or more categories of data in which the consumer looks for a matching data set.

4. The method of claim 1, wherein performing a search comprises consulting an index to efficiently match a consumer's data query with a possible number of offers in a data store.

5. The method of claim 1, wherein performing a search comprises identifying matching datasets based on dataset descriptions submitted by providers of the datasets.

6. The method of claim 1, wherein detecting unavailability comprises determining that the search does not return any data sets.

7. The method of claim 1, wherein detecting unavailability comprises determining that one or more data sets returned by the search are not satisfactory to the consumer.

8. The method of claim 1, wherein receiving demand information comprises displaying a user interface for the consumer to fill in when unavailability of particular data is detected.

9. The method of claim 1, wherein receiving demand information comprises receiving a textual description from the consumer that describes a type of data that the consumer has attempted to find.

10. The method of claim 1, wherein storing a demand record comprises storing information identifying the consumer.

11. The method of claim 1, wherein storing the demand record comprises storing statistical information quantifying the associated requests.

12. The method of claim 1, further comprising displaying other received demand information to the consumer and asking the user if the other demand information matches the data the user is searching for.

13. A computer system for satisfying data marketplace service requests, the system comprising:

a processor and memory configured to execute software instructions contained within the following components;

a provisioning data store (110) storing information describing one or more data provisions available to data consumers and provisioned by data providers in the data marketplace;

a demand data store (120) storing information describing one or more failed attempts to access data from the supply data store, wherein a failure indicates that the data is unavailable or not available in a form requested by a consumer;

a data request component (130) that receives a query from a data consumer to identify one or more matching data offerings in an offerings data store;

a data identification component (140) that identifies data offerings that match the received query and reports any matching data offerings to the consumer;

an unavailability detection component (150) that detects a query that does not return any available data offerings or that the consumer indicates that none of the returned data offerings satisfies one or more criteria of the consumer;

a requirements capture component (160) that records information describing failed queries detected in the requirements data store; and

a provider reporting component (170) that provides a user interface through which potential data providers can access the demand data store to identify one or more data provisioning opportunities based on previous consumer data requests.

14. The system of claim 13, wherein the demand data store provides quantifiable records of demand for new data that can be reported to providers to enable the providers to fill gaps in available data types.

15. The system of claim 13, the unavailability detection component investigates searching consumers after each search to ask the consumers whether the consumers found data that the consumers searched.