MANAGEMENT AND SCORING OF DATA FOR INFORMATION SOURCES

BACKGROUND

Organizations and services often aggregate data from a multitude of sources to provide accurate information to a user of the organization or service. This data may include numerical values, text based information, or some other data that can be provided to the user. However, although organizations and services may require that information is obtained from various sources, managing and making use of the data as it is received can be difficult and cumbersome. In particular, issues often arise when the data is obtained in various different formats, which causes difficulties in combining the data with information from other sources. Additionally, difficulties can arise in presenting the information to a user of the organization or service to permit the user to efficiently and effectively identify relevant information from the presentation.

OVERVIEW

Provided herein are enhancements for managing data from different information sources and generating scores for each of the information sources. In one implementation, a method of operating a summary service to manage data from multiple information sources includes obtaining, from a plurality of data sources, data objects in a plurality of formats corresponding to an event, wherein the data objects each comprise data items for the event. The method also includes maintaining a common data structure for the event, wherein the data structure relates data items of similar data type from the plurality of data sources. The method further provides identifying a user request for a summary of the event, and in response to the user request, generating an event summary based on the common data structure, wherein the event summary compares data items of similar type from the plurality of data sources. The method also includes providing the event summary to the requesting user.

BRIEF DESCRIPTION OF THE DRAWINGS

Many aspects of the disclosure can be better understood with reference to the following drawings. While several implementations are described in connection with these drawings, the disclosure is not limited to the implementations disclosed herein. On the contrary, the intent is to cover all alternatives, modifications, and equivalents.

FIG. 1 illustrates a computing environment for managing and comparing data from multiple information sources according to an implementation.

FIG. 2 illustrates an operation of a summary service according to an implementation.

FIG. 3 illustrates an operational scenario of a summary service according to an implementation.

FIG. 4 illustrates a data structure for managing and comparing data from multiple information sources according to an implementation.

FIG. 5 illustrates an operational scenario for prioritizing data for a user of a summary service according to an implementation.

FIG. 6 illustrates a user interface for managing the comparison of data according to an implementation.

FIG. 7 illustrates an operational scenario of scoring and prioritizing services for a user of a summary service according to an implementation.

FIG. 8 illustrates a user interface for providing a comparison of data according to an implementation.

FIG. 9 illustrates an operational scenario of generating scores for services according to an implementation.

FIG. 10 illustrates a computing system to manage and compare data from multiple information sources according to an implementation.

DETAILED DESCRIPTION

FIG. 1 illustrates a computing environment 100 for managing and comparing data from multiple information sources according to an implementation. Computing environment 100 includes information sources 122, supplemental sources 124, summary service 110, and user 160. Summary service 110 is configured to provide operation 200 that is further described in FIG. 2.

As depicted, summary service 110 communicates with information sources 122 and supplemental sources 124 to obtain data objects from the sources. These data objects may include forms, official documents, or some other similar data object. As the objects are obtained, either by information sources 122 automatically providing the information or via request from summary service 110, summary service 110 generates and maintains a data structure to cohesively manage the information from the various sources. In some implementations, the data objects that are received from information sources 122 and supplemental sources 124 may be provided using different format types. For example, a first information source may use a format type associated with a first geographic location (e.g. a first form), while a second information source may use a format type associated with a second geographic location (e.g. a second form). As a result, as the data objects are obtained, data items within the object (e.g. monetary values, ratings, scores, and the like) are extracted and placed within a common data structure capable of comparing information from multiple different formats. Thus, although a rating from a first information source may be in a first location for a data object, and a similar rating from a second information source may be in a second location, the common data structure may store the data in such a manner that the similar values can be compared.

As the data objects are obtained and the data items therein are placed within the common data structure, user 160 may generate requests to compare information between the different information sources. As an example, user 160 may provide a request for a particular event. In response to the request, summary service 110 will identify data items that are relevant to the request and provide information to the user based on the identified data items, wherein the information permits the user to efficiently compare data items of similar data types across multiple information sources.

To further demonstrate operations of computing environment 100, FIG. 2 is provided. FIG. 2 illustrates an operation 200 of a summary service according to an implementation. The processes of operation 200 are described parenthetically in the paragraphs that follow with reference to systems and elements of computing environment 100 of FIG. 1.

In the example of operation 200, summary service 110 obtains (201) data objects in a plurality of formats corresponding to a plurality of events, wherein the data objects each comprise data items for the events. In some implementations, the data objects may comprise forms, documents, or other similar objects that contain various statistical data items for a particular event. These data objects may comprise varying formats based on the information source for the particular data object. In at least one implementation, based on the location of the information source (e.g. country, trade organization, and the like), the information source may use a particular format associated with the location. As a result, although two information sources may provide a data object with similar information, the format of the data objects may differ, creating difficulties in comparing similar data between the information sources.

Once the data objects are obtained from the information sources, operation 200 further maintains (202) a common data structure for the events. This common data structure is used to relate data items of similar type to other data items from other information sources. For example, summary service 110 may receive three data objects from three different information sources, wherein the data objects may be provided in three different formats. Once the objects are received, each data item within the data objects may be extracted and associated with similar data items from the other data objects. Consequently, if a data item represented an amount of time for a particular operation related to an event, such as completing a project for the event, the data item may then be stored in the common data structure such that it may be related or compared to other times for the same operation related to the event.

While maintaining the common data structure for the events, operation 200 further includes identifying (203) a user request for a summary of an event in the plurality of events. In identifying this request, summary service 110 may operate as a remote service, wherein users via remote consoles, such as desktop computing systems, laptop computing systems, tablets, smartphones, or some other similar console computing systems, may request comparison information for a particular event. As an example, summary service 110 may be configured to take bids to provide services for a particular event and the information sources may comprise contractors capable of fulfilling the requirements for the event. As information is gathered from the contractors that may use various different formats, the information may be stored in a data structure permitting data items of a similar data type to be compared for the event. While the data is maintained within the structure, a user may request a summary comparison between each of the contractors providing a bid for the particular event.

Once a request is identified, operation 200 generates (204) an event summary based on the common data structure, and provides (205) the event summary to the requesting user. Returning to the example of requesting a bid for a particular event, summary service may identify relevant data items from contractors related to the event, and generate a summary using the data items. In some implementations, the comparison may be used to compare each of the contractors that are providing bids for the particular event, wherein the requesting user may be provided with information about various data types and corresponding values for each of the contractors. Accordingly, although each of the contractors may provide information using different formats, the data may be presented in such a manner that similar data types may be compared.

In at least one implementation, in providing the summary to the requesting user, summary service 110 may be used to promote particular data types for the comparison. These data types may be promoted based on data items for the types meeting defined criteria. For example, if the value were numerical and data items from different sources had a large discrepancy in their numerical value, then summary service 110 may flag the data type as a type that should be promoted. Other examples, of promoting a particular type may include identifying when an information source has not provided a data item for a particular type, when values from one or more of the sources are higher/lower than a predicted value, or some other similar criteria for promoting a particular data type. In promoting the data type within the presentation to the requesting user, summary service 110 may highlight one or more data items that correspond to the data type, may move the promoted data items into a better viewing position for the user (such as the top of the display), may bold or provide a different font for the promoted data items, or may provide the information in any other similar manner. By promoting particular data items for the requesting user, the user may more easily analyze and process the varying data types to determine differences between the information sources. Referring again to the example of the contractors (information sources) providing bids for a particular event, the user may analyze differences between the various contractors to identify a contractor capable of providing the required services.

As illustrated in computing environment 100, summary service 110 may also use supplemental sources 124 in providing summary information about an event. In particular, supplemental sources 124 may not comprise direct forms or input related to an event, but may comprise alternative sources related to an event. In some implementations, these alternative sources may comprise emails, chats, or some other similar data source related to the information sources. For example, when an information source of information sources 122 lacks a data item or value for a particular data type, summary service 110 may inspect supplemental sources 124 to determine if a value can be extracted. If an appropriate data item can be identified, in some examples by applying natural language operations on the information from supplemental sources, then data time may be added to the common data structure to provide additional information for an event. Additionally, supplemental sources 124 may provide information about other similar events, wherein the data for the other similar events may be compared against a current event. Referring again to the example of promoting particular data types, if the values from supplemental sources 124 differed greatly from the values for a particular event from information sources 122, then the data type may be promoted for that event.

In some implementations, in generating the event summary for the event, in addition to or in place of identifying data items of interest, summary service 110 may generate a score for each of the information sources based on their data items. In particular, when a user generates a request for an event, the user may provide preferences, such as the location of the event, the cost of personnel for the event, or some other similar preferences related to the event. These preferences may then be compared to the data items provided from the information sources (and stored in the common data structure) to determine a score for each of the information sources. Accordingly, if a first information source provided a location in proximity to a preferred location specified by the user, then the first information source may be provided with a higher score for that preference than a second information that had a location that was not in proximity to the preferred location. Additionally, in some implementations, in addition to the data items provided from the information sources, supplemental sources 124 may also be used in generating the scores. This supplemental information may include reviews for each of the sources, discrepancies between proposed costs and actual costs, discrepancies between proposed lengths of operations, or some other similar information.

FIG. 3 illustrates an operational scenario of a summary service according to an implementation. The operational scenario in FIG. 3 includes information sources 301-303 and summary service 310, wherein summary service 310 further includes extract operation 320, data type operation 322, and maintain operation 324.

As described herein summary service 310 may obtain data objects from a plurality of information sources 301-303, wherein the information sources may comprise contractors providing bids for one or more events, companies providing cost and capability information, or some other similar information sources, wherein the data from the sources may be compared via summary service 310. In the present implementation, in providing the data objects to summary service 310 the information sources may use multiple formats for the data objects, which causes difficulties in comparing data items/values from each of the information sources.

As a result of the differing formats, extract operation of summary service 310 is used to identify the various data items within each of the data objects. In some implementations, in extracting the data, extract operation 320 may identify a format associated with a received data object, and based on the format, may identify the data items from the data object. For example, if a data object from information source 301 were in a first format with three numerical values, and a data object from information source 302 were in a second format with three numerical values, extract operation 320 may be used to extract the data values from both of the formats although the data may not be in the same order.

As the data is extracted using extract operation 320, data type operation 322 is used to identify the particular data type associated with each of the data items. These data items may include information about a particular event, such as total cost, total time, number of employees, or any other similar data type that might be consistent across each of the information sources. In some examples, to determine the data type, data type operation 322 may identify the format of the data object that was received and determine the different data types that are included in that format. Thus, if a format provided a number of employees first and then provided a total cost of providing services for an event, data type operation 322 may associate a first value extracted with an employee number data type, while type operation 322 may associated a second value extracted with a total cost data type.

Once a data type is identified for each of the data items, maintain module 324 is then used to maintain a data structure capable of comparing the data from each of the information sources. In this manner, for each event, data items of the same data type may be quickly identified for the information sources, such that they can be compared by a user interested in the event. For example, when a user requests a summary of a particular event, summary service 310 may identify relevant data items associated with the particular event, and present a comparison of data items from different information sources to the requesting user. Referring again to the example of information sources providing a quantity of employees to support a particular event, summary service 310 may provide a display to the requesting user permitting the user to compare quantities from each of the information sources. In this manner, rather than requiring each of the information sources to provide data using the same format, summary service 310 may extract the relevant data and manage the data to be provided to requesting users.

As described herein, it should be understood that information sources 301-303 may provide multiple data objects per event. In providing the data objects, summary service 310 may be used to aggregate data items from each of the objects into singular data structure to be compared against the data obtained from other information sources. Further, in some examples, it should be understood that conflicts may be presented when multiple data objects are received for an event from a singular information source. For instance, if an information source provided multiple data objects that each included information about the number of employees required to support an event, then summary service 310 may be responsible for managing the conflicts presented within the data objects. In managing the conflicts, the most recently identified data item may be promoted over other data items of the same data type, the most frequently encountered data item may be promoted over other data items of the same data type, or some other similar management process for conflicts.

FIG. 4 illustrates a data structure 400 for managing and comparing data from multiple information sources according to an implementation. Data structure 400 includes events 402-403, data types 420-424, and sources 410-413. Although demonstrated with three sources per event, it should be understood that additional or fewer sources may provide data for data structure 400.

As described herein, a summary service may communicate with one or more information to sources to obtain data objects related to events. These information sources may comprise contractors, companies, or some other similar information source in some examples. Additionally, the data objects may provide information related to costs, number of employees, locations, or some other similar information related to a particular event. As the data objects are received, the summary service may extract data from the objects and use the data to populate data structure 400. In particular, because the data objects may be received in different formats, the summary service may be required to extract data, identify a data type associated with each of the data items, and store the data in data structure 400, such that it can be compared to data from other information sources. Referring to an example for event 402, data for data type 422 may be stored in such a manner, such that it can be compared across sources 410-412. As a result, when a request is generated by a user of the service, data may be retrieved from data structure 400 and presented to the user, permitting the user to compare the information from the various sources.

FIG. 5 illustrates an operational scenario 500 for prioritizing data for a user of a summary service according to an implementation. Operational scenario 500 includes operations 510-512 and user 502.

In operation, users of a summary service provide requests to receive information about particular events. Specifically, the users may generate requests for data from multiple information sources, wherein the data from each of the sources may be compared with data from the other sources. In the present implementation, user 502 generates event request 505 that is identified by the summary service. In response to the request, operation 510 is initiated that identifies data related to the event. Referring back to the data structure in FIG. 4, as data objects are received, data items within the objects are extracted and organized within a data structure, such that similar data items from multiple information sources may be compared to one another. In particular, when a user generates the request, the user may specify a particular event of a plurality of events for which a summary should be generated. As a result, data derived from information sources and data objects related to the event would be identified to support the request.

Once data items 515 are identified to support the request, operation 511 identifies data types of interest for the event. In identifying data types of interest, the summary service may use various criteria, such as thresholds, to determine information that should be prioritized for the requesting user. In one implementation, the criteria may comprise differences in data values between the various information sources. For example, if four information sources were providing information about an event, and three had a similar value for a particular data type, while the fourth had a value that met criteria indicating a large deviation from the other values, the data type may be identified as one of interest for the user. In determining whether a value is too different from the others as to be flagged for a data type of interest, the summary service may use percentages, set numerical values, or some other similar differencing criteria to identify when one or more values are not similar to other values. In another implementation, the criteria information for identifying data types of interest may be based on other similar events. In particular, when a user requests a particular event, the summary service may identify similar events and data items that correspond to the event. As an example, if the event comprised a party and the information sources were contractors to support the party, then values from other similar parties may be compared with current values and the associated information sources. Thus, if one or more of the current information sources provided a value that is inconsistent with previous values, that value type may be flagged for the requesting user.

Although these are example criteria for identifying a data type of interest, it should be understood that other criteria may be used in identifying data types of interest. These criteria may be a minimum value (e.g. a minimum monetary value), a maximum value (e.g. a number of employees), or some other similar type of criteria.

After the data types of interest are identified, operation 512 generates a display prioritizing the data types of interest. In prioritizing the data types of interest over the other data types for the event, the types of interest may be highlighted, may be promoted to a particular location on the display, may be bolded or italicized, or any other similar operation of promoting a particular data type. In some implementations, users may interact with the summary service via a remote console device, such as a laptop computer, desktop computer, smartphone, tablet computer, or some other similar computing system. To generate requests, the user may use a web browser or some other application on the computing system to generate requests that are received by the comparison system. Once the requests are received, the comparison system may employ operations 510-512 as described herein to provide a comparison summary to the requesting user.

FIG. 6 illustrates a user interface 600 for managing the comparison of data according to an implementation. User interface 600 is an example summary that can be provided to a user in response to a request for a summary of a particular event. In the present implementation, the user interface includes comparison information for three different information sources. For each of the information sources, illustrated on user interface 600 as “ALPHA,” “BETA,” and “THETA,” data is provided that corresponds to various data types. In particular, as a summary service receives data objects from each of the information sources, the data items from the objects may be placed into at least one data structure capable of directly comparing similar data types. Thus, while each of “ALPHA,” “BETA,” and “THETA” may use different formats for their objects, the data within the objects may be directly compared.

In addition to identifying similar data types from the various formats and information sources, the comparison operation may further identify particular data types of interest when providing the information to a requesting user. To identify the data types of interest, in some implementations, the data items associated with the data types may be compared to defined criteria. The criteria may be used on comparing the data items themselves (such as the numerical values for a data type), may be used in comparing the current data items to data items of other similar event, may be used in comparing the current data items to user defined values for the data items of that data type, or may be used in any other similar manner.

Referring to the example in user interface 600, in providing the comparison information to the requesting user, the data type for “Production Cost” has been flagged as a data type of interest for the user. This data type may have been identified based on the cost for “ALPHA” being lower than the other information sources, may be based on one or more of the production costs being below a predefined threshold or lower than previously presented production costs, or may be identified in any similar manner. As a result of being identified, data items related to the production cost are provided in a different font than data items related to other data types, permitting the user to quickly identify and analyze the information for the data type to make decisions regarding the particular event.

Although demonstrated in the example of FIG. 6 as bolding and increasing the font size for the data type of interest, it should be understood that other operations may be employed to promote a data type of interest. These other operations may include placing the data item of interest in a location that is in a better location of the display to be acknowledged by the user, may be highlighted, provided in a different color font, or promoted for the user in any other similar manner.

FIG. 7 illustrates an operational scenario 700 of scoring and prioritizing services for a user of a summary service according to an implementation. Operational scenario 700 includes operations 710-712, user 702, event request 705, event preferences 725, data items 715, and display 740.

In operation, users of a summary service provide requests to receive information about particular events. Specifically, the users may generate requests for data from multiple information sources, wherein the data from each of the sources may be compared with data from the other sources. In the present implementation, user 702 generates event request 705 that is identified by the summary service. In response to the request, operation 710 is initiated that identifies data related to the event. Referring back to the data structure in FIG. 4, as data objects are received, data items within the objects are extracted and organized within a data structure, such that similar data items from multiple information sources may be compared to one another. In particular, when a user generates the request, the user may specify a particular event of a plurality of events for which a summary should be generated. As a result, data derived from information sources and data objects related to the event would be identified to support the request.

Once the data items are identified for each of the sources, operation 711 is implemented to score each of the sources based on the data items and preferences 725 provided by user 702. As an example, a user may require a particular landscaping operation to be implemented, wherein three sources or service providers provide information (data items) about how the service can be provided (length of the job, cost of personnel, cost of each physical item, and the like). Once the information is provided and stored within the data structure for the summary service, the information may be used in providing suggestions to the requesting user. In the present example, the user may provide targets or preferences 725 for the supporting sources or service providers. These targets may include cost for a particular portion of the event, location of the event, dates of the event, or any other similar targets or preferences. These preferences may then be compared to the data items provided from each of the sources to determine a score for each of the sources. For example, if user 702 requested a particular location for an event, the sources may be provided with a score based on the proximity of their proposed location to the requested location. This score may then be combined with scores for other categories in providing the overall score to the requesting user. This score may comprise a numerical value, a grade letter, or some other similar score, including combinations thereof.

After each of the scores are generated for the various sources related to the event, operation 712 is performed, wherein operation 712 directs the summary service to generate a display prioritizing sources based on their scores. In some implementations, the summary service may provide the various sources as a hierarchy, wherein the source with the best score is promoted over sources with lower scores. This hierarchy may promote sources using bold fonts, different sized fonts, colors, or some other similar operations to promote sources with the higher scores. In some implementations, in providing the sources to the user, at least a portion of the sources may be omitted when the scores fail to meet a minimum score. Once the display is generated, display 740 may be provided to the user permitting the user to make an informed selection of the available sources.

In some implementations, in addition to using the information (data items) provided from the each of the sources to generate the score for the sources, supplemental information may also be used in generating the score. This information may include reviews from various different users of the services, actual cost to predicted cost information for each of the services, emails or other similar messaging transactions about the event, or some other similar information about the services. For example, a service provider may consistently provide estimated costs that are lower than the actual cost of providing the service. Consequently, the rating for the service provider may be lower to reflect the discrepancy between the proposed cost and the actual for the particular service provider.

In some examples, in operating the summary service, the summary service may obtain information from email servers, instant messaging servers, websites, and other similar supplemental sources to determine scores for each of the sources (service providers). First, the supplemental sources may be used to assist in identifying preferences of the requesting user or administrator for the event. For example, an instant messaging server or email server may be inspected to identify preferences of the user that may be included within a message. Consequently, although the user may not have explicitly indicated to the summary service a particular event requirement, the summary service may extract the preference based on the identified communications. Once the preferences of the requesting user have been determined, the supplemental sources may also be used in conjunction with any locally maintained information to generate the scores for each of the service providers. For example, review websites may be used to determine how well a service provider has performed in the past on similar events. Further, email communications, blog posts, instant messages, and other communication information may be used to identify values (such as amount of personnel, cost, and the like) and other similar information about a particular service providers proposal. Once supplemental information is identified, scores may be generated for each of the service providers as described herein, wherein the score may be generated from the express information provided for the event (e.g. the common data structure and express requirements defined for the event), as well as supplemental information that is derived from the supplemental sources.

In some implementations, such as the operations described previously, scores may be generated for multiple sources or service providers, however, it should be understood that scores may be generated for a single source or service provider in some examples. For example, a user may want to determine a score about a particular service provider to determine whether the service provider is adequate for a particular event.

FIG. 8 illustrates a user interface 800 for providing a comparison of data according to an implementation. User interface 800 is an example of display 740 of FIG. 7 that might be provided to a user, however, it should be understood that other examples are possible. User interface 800 includes scores 810, which are representative of the scores that may be allocated to sources or service providers for a particular event. In the example of user interface 800, the event corresponds to production companies for a particular advertising operation. Here, the user provides preferences for the production companies placing bids for the event, and the data items entered from the production companies are compared with the preferences of the user to generate a score. Here, company “ALPHA” has provided a bid that closely aligns with the preferences of the requesting user, and is provided with a check mark to display that they provided the most similar items to that requested by the user. Additionally, scores are provided for the other companies to provide the user with alternative options.

Although not discussed in detail with regards to FIG. 8, it should be understood that the display that is provided to the requesting user may provide additional information. This information may include comparison of individual data items, changes in proposals over time, or some other information regarding each of the service providers.

FIG. 9 illustrates an operational scenario 900 of generating scores for services according to an implementation. Operational scenario 900 includes event 905, operations 910-913, local sources 930, supplemental sources 932, display 940, and user 902.

In operation, users and administrators of a summary service may generate an event, wherein the sources or service providers may provide quotes or information about the event. For example, service providers may provide information about how they would service the event (personnel, cost, location, etc.), and the information may be stored within local sources 930. In some implementations, as the information is gathered from the service providers, the information may be sorted and stored in a common data structure, wherein the common data structure may identify similar information (item quantities, monetary amounts, and the like) across multiple service providers that can be used to compare like fields for each of the service providers.

Here, once the information is sorted for the event, the summary service may identify data related to event 905 using operation 910, wherein the information related to the event may include both local sources (e.g. the common data structure for the service providers derived from formally submitted reports), as well as supplemental sources, which may include websites for the service providers, review websites of the service providers, emails, or some other similar information for the service providers. In some implementations, when identifying data related to the particular event, operation 910 may identify requirements for the administrator of the event, and may also identify information for the service providers that will service the event.

In some implementations, the summary service will identify preferences of the administrator, which may be expressly provided as a local source for the event or may inferred from emails, instant messages, communications or preferences for previous events, or some other similar supplemental information source. Additionally, the summary service may use supplemental sources to identify attributes for each of the service providers or sources, wherein emails, instant messages, blog posts, and the like may provide information (such as cost information) that is not directly indicated in the data items stored in the locally maintained common data structure.

In addition to identifying information that is specific to the event 905, the summary service may identify additional information related to each of the sources using operation 911. In particular, for each of the sources, the summary service may identify information from both local sources 920, and supplemental sources 932. The local sources may include information from the maintained databases and other information that is maintained locally for each of the services. Additionally, the summary service may identify information from supplemental information that is obtained from resources that are not locally maintained by the summary service. This information may include emails, reviews from websites or other databases, feedback from other events, emails from other events, or some other information. As an example, supplemental sources 932 may provide information about how well the service provider held to their proposal, and how well other users have rated the service provider.

After the information related to the particular event is identified along with the additional information related to each of the service providers, operation 912 scores each of the sources (service providers) for event 905 based on the information that was obtained. In some implementations, the score may be based on requested information from the administrator of the event (expressly and implicitly determined) in comparison to bids from each of the service providers, and may further be based on the supplemental information related to the event and the service providers. For example, a service provider may provide information to generate local sources 930, wherein the information indicates cost, personnel, dates, location, or some other information for the event. However, in addition to the express information provided from the service providers for local sources 930, supplemental information may provide information related to the service provider, such as email exchanges about the event, reviews, and the like. Thus, even if a proposal submitted to local sources 930 fulfilled the requirements of the event, the supplemental information may be used to decrease the score of the service provider. Similarly, if the information in local sources 930 were to indicate that the service provider was inadequate, the supplemental information may be used to increase the score of the service provider.

After each of the scores are generated for the various sources or service providers related to the event, operation 913 is performed, wherein operation 913 directs the summary service to generate a display prioritizing sources based on their scores. In some implementations, the summary service may provide the various sources as a hierarchy, wherein the source with the best score is promoted over sources with lower scores. This hierarchy may promote sources using bold fonts, different sized fonts, colors, or some other similar operations to promote sources with the higher scores. In some implementations, in providing the sources to the user, at least a portion of the sources may be omitted when the scores fail to meet a minimum score. Once the display is generated, display 940 may be provided to the user permitting the user to make an informed selection of the available sources.

FIG. 10 illustrates a computing system 1000 to manage and compare data from multiple information sources according to an implementation. Computing system 1000 is representative of any computing system or systems with which the various operational architectures, processes, scenarios, and sequences disclosed herein for an event summary service may be implemented. Computing system 1000 is an example of summary service 110 and 310, although other examples may exist. Computing system 1000 comprises communication interface 1001, user interface 1002, and processing system 1003. Processing system 1003 is linked to communication interface 1001 and user interface 1002. Processing system 1003 includes processing circuitry 1005 and memory device 1006 that stores operating software 1007. Computing system 1000 may include other well-known components such as a battery and enclosure that are not shown for clarity.

Communication interface 1001 comprises components that communicate over communication links, such as network cards, ports, radio frequency (RF), processing circuitry and software, or some other communication devices. Communication interface 1001 may be configured to communicate over metallic, wireless, or optical links. Communication interface 1001 may be configured to use Time Division Multiplex (TDM), Internet Protocol (IP), Ethernet, optical networking, wireless protocols, communication signaling, or some other communication format—including combinations thereof. In some implementations, communication interface 1001 may be configured to communicate with information sources to obtain data objects related to various events. Additionally, in some examples, communication interface 1001 may be configured to communicate with one or more end user console systems to receive summary requests from end users and provide the users with generated summaries.

User interface 1002 comprises components that interact with a user to receive user inputs and to present media and/or information. User interface 1002 may include a speaker, microphone, buttons, lights, display screen, touch screen, touch pad, scroll wheel, communication port, or some other user input/output apparatus—including combinations thereof. User interface 1002 may be omitted in some examples. In some implementations, user interface 1002 may be used in obtaining user summary requests.

Processing circuitry 1005 comprises microprocessor and other circuitry that retrieves and executes operating software 1007 from memory device 1006. Memory device 1006 may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. Memory device 1006 may be implemented as a single storage device, but may also be implemented across multiple storage devices or sub-systems. Memory device 1006 may comprise additional elements, such as a controller to read operating software 1007. Examples of storage media include random access memory, read only memory, magnetic disks, optical disks, and flash memory, as well as any combination or variation thereof, or any other type of storage media. In some implementations, the storage media may be a non-transitory storage media. In some instances, at least a portion of the storage media may be transitory. It should be understood that in no case is the storage media a propagated signal.

Processing circuitry 1005 is typically mounted on a circuit board that may also hold memory device 1006 and portions of communication interface 1001 and user interface 1002. Operating software 1007 comprises computer programs, firmware, or some other form of machine-readable program instructions. Operating software 1007 includes obtain module 1008, maintain module 1009, and request module 1010, although any number of software modules may provide the same operation. Operating software 1007 may further include an operating system, utilities, drivers, network interfaces, applications, or some other type of software. When executed by processing circuitry 1005, operating software 1007 directs processing system 1003 to operate computing system 1000 as described herein.

In one implementation, obtain module 1008 directs processing system 1003 to obtain data objects from a plurality of information sources, wherein the data objects provide data related to a plurality of events. In some implementations, the information sources may comprise contractors, companies, or some other similar entity that is providing information, such as bids, cost estimates, or some other similar information for a particular event. These entities may use varying data object formats, which may comprise different forms, different formal documents, or some other format.

As a result of the differing formats, maintain module 1009 directs processing system 1003 to store data values from the data objects in a manner such that data items/values for the same event may be compared against other data values of the same data type. Thus, if a first value for wardrobe cost were provided from a first information source for an event, that first value may be stored in a manner such that it can be compared to other values of the same type for the event. Once stored, request module 1010 may direct processing system 1003 to receive a request from an end user requesting comparison information for a particular event. In response to the request, request module 1010 may identify data that corresponds to the event using the at least one data structure maintained by maintain module 1009, and will provided the identified data to the requesting user. In some implementations, in providing the data to the requesting user, request module 1010 may generate a display that permits the user to compare data types across multiple information sources.

As an example of providing information to a user that requests information about contractors for a party, each of the contractors (examples of information sources) may provide values corresponding to different data types for the party (e.g. number of personnel, cost of cake, cost of decorations, and the like). After the information is provided from the contractors and sorted into at least one data structure, the user may request a comparison summary for the party, wherein the summary may present values for each data type such that they can be compared across the contractors. Further, in some examples, at least a subset of the data types may be promoted over other data types based on criteria associated with the data type. The criteria may comprise criteria that compares that values for the data type (e.g. one data value may not closely reflect the other data items, or a data value may be missing from a particular source), the criteria may comprise criteria that relates values for the current event to values of other similar events (e.g. a value is much larger or smaller than values for another similar event), or may comprise some other criteria capable of being applied to an individual data type. In presenting the prioritized values, the identified data types may be highlighted, bolded, provided in a different font or size, promoted in the viewing space for the requesting user, or promoted in any other similar manner. Once presented, the user may be more capable of selecting an appropriate information source to support the event.

In some implementations, in addition to receiving the data objects, such as forms and official documents, from each of the information sources, computing system 1000 may also obtain supplementary information from sources, such as email, instant messaging, and other similar sources. The information from these sources may be processed to identify relevant data items that can also be stored in the data structure from the primary information sources.

In some examples, in generating the event summary for the event, in addition to or in place of identifying data items of interest, computing system 1000 may generate a score for each of the information sources based on their data items. In particular, when a user generates a request for an event, the user may provide preferences, such as the location of the event, the cost of personnel for the event, or some other similar preferences related to the event. These preferences may then be compared to the data items provided from the information sources (and stored in the common data structure) to determine a score for each of the information sources. Accordingly, if a first information source provided a location in proximity to a preferred location specified by the user, then the first information source may be provided with a higher score for that preference than a second information that had a location that was not in proximity to the preferred location. Additionally, in some implementations, in addition to the data items provided from the information sources, supplemental sources may also be used in generating the scores. This supplemental information may include reviews for each of the sources, discrepancies between proposed costs and actual costs, discrepancies between proposed lengths of operations, or some other similar information. This information may be derived from emails, from blog posts, from review websites, or some other similar source wherein the data may not directly be provided from the source for the event.

Returning to the elements of FIG. 1, information sources 122 and supplemental sources 124 may each comprise one or more computing systems (such as desktop computers, server computers, laptop computers, and the like) for a particular contractor, company, or some other similar information source. These computing systems may each comprise one or more communication interfaces and network interfaces, processing systems, computer systems, microprocessors, storage systems, storage media, or some other processing devices or software systems.

Summary service 110 may comprise communication interfaces and network interfaces, processing systems, computer systems, microprocessors, storage systems, storage media, or some other processing devices or software systems, and can be distributed among multiple devices. Summary service 110 may include software such as an operating system, logs, databases, utilities, drivers, networking software, and other software stored on a computer-readable medium. Summary service 110 may comprise one or more serving computing systems, desktop computing systems, or some other similar computing system.

Communication between summary service 110 and sources 122 and 124 may use metal, glass, optical, air, space, or some other material as the transport media. Communication between the host computing system and other computing nodes 130 may use various communication protocols, such as Time Division Multiplex (TDM), asynchronous transfer mode (ATM), Internet Protocol (IP), Ethernet, synchronous optical networking (SONET), hybrid fiber-coax (HFC), circuit-switched, communication signaling, wireless communications, or some other communication format, including combinations, improvements, or variations thereof. Communication between summary service 110 and sources 122 and 124 may be a direct link or can include intermediate networks, systems, or devices, and can include a logical network link transported over multiple physical links.

The included descriptions and figures depict specific implementations to teach those skilled in the art how to make and use the best option. For the purpose of teaching inventive principles, some conventional aspects have been simplified or omitted. Those skilled in the art will appreciate variations from these implementations that fall within the scope of the invention. Those skilled in the art will also appreciate that the features described above can be combined in various ways to form multiple implementations. As a result, the invention is not limited to the specific implementations described above, but only by the claims and their equivalents.

MANAGEMENT AND SCORING OF DATA FOR INFORMATION SOURCES

Information

Publication Number

Date Filed

Date Published

Inventors

Original Assignees

CPC

International Classifications

Abstract

Description

Claims

RELATED APPLICATIONS

Provisional Applications (1)