Knowledge Search System

Abstract

Provides a search platform that can be customized by entity. The system and method generate a custom entity type including one or more fields containing first data corresponding to a merchant system, receive updates to the first data of the custom entity type, and generate an updated custom entity type. The updated custom entity type is distributed to multiple business listing provider systems that provide search results related to the merchant system in response to search queries from end user systems. The system and method can also generate a search experience interface including multiple input fields. The search experience interface is displayed to an end user for receiving search terms via the first and second input fields in response to a single search operation.

Description

[Technical Field]

[0001] [CROSS-REFERENCE TO RELATED APPLICATIONS] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 749,457, entitled "Knowledge Search System," filed October 23, 2018, which is incorporated herein by reference in its entirety.

[0002] FIELD OF THE DISCLOSURE The present disclosure relates generally to knowledge search platforms, and more particularly to search platforms having searchable elements that are customizable by entity. [Background technology]

[0003] Merchants (e.g., businesses and individuals) have long invested significant amounts of time, money, and effort in making information about their products and services (e.g., advertisements) available to consumers (e.g., end users) in the electronic environment. Various media have been used over generations to accomplish this. The proliferation of open networks like the Internet has provided a global means to attract new customers and retain existing ones.

[0004] End users may use search engines to obtain merchant-related information that is publicly accessible over a network (e.g., the Internet). Search engines are software programs that search databases to collect and display information related to search terms specified by end users. Merchants' interaction with search engines is a key factor in the merchants' ability to reach end users and provide them with quality information about merchants that responds to their search queries. The present disclosure will become more fully understood from the detailed description given below and the accompanying drawings of various implementations of the present disclosure. [Brief explanation of the drawings]

[0005] [Figure 1] 1 illustrates an exemplary environment including a knowledge retrieval system according to an embodiment of the present disclosure. [Figure 2] FIG. 1 is a flow diagram of an example method for generating search results in response to a search query from a developer system according to an embodiment of the present disclosure. [Figure 3] 1 illustrates a diagram including a knowledge retrieval system configured to execute a search algorithm and operably couple to a developer user system and a marketer user system according to an embodiment of the present disclosure. [Figure 4] 1 illustrates an exemplary interface generated by a knowledge retrieval system according to an embodiment of the present disclosure. [Figure 5] FIG. 10 is a diagram illustrating an example of generating a search experience type by a knowledge search system according to an embodiment of the present disclosure. [Figure 6A] 1 illustrates an example interface associated with managing a search experience with a knowledge retrieval system according to an embodiment of the present disclosure. [Figure 6B] 1 illustrates an example interface associated with managing a search experience with a knowledge retrieval system according to an embodiment of the present disclosure. [Figure 6C] 1 illustrates an example interface associated with managing a search experience with a knowledge retrieval system according to an embodiment of the present disclosure. [Figure 6D] 1 illustrates an example interface associated with managing a search experience with a knowledge retrieval system according to an embodiment of the present disclosure. [Figure 6E] 1 illustrates an example interface associated with managing a search experience with a knowledge retrieval system according to an embodiment of the present disclosure. [Figure 7A] 1 illustrates an example interface related to managing an analysis by a knowledge retrieval system according to an embodiment of the present disclosure. [Figure 7B] 1 illustrates an example interface related to managing an analysis by a knowledge retrieval system according to an embodiment of the present disclosure. [Figure 8] 1 illustrates an exemplary interface related to search experience configuration and analysis managed by a knowledge retrieval system according to an embodiment of the present disclosure. [Figure 9A] 1 illustrates a flow diagram of an example method for creating association types relating multiple entity types to manage updates in a knowledge graph associated with a merchant system according to an embodiment of the present disclosure. [Figure 9B] 1 illustrates an example interface for creating entity types and relationship types according to an embodiment of the present disclosure. [Figure 9C] 1 illustrates an example interface for creating entity types and relationship types according to an embodiment of the present disclosure. [Figure 10] 10 illustrates an example interface for creating fields associated with a custom entity type created by a knowledge retrieval system according to an embodiment of the present disclosure. [Figure 11] FIG. 1 is a block diagram of an exemplary computer system in which implementations of the present disclosure may operate. DETAILED DESCRIPTION OF THE INVENTION

[0006] To find relevant data related to queries received from end users (e.g., users initiating searches via a web interface), many search engines use keyword searches based on text data provided by the end users. When performing a search, the end user attempts to identify web elements (e.g., web pages) responsive to the query, which are copied and indexed by the search engine based on the keywords in the search query input. If any of the keywords are incorrect (e.g., incomplete, typo-filled, misspelled, etc.) or not indexed by the search engine, the information the end user searches for may not be identified or found in response to the query. If the combination of keywords in the search query matches multiple web pages, information about those web pages (e.g., links, etc.) may appear in multiple search result web pages. This may require the end user to manually click multiple links and sort through hundreds or thousands of similar web pages before finding the desired information. In other situations, the requested information responsive to the user query may not be found due to gaps (e.g., lack of content, etc.) between the keywords in the end user query and online data related to an entity (e.g., a merchant). Thus, the amount of information and misinformation that an end user must process to find a particular product or service can create an overly time-consuming process that results in the end user abandoning their search effort before obtaining the desired information, which can result in lost business opportunities for merchants related to the search query.

[0007] Embodiments of the present disclosure address the above problems and other deficiencies in conventional search engine technology by providing a knowledge search system that enables end users (e.g., individuals using search engines to obtain knowledge or information about merchants, products, or services) to create an improved search experience using one or more knowledge search features. In one embodiment, knowledge can be defined as "facts," information, or data about a subject that is stored in a data store (e.g., a database, etc.) and can be queried to generate responsive search results. In some embodiments, the knowledge search engine platform includes a natural language processor that can process search query hints and auto-completion techniques to intuitively guide end users toward useful responses. The knowledge search process is performed by the knowledge search engine platform based on information about specific data related to business product data.

[0008] In one embodiment, a merchant user (i.e., a user acting on behalf of a business entity, also referred to as an "entity user") can use the knowledge retrieval system of the present disclosure to manage and centralize structured data about an entity (e.g., a company, etc.) and surface the entity data on an electronic platform (e.g., a first-party website or a third-party website related to the entity). In one embodiment, the entity data can be provided via the knowledge retrieval system to multiple different publisher systems (e.g., websites such as Google®, Facebook®, Bing®, Apple®, etc., social media platforms, search engine platforms, etc.).

[0009] In one embodiment, the knowledge retrieval system of the present disclosure can utilize multiple different entity types (e.g., categories or classifiers of information) to organize searchable information and generate search results containing desired information in response to a query. The different entity types can be system-based entity types (e.g., default entity types generated by the knowledge retrieval system and used by multiple different entities, also referred to as "system entity types") and customized entity types (e.g., entity types generated by the knowledge retrieval system according to instructions from a particular entity). In one embodiment, customized entity types (also referred to as "custom entity types") can be created, selected, and managed by an entity to provide searchable information elements when generating search results in response to an end-user search.

[0010] In one embodiment, a custom entity type can be mapped, linked, associated, or logically connected to another entity type via a relationship type. In one embodiment, a relationship type can include a defined association between multiple entity types. For example, multiple custom entity types can be associated with one or more relationship types. In another example, a custom entity type can be linked to a system entity type by one or more relationship types. Advantageously, customized entity types and relationship types enable entity users to update entity data through the knowledge retrieval system (e.g., in a single "place" or through the system) and update the entity data across multiple different publisher systems (e.g., multiple different search engines, etc.). In this regard, through a single interaction, an entity user (e.g., a company, etc.) can update entity data by updating, adding, modifying, changing, etc., data related to a first entity type and have corresponding data updates performed for other entity types related to the first entity type via one or more established relationship types. This enables entity data to be updated across multiple different publisher systems, establishing uniformity and consistency in the type, quality, and accuracy of entity data returned to end users by different publisher systems in response to queries.

[0011] 1 illustrates an exemplary environment 10 including a knowledge retrieval system 100 operatively coupled to one or more merchant systems 101. In one embodiment, the knowledge retrieval system 100 enables a user (referred to herein as a "merchant user") operating a communicatively connected merchant device 102 on behalf of the merchant system 101 to enhance one or more business listings associated with the merchant in accordance with one or more aspects of the present disclosure.

[0012] According to an embodiment, the knowledge retrieval system 100 includes modules configured to perform various functions, operations, actions, and activities, as described in detail herein. In one embodiment, the knowledge retrieval system 100 includes an entity type manager 110, a search experience management component 120, and a knowledge search engine 130 operably coupled to one or more processing devices 140 and memory 150. In one embodiment, the memory may include a knowledge retrieval system database configured to store data related to the knowledge retrieval system 100. In one embodiment, the software modules may execute on one or more computer platforms of the knowledge retrieval system interconnected by one or more networks, which may include the Internet. The software modules may be, for example, hardware components, circuits, dedicated logic, programmable logic, microcode, etc., implemented by the processing device 140 executing instructions stored by the memory 150 of the knowledge retrieval system 100.

[0013] In some embodiments, the knowledge retrieval system 100 can generate expanded business listings for provisioning to the end-user systems 170 in response to one or more search queries 172 initiated by one or more end-user systems 170 via an interface operatively coupled to the knowledge search engine 130 of the knowledge retrieval system 100. In one embodiment, the search queries 172 can be submitted by one or more end-user systems 170 via interfaces with the knowledge retrieval system 100, the merchant system 101, and one or more business listing provider systems 180 (e.g., third-party search engines, websites, applications, etc., such as Google®, Yelp®, Bing®, etc.). As used herein, the term "end user" refers to one or more users who operate an electronic device (e.g., end-user system 170, etc.) to submit search queries 172 to a system (e.g., merchant system 101, knowledge retrieval system 100, business listing provider system 180) and obtain search results related to the merchant. For example, an end-user system 170 can initiate a search by entering a search query through a web page interface of the merchant system 101. In one embodiment, search results are generated based on merchant information managed by the knowledge retrieval system 100.

[0014] As an example, an end-user system may be a customer or prospective customer searching for information about one or more merchants. In one embodiment, the knowledge retrieval system 100 is communicatively coupled to the end-user system 170 and operates to respond to search queries 172.

[0015] In one embodiment, knowledge retrieval system 100 is operatively coupled to one or more merchant systems 101, one or more end-user systems 170, and a business listing provider system 180 via a suitable network (not shown), including, for example, the Internet, an intranet, an extranet, a wide area network (WAN), a local area network (LAN), a wired network, a wireless network, or other suitable network, or any combination of multiple such networks. In one embodiment, knowledge retrieval system 100 includes a processing device 140 and a memory 150 configured to execute and store instructions related to the functionality of the various components, services, and modules of knowledge retrieval system 100, as described in more detail below in connection with FIGS. 1-11 .

[0016] In one embodiment, merchant system 101 may include one or more components of knowledge retrieval system 100. In this embodiment, merchant system 101 and knowledge retrieval system 100 may be integrated such that merchant system 101 uses knowledge retrieval system 100 and its associated functionality to respond to one or more search queries 172 received from communicatively connected end-user systems 170. According to an embodiment of the present disclosure, as shown in FIG. 1 , user device 130 may send search queries 172 to merchant system 101 (merchant system 120 is coupled with knowledge retrieval system 100) and / or send search queries 172 related to merchant system 120 to knowledge retrieval system 101.

[0017] Merchants, via merchant system 101, can use knowledge retrieval system 100 to manage their data relevant to knowledge searches (also referred to as "merchant data") and use knowledge retrieval system 100 to "push" or otherwise provision merchant data to end users (e.g., customers) in response to search queries 172 and / or to "push" or otherwise provision merchant data to one or more business listing provider systems 180. In this regard, merchant system 101 controls the data returned to end users from knowledge retrieval system 100. In other embodiments, at least a portion of the merchant data may be "pulled" or otherwise received from other systems, such as websites associated with merchants or other types of search websites. In one embodiment, merchant users use merchant system 101 to communicate with knowledge retrieval system 100 to request changes to merchant data (e.g., data that may be provided to end users in response to related input queries 140).

[0018] In some embodiments, the merchant system 101 and the business listing provider system 180 include one or more modules (e.g., APIs, etc.) that the knowledge retrieval system 100 interacts with to perform operations and provide relevant merchant data to the end-user system 170. For example, the merchant system 101 and the business listing provider system 180 may include APIs for accessing one or more pre-defined databases dedicated to storing information about a particular merchant's products, services, employees, events, etc. (e.g., merchant data). In other embodiments, the knowledge retrieval system 100 may include databases that store all or a portion of the merchant data. For example, the knowledge retrieval system 100 may include one or more pre-defined databases dedicated to storing information related to the merchant data.

[0019] 1, knowledge retrieval system 100 may include multiple modules executing on one or more computer platforms interconnected by one or more networks, which may include any suitable network such as the Internet. In some embodiments, a module may include one or more hardware components, circuitry, dedicated logic, programmable logic, microcode, etc., and one or more instruction sets executable by one or more processing devices of knowledge retrieval system 100. The modules are configured, for example, (1) an entity type manager 110 to enable the establishment of customized entity types and relationship types associated with multiple entity types to associate with merchant data, (2) a search experience management component 120 to enable the merchant system 101 to configure or customize a set or collection of input fields to define a search experience that can be presented to and used by end-user systems 170 to conduct searches related to merchants (e.g., the search experience is provided to end-users via the merchant system's website interface), and (3) a knowledge search engine 130 to provide enhanced website searches by analyzing search queries initiated by end-user systems 170 to identify natural language queries related to specific merchant-related questions (e.g., merchant data related to products, services, employees, events, locations, etc.).

[0020] In one embodiment, the knowledge retrieval system 100 is configured to communicate with merchant systems 101, end user systems 170 and business listing provider systems 180 across a range of expertise based on factors such as distance, prominence, traffic, cultural relevance, industry relevance, event type relevance, directory vs. editorial site, paid vs. free, long-term vs. last-minute planning, etc.

[0021] The entity type manager 110 enables the merchant system 101 (e.g., a merchant user) to interact with the knowledge retrieval system 101 to perform various operations, such as creating customized entity types associated with merchant data and establishing relationships (i.e., relationship types) between multiple different entity types associated with merchant data.

[0022] In one embodiment, the end user can use the user device 130 to submit suggested or requested changes or edits to portions of the merchant information provisioned to the end user in response to the search query 172 (e.g., the end user can suggest changes to a merchant's business hours if they determine that the published business hours are inaccurate). In response, the knowledge retrieval system 100 reviews the suggested or proposed changes and provides a change request to the merchant system. In one embodiment, the knowledge retrieval system 100 updates information related to the merchant and provides notification of the updates or changes to the merchant system 101. In one embodiment, the knowledge retrieval system 100 collects the updated information related to the merchant and provides the updated information to the merchant system 101 for review and approval before adopting the updates or changes.

[0023] In some embodiments, the knowledge retrieval system 100 allows merchant users to interact with end users through a conversational user interface (UI). Merchant users can opt into this feature of the knowledge retrieval system 100 by entity and / or interaction type. In some embodiments, merchant users add phone numbers and / or account information for each interaction type of an entity (without being associated with a user). In some embodiments, the knowledge retrieval system 100 can auto-enable the merchant system for specific account types or businesses and use a customer matching API to collect social media-related information about the merchant user (e.g., the end user's Facebook® identifier). According to one embodiment, in response to the knowledge retrieval system 100 registering a location with the merchant and verifying that the merchant user is linked to a valid phone or social media account (depending on the interaction type), the knowledge retrieval system 101 can interact with the merchant user on the associated social networking platform.

[0024] According to an embodiment of the present disclosure, the knowledge search engine 130 performs a search based on input from an end user (e.g., a search query 172 submitted by an end user system 170 via an interface operatively coupled to the knowledge retrieval system 100). In one embodiment, the search may be based on information entered by the end user (e.g., a zip code, location information, or other information that may lead to the determination of the end user's location and / or location of interest). In another embodiment, the search may be based on where the end user (e.g., the user device 130) is searching from (e.g., the IP address of the user device is queried and used in the search). The knowledge search engine 130 may evaluate the search results and provide recommendations to the merchant user. In one embodiment, the recommendations are presented to the merchant system 101 as notifications provided by the knowledge retrieval system 100.

[0025] In another embodiment, the knowledge retrieval system 100 provides one or more recommendations to the merchant system 101 to improve the content of search results for the merchant, as described in detail herein. For example, a search of published competitive information in an indexed search engine database can be performed by the knowledge retrieval system 130. For example, the knowledge retrieval system 100 can determine that a competitor associated with the merchant has published multiple images related to the competitor's stores in applicable locations. In one embodiment, the knowledge retrieval system 100 can send a message (e.g., text, email, etc.) to one or more merchant devices 102 associated with the merchant system 101 to recommend that the merchant add photos to applicable business locations corresponding to the competitor's business locations. With input from the merchant system 101, the knowledge retrieval system 100 can upload the photos to one or more business listing provider systems 180.

[0026] According to an embodiment, the knowledge retrieval system 100 can generate one or more interfaces to enable the end-user system 170 to perform a search for information. In one embodiment, the one or more interfaces presented by the knowledge retrieval system 100 to the end-user system 170 (e.g., via a graphical user interface on a user device used by the end-user) may provide one or more of the following features: 1) performing real-time auto-completion in response to an end-user's input entry (e.g., as the end-user types or otherwise enters a search query (e.g., voice dictation)) in, for example, less than 100 ms, less than 50 ms, etc.; 2) generating response result cards (e.g., one or more responses to an end-user search query including location information including maps, events related to the merchant, etc.); 3) providing a single search interface (e.g., a single box) that allows an end-user to search for and identify multiple different types of information using a single search query (e.g., a search initiated by a single search operation); 4) generating search results based on incorrect or ambiguous search queries (e.g., allowing searches configured to manage spelling errors and synonyms). 5) generating a ranked list of search results based on one or more ranking parameters configured to present the search result data in a manner optimized for end-user consumption; 6) generating search results that include one or more sections to differentiate the search results; 7) generating search results that include highlighting of one or more "matching" search terms; 8) conducting a search of properties related to the search in addition to related entities; and 9) enabling keyboard navigation that allows end users to type using arrow keys to navigate a user-friendly search experience.

[0027] As shown in FIG. 1 , the knowledge retrieval system 100 can be operatively coupled to one or more developer systems 105 to provide enhanced and improved functionality to developers. According to one embodiment, the knowledge retrieval system 100 provides one or more developer systems 105 with a JavaScript library configured to wrap associated application programming interfaces (APIs) and facilitate the display of associated user interfaces (UIs). According to one embodiment, the knowledge retrieval system provides an improved API, allowing the developer systems 105 to make a single API call to search all available databases and return results in a structured format. Advantageously, the above-described features enable the knowledge retrieval system 100 to reduce the latency and costs experienced by developer users using mobile devices by reducing API calls and associated processing time and resource consumption.

[0028] FIG. 2 is a flow diagram illustrating an exemplary process 200 including steps performed by a knowledge retrieval system (eg, knowledge retrieval system 100 of FIG. 1) communicatively coupled to a developer user according to an embodiment of the present disclosure.

[0029] In block 210, the knowledge retrieval system presents a search field to a developer user (e.g., a device or system operated by a user of the developer system 105). In block 220, the knowledge retrieval system receives a first input from the developer user. In one example, the first input may include one or more characters entered by the developer user into the provided search field.

[0030] In block 230, the knowledge retrieval system generates a first search result set in response to a first input received from a developer user. In one embodiment, the first search result set may include a number of result entries presented in a prioritized or ranked order. In one embodiment, the first search result set may be derived based on a review and analysis of information stored in one or more databases. In one embodiment, depending on the API, returning the first search result set may require a large number of complex API queries to search multiple fields and entities.

[0031] In block 240, the knowledge retrieval system displays the first set of search results. In one embodiment, the search results may include cards rendered for each result type. In one embodiment, the first set of search results may be grouped into multiple sections. In one embodiment, portions of the search results that match portions of the text associated with the first input may be highlighted.

[0032] In block 250, the knowledge retrieval system may receive from the developer user a selection of a first search result from the first search result set. In one embodiment, the developer user may enter their selection using a mouse, keyboard, voice command, touch screen, or other input device or mechanism. In response to receiving the selection, the knowledge retrieval system may store the selection (block 260), perform another search (e.g., display advisors near a zip code, etc., block 270), or redirect the developer user to an entity web page (e.g., display event details, etc., block 280).

[0033] In one embodiment, in response to displaying the first search result set at block 240, the knowledge retrieval system may receive second input (e.g., one or more new characters) from the developer user at block 255. In response to receiving the second input, the process may return to block 230 and continue as shown.

[0034] According to embodiments of the present disclosure, marketers are provided with enhanced and improved functionality by a knowledge retrieval system. In one embodiment, the knowledge retrieval system provides one or more marketers with features and functionality that enable marketer users to tailor their search experience and improve corresponding search results. In one embodiment, the knowledge retrieval system provides marketer users with well-tailored search results based on analytics that enable marketer users to tailor search results to improve their quality. In one embodiment, this can be based on generating an understanding of search performance.

[0035] In one embodiment, the knowledge retrieval system provides marketer users with the ability to change how search results are returned or displayed. Traditionally, changing how search results are displayed required developers to change the UI or API calls. However, making frequent changes can be a very tedious task.

[0036] In one embodiment, the knowledge retrieval system "dumbs" the API calls. In one embodiment, instead of performing all of the logic regarding which fields to search, which entities to search, which rankings to use, etc., the knowledge retrieval system moves that logic behind the API calls. In one embodiment, within the knowledge retrieval system, marketer users can then control the details of the search results using the knowledge retrieval system interface. In one embodiment, the search algorithms performed by the knowledge retrieval system are moved from the client side to behind the API (e.g., invisible to the front-end developer user), as shown in the logic diagram of Figure 3.

[0037] According to one embodiment, the knowledge search system includes a JavaScript library, a search API to facilitate "simpler" queries, and an improved interface (e.g., a knowledge search interface configured for display via a dashboard) to enable configuration and analysis of the search API.

[0038] In one embodiment, a JavaScript library facilitates building a search experience. In one embodiment, a user (e.g., a developer user, a marketer user, etc.) can provide inputs, section headers, and result cards, and a JavaScript library in the knowledge retrieval system presents search results and manages user interaction. In one embodiment, the JavaScript library can automatically send analysis back to the knowledge retrieval system for further review and analysis.

[0039] In one embodiment, the knowledge retrieval system may include a search API that allows an end user to search multiple fields and multiple entities of a collection of information (also referred to as a "knowledge graph") with a single API call (e.g., a single search operation in response to a single instruction by an end user system). In one embodiment, the search experience management component 120 of the knowledge retrieval system 100 may be used by the merchant system 101 to configure a search experience interface defined by multiple input fields and entity types that are searched with a single API call. In one embodiment, the knowledge retrieval system may use one or more API filters to enable an end user to engage the search experience interface to perform searches across multiple fields and multiple entities with a single API call. In one example, the API call itself is "dumb" and may be structured according to the following example structure:

number

[0040] In one embodiment, one or more different data types can be used to generate a search experience interface that includes multiple different input fields. In some embodiments, an exemplary data type that can be used to define a search experience interface is one or more input fields. In one embodiment, an input field is a group of searchable attributes. In one embodiment, one or more input fields of a search experience interface can be used to control and manage the input of text related to a search query entered via a web page. For example, the input field can be a location selector or a search (i.e., collection of information) across a knowledge graph. In some embodiments, each search experience interface can include multiple input fields.

[0041] In some embodiments, an input field of the search experience interface can include one or more parameters. In one embodiment, a parameter represents a type of data that can be searched across in the corresponding input field. In one embodiment, each input field includes at least one parameter. Examples of parameters include name, entity type (e.g., specificity, condition, etc.), address, etc.

[0042] FIG. 4 illustrates an example search experience interface 400 generated by a knowledge retrieval system according to an embodiment of the present disclosure. As illustrated, the search experience interface 400 includes multiple input fields (e.g., a “location” input field 410 and a “provider” input field 420) configured to receive one or more search terms associated with an input field category (e.g., location, provider, specialty, etc.). In one embodiment, for each input field 410, 420, an end user can select or enter one or more search terms associated with multiple different parameters 412, 422. For example, the location input field 410 is configured to allow entry of search criteria for a first set of parameters 412 (e.g., parameter 1, parameter 2, parameter 3), and the provider input field 420 is configured to allow entry of search criteria for a second set of parameters 422 (e.g., parameter X, parameter Y, parameter Z). Execution of a single search can be initiated via a single search action, such as interaction with a search action button 430. A single search can be performed against the search terms (e.g., search criteria) provided for the illustrated search experience interface 400 or for parameters of multiple input fields. It should be noted that a given input field may be associated with any number of parameters, and any number of input fields may be used to generate a search experience interface.

[0043] FIG. 5 illustrates an example of a search experience interface generated by the knowledge retrieval system of the present disclosure. As shown in FIG. 5, a merchant system (e.g., merchant system ABC501) interacts with knowledge retrieval system 500 to generate a search experience interface for use with one or more web pages or other interfaces associated with merchant system ABC501. In this example, knowledge retrieval system 500 generates a "Search for Providers" search experience type. According to one embodiment, merchant system ABC501 selects a "Location" input field (i.e., input field 1 in FIG. 5) and a "Provider" input field (i.e., input field 2 in FIG. 5) as input fields to be included in the "Search for Providers" search experience interface. According to one embodiment, merchant system ABC501 selects one or more parameters to associate with each of the input fields (input field 1 and input field 2). In this example, a "City, Postal, Location" parameter field is associated with the location input field. Additionally, input field 2 is associated with parameters for provider type, terms, specialty, provider name, and common name. Advantageously, in one embodiment, parameters can be used to refine the search experience through association with corresponding input fields. In one embodiment, the input fields and corresponding parameters are displayed on the end-user system via a search experience interface, and the end-user can enter or select one or more search terms for each input field to submit a search query for processing by the knowledge retrieval system.

[0044] According to one embodiment, a search experience interface associated with a "Search for Providers" search experience may be presented to an end user system via one or more web pages or application pages associated with merchant system ABC 501. An end user may generate a search query by entering information into a number of input fields via the search experience interface. According to one embodiment, knowledge retrieval system 500 may return one or more search results (e.g., a search result set) corresponding to the search query.

[0045] As described above, in one embodiment, the search experience can have one or more input fields. In another embodiment, the search experience interface can be defined and established without input fields. In one embodiment, an input field can be associated with a parameter. For example, a marketer user can adjust the behavior of an input field without working with a developer user. For example, a marketer user can add a second searchable input field to the search experience interface. In one embodiment, the knowledge retrieval system can generate and process query analytics associated with each input field to generate analytical data associated with search queries performed using the input fields.

[0046] As described above, when configuring an input field, the merchant system can select a set of parameters to include in the input field. In one embodiment, when viewing analytics, the merchant system can use the set of parameters and one or more additional "filters" included via the API. For example, when a user uses a knowledge retrieval system to collect analytics data, no input fields are used, and one or more parameters (e.g., filters, etc.) can be presented via the interface.

[0047] In one embodiment, the one or more parameters may be identified by a color in the user interface. The merchant system may configure the parameters (filters) displayed in association with one or more input fields in a uniform color scheme, where the parameters have the same color across multiple different web pages of the merchant system.

[0048] In some embodiments, the knowledge retrieval system can include a program library (e.g., a Javascript library), a user interface for configuration and analysis, and multiple API endpoints. In some embodiments, the program library can be used to build the search experience and corresponding search experience interface. In some embodiments, the merchant system is provided with the inputs, section headers, and result cards, and the library handles presenting the results and user interaction. Additionally, this program library can send analysis back to the knowledge manager 168.

[0049] In some embodiments, data stored in a database associated with the knowledge retrieval system may be automatically synchronized to a website associated with a merchant system in response to an end-user system submitting a search query via a user device based on the created search experience.

[0050] FIG. 6A illustrates an example interface of a knowledge retrieval system configured to allow a merchant user to manage, modify, create, and update one or more search experience types and search experience interfaces. As illustrated, a merchant user (e.g., Merchant ABC) representing a merchant system can log in to the knowledge retrieval system to view a display of one or more search experiences associated with their account at the merchant system. As shown in this example, Merchant ABC has four active search experiences: a "Search for Doctors" search experience, a "Search for Hospitals" search experience, a "Search for Home Care and Hospice" search experience, and a "Search for Insurance Plans" search experience. For each search experience, a search experience name or label and one or more corresponding input fields are displayed. In one embodiment, each input field can have one or more parameters that are either selected by the merchant system or default parameters set by the knowledge retrieval system.

[0051] 6B shows an exemplary interface generated by the knowledge retrieval system to enable the merchant system to generate or create a new search experience. In one embodiment, the merchant user can select a new search experience from a list of pre-built templates or exemplary search experiences (e.g., an "All Entity Finder" template, a "Physician Finder" template, an "Events Calendar" template, a "Financial Advisor Finder" template, a "Menu Item Finder" template, a "Nearby Services Finder" template, and a "Store Locator" template, etc.) or select an option to create a custom search experience (e.g., a "Custom Search Experience" template, etc.). In one embodiment, in response to selecting a search experience template, the knowledge retrieval system provides a corresponding template.

[0052] In one embodiment, if the merchant user selects the "Custom Search Experience" template, the knowledge retrieval system provides the merchant user with a prompt to select information related to the custom search experience, including a search experience name, a search experience or API key, a description of the search experience, and a list of one or more entity types to be searched in response to end-user queries submitted using the custom search experience. Following selection of a pre-built or custom search experience (as shown in FIG. 6C), the knowledge retrieval system generates a search experience interface or page.

[0053] FIG. 6D illustrates an exemplary interface generated by a knowledge retrieval system configured to allow a merchant user to review and manage a search experience. As illustrated, the knowledge retrieval system presents settings related to the search experience (e.g., name, description, list of information entities to query, etc.) and corresponding input fields in the search experience interface. In this example, input field 1 is a “Location” input field having a “Location” parameter. Input field 2 is a “Provider” input field having a set of parameters including “Doctor Name,” “Condition,” “Specialty,” “Language,” “Practice Name,” and “Symptoms” parameters. As illustrated in FIG. 6D, the knowledge retrieval system displays a “live preview” of the search experience, where the merchant user can test the search experience by interacting with the input fields and executing queries to obtain search results. As illustrated, the merchant system can add new input fields or delete existing input fields associated with the search experience through the knowledge retrieval system interface. In one embodiment, the merchant system can add or delete parameters associated with each input field.

[0054] FIG. 6E illustrates an exemplary interface generated by a knowledge retrieval system to allow a merchant system to edit or modify a search experience. In this example, the merchant system interacts with the interface to configure parameter settings associated with the "provider" input field. As shown, the return value and typographical (or "typo") tolerance associated with each parameter can be set. In one embodiment, a search experience can be customized without specific input fields. This "empty" search experience includes generic or non-specific search fields to allow end users to submit search queries.

[0055] In some embodiments, the knowledge retrieval system 100 can store end-user search queries (via one or more databases) and present them as analytics to the merchant system. According to one embodiment, the knowledge retrieval system 100 can enable the merchant system 101 to configure and display analytics about the search experience. In one embodiment, knowledge searches may be provided via tabs under the "Search" tab. In one embodiment, a merchant user can set up new example searches, determine which entity types and fields will be searched, identify matching logic, and configure how search results should be ranked (e.g., analysis of example searches, etc.), as shown in FIG. 7A. FIG. 7B shows an example interface for configuring an example search bar.

[0056] In one embodiment, an example search bar from a knowledge retrieval system may include analytical information and configuration information. Example analytical information may include one or more of the following: 1) hero numbers (e.g., total number of searches, average number of results, average response time, time to results, etc.), 2) high-level metrics over time (e.g., number of searches over time by platform (e.g., phone, tablet, desktop, etc.), average response time, etc.), 3) a list of frequently or commonly selected options, 4) a list of frequently or commonly selected queries (condensed queries that do not present all typed characters, presenting the most with no results, the most with no selected results, etc.).

[0057] In one embodiment, exemplary configuration information may include one or more of the following: 1) searchable attributes; 2) other configurable settings such as API keys, answer box keys, group results in sections, etc. In one embodiment, the knowledge retrieval system may provide one or more of the following features to merchant marketer users: 1) search as you type functionality; 2) a single search across multiple entities and attributes; 3) fast and efficient search; 4) a customized or customizable experience for a given use case. In one embodiment, the knowledge retrieval system may provide one or more of the following analyses to marketer users based at least in part on direct feedback from consumers or end users: 1) descriptions of how end users search; 2) descriptions of what end users are interested in; 3) identification of opportunities to improve search; and 4) identification of opportunities to improve business practices.

[0058] According to embodiments, users have a greater degree of control compared to traditional systems that rely on information technology personnel. For example, users can configure the display and change results without requiring developers or additional IT resources. Figure 8 illustrates an exemplary interface generated by a knowledge retrieval system according to embodiments of the present disclosure. Figure 8 illustrates an exemplary interface for a view of multiple search examples (e.g., all available search examples).

[0059] In one embodiment, a knowledge retrieval system (such as entity type manager 110 of knowledge retrieval system 100 shown in FIG. 1 ) enables a merchant system to establish a knowledge graph that includes multiple entity types (e.g., custom or system-defined) related by one or more relationship types. The knowledge graph represents information in data associated with the merchant system that is maintained, updated, and stored in one or more data fields of the entity types associated with the merchant system. In one embodiment, updates to a first entity type in the knowledge graph can be distributed to one or more other entity types in the knowledge graph based on relationship types defined between multiple entity types.

[0060] FIG. 9A illustrates a flow diagram of a method 900 for generating relationship types that relate multiple entity types to manage updates to a knowledge graph associated with a merchant system, according to an embodiment of the present disclosure. Method 900 may be implemented in hardware (e.g., a processing device, circuitry, dedicated logic, programmable logic, microcode, device hardware, integrated circuitry, etc.), software (e.g., instructions running or executable on a processing device), or a combination thereof. In some embodiments, method 900 is performed by entity type manager 110 of knowledge retrieval system 100 of FIG. 1 . Although shown in a particular order, the order of processes can be changed unless otherwise specified. Therefore, the illustrated embodiment should be understood as an example only, and the illustrated processes can be performed in a different order, and some processes can be performed in parallel. Furthermore, in various embodiments, one or more processes can be omitted. Therefore, not all processes are required in all embodiments. Other process flows are possible.

[0061] As shown, at operation 910, process logic generates a first entity type associated with the merchant system, the first entity type including one or more first data fields including first data corresponding to the merchant system. In one embodiment, the first entity type may be a custom entity type (e.g., established and configured by the merchant system) or a built-in or system-defined entity type. The first entity type may include one or more data fields including data (e.g., data values, etc.) associated with the merchant system.

[0062] At operation 920, process logic generates a second entity type associated with the merchant system, the second entity type including one or more second data fields that include second data corresponding to the merchant system. As described above, the second entity type may be a custom entity type or a system-defined entity type. Like the first entity type, the second entity type is configured to include one or more data fields for storing data related to the merchant system. Examples of a first entity type (e.g., a "restaurant" entity type, etc.) and a second entity type (e.g., a "menu" entity type, etc.) are shown in FIG. 9B.

[0063] At operation 930, process logic establishes a relationship between a first entity type and a second entity type, where at least a first portion of the first data matches at least a second portion of the second data. In one embodiment, the relationship is defined by a relationship type that links or associates multiple entity types. For example, as shown in FIG. 9B, the "Offered at" relationship type establishes a defined relationship between a first entity type ("Restaurant") and a second entity type ("Menu"). In one embodiment, the relationship type defines the nature of the association between multiple entity types and can be used to identify additional entity types to be updated in response to an update of an entity type. In one embodiment, the relationship type can represent that multiple entity types share data (e.g., at least some of the data fields of the multiple entity types match each other).

[0064] At operation 940, process logic receives an update to a first portion of the first data of the first entity type from a merchant system. In one embodiment, the update to the first portion of the first data may include deleting, modifying, adding, reformatting, changing, etc., one or more data values ​​of one or more data fields of the entity type. In one embodiment, the update to the first entity type may be performed via communication or interaction between the merchant system and the knowledge retrieval system.

[0065] At operation 950, process logic creates a first update entity type that includes the update to the first data. In one embodiment, the first update entity type is created and stored in association with a merchant system.

[0066] At operation 960, in consideration of the relationship between the first entity type and the second entity type, process logic updates a second portion of the second data of the second entity type to generate a second updated entity type. In one embodiment, process logic may identify a relationship type between the first entity type and one or more other entity types, including the second entity type, in response to the update to the first entity type. The process logic may use the relationship type to identify a match between at least a portion of the data of the first entity type and the data of the second entity type. In one embodiment, the relationship type may be used in this regard to determine whether to update the second entity type in consideration of the update to the first entity type. Note that an entity type (e.g., the first entity type) may be related to multiple other entity types by one or more different relationship types, as shown in the example of FIG. 9C . Advantageously, through a single interaction by the merchant system (e.g., updating the first data of the first entity type), one or more other entity types (e.g., the second entity type) may be updated to include the updated data in terms of the relationship types linking the entity types in a knowledge graph associated with the merchant system. In one embodiment, this advantageously allows a merchant system to initiate updates in a single stored location (e.g., a first entity type) and have the updates distributed and "pushed" to other entity types in the knowledge graph.

[0067] At operation 970, process logic stores the first updated entity type and the second updated entity type in a data store. In one embodiment, process logic can distribute the first updated entity type and the second updated entity type to one or more third-party systems (e.g., business listing provider system 180 of FIG. 1 ). Advantageously, updates to the first entity type can be linked and shared with other entity types based on established relationships. Furthermore, the updated entity types can be distributed to multiple different third-party systems (e.g., search engines, websites, etc.) such that a single update (e.g., an update to the first entity type) can update to another entity type, updating information related to merchants in multiple different locations.

[0068] 9B-9C illustrate example interfaces generated by the knowledge retrieval system to enable interaction with merchant systems and to create and manage custom entity types. The various example interfaces illustrated in Figures 9B-9C illustrate various features and functionality associated with the knowledge retrieval system, as described in more detail below.

[0069] In one embodiment, the knowledge retrieval system may include a number of built-in (e.g., system-defined) entity types that relate to a number of different base types (e.g., people, places, services, etc.). In one embodiment, the system-defined entity types may be vertically specialized (e.g., people and doctors, places and medical professionals, services and medical procedures, etc.). In one embodiment, the system definitions are established in response to the knowledge retrieval system coupling to a publisher network.

[0070] In one embodiment, the knowledge retrieval system provides system-defined entity types and custom entity types. In one embodiment, the knowledge retrieval system provides inheritance functionality that allows entity types (either system-defined or custom) to build upon other entity types. In one example, the knowledge retrieval system can categorize entity types to enable "answers" (i.e., search results) to an example search query that retrieves all person entities for an organization, where the organization is set up with staff, executives, engineers, etc.

[0071] In one embodiment, the knowledge retrieval system allows a merchant system to store data about entity types and define how the entity types are related by establishing relevant relationship types between multiple entity types. For example, a first entity type ("doctor") may be related to a second entity type ("location") by a first relationship type ("worked at") to link or relate multiple entity types. Further, in this example, the first entity type ("doctor") may be related to a third entity type ("medical procedure") by a second relationship type ("specialty") to link the first entity type with the third entity type. In this example, the knowledge retrieval system generates mappings or associations between multiple entity types by considering the identified relationship types to establish the following relationships: a doctor "works at" a location and "specializes in" a medical procedure. In one embodiment, the knowledge retrieval system can add custom entity types (to a merchant system) and monitor and observe how the merchant system interacts with the knowledge retrieval system to track how the merchant system manages the custom entity types and the relationships between the entity types.

[0072] In some embodiments, a merchant system can create relationships between custom entity types and multiple entity types (e.g., custom or built-in entity types, etc.). For example, in FIG. 9A , the merchant system can interact with a knowledge retrieval system to manage entity types and corresponding relationship types. In one example, the merchant system can establish a relationship ("Offered at") between a first entity type ("Restaurant") and a second entity type ("Menu"). In one embodiment, the first entity type and the second entity type can be system-defined entity types, custom entity types, or a combination thereof.

[0073] FIG. 9B illustrates an example set of entity types linked to each other by relationships generated in accordance with an embodiment of the present disclosure. In one embodiment, the knowledge retrieval system establishes multiple entity types (e.g., "Offer," "Restaurant," "Event," "Job," "Menu," "Menu Item") and multiple relationships (e.g., "Offered at," "Position at," "Promoted at," "Available on," "Available at") between different pairs of entity types. For example, the entity type "Job" is a system-defined entity type, and the entity type "Offer" is a custom entity type. In one embodiment, the merchant system can create a custom entity type for limited-time offers for specific restaurants. These limited-time offers can be discounts on specific menu items offered at specific restaurants (e.g., buy a hamburger, get free fries). The merchant system can define which restaurants (e.g., the relationship between the restaurant entity type and the offer entity type) offer the offer (e.g., all, a subset, etc.) and which menu items are included in the offer (e.g., the relationship between the menu items and the offer).

[0074] In some embodiments, if an offer changes (e.g., buy a hamburger, get a free soda), the merchant system can update the corresponding entity type (e.g., the Offer entity type). For example, if the merchant system changes an offer of the "Offer" entity type, the relationship established between the entity types automatically changes the offer in relation to the restaurant and menu item where it is offered.

[0075] In one embodiment, if a merchant has different first-party web pages for menus, limited-time offers, and restaurant locations, that information can be automatically updated across all web pages. In one embodiment, merchant information can be updated in one or more databases of the knowledge retrieval system across one or more entity types associated with the merchant system. For example, a menu can be updated to display a new limited-time offer, the specific restaurant location where the offer is offered can be updated (e.g., via a corresponding API) to display the new offer, and the limited-time offer web page can be updated to display it. In other embodiments, the knowledge retrieval system can update information across third-party websites (e.g., online listing publishers, search engines, etc.) in response to updates of information types by the merchant system, e.g., via a corresponding API. FIG. 10 shows an exemplary interface generated by the knowledge retrieval system that enables a merchant system to create, update, and manage custom information types according to an embodiment of the present disclosure. In one embodiment, the knowledge retrieval system can use unidirectionally linked custom field types, either standalone or as part of custom field types containing other properties, to generate relationship types that relate entity types. In one embodiment, the knowledge retrieval system includes system-defined entity types and relationships based on customer feedback and observations. For example, the knowledge retrieval system may be configured to provide information regarding exemplary analyses including, but not limited to:What motivates customers to add entities to a knowledge retrieval system? When information needs to be an entity type rather than a property of another entity type? What entity types do various merchant systems generate, use, and store in knowledge retrieval systems? How relationship types are used in knowledge retrieval systems? Whether relationship types can be converted to entity types to contain additional data or whether relationship types are properties of entity types? What data merchant systems store in relation to what customers want to store about their entities? How merchant systems use entity types in downstream end-user services.

[0076] In one embodiment, custom entity types may be used to enable storage of data in a knowledge retrieval system and to enable a merchant system to use the custom entity types with one or more other exemplary systems and functions, such as knowledge pages, consulting pages, knowledge searches, listings, reviews and analytics, etc.

[0077] In one embodiment, the knowledge retrieval system can provide compatibility between custom entity types and built-in entity types. For example, if a merchant system user adds a custom entity type named "Vehicle" and the knowledge retrieval system subsequently adds a built-in type for "Vehicle," the knowledge retrieval system can allow the merchant system to migrate or utilize the functionality of the built-in type. In one embodiment, the knowledge retrieval system allows a merchant system to manage which entity types are enabled in its account. In one embodiment, the knowledge retrieval system can provide customers with recommended custom entity types based on historical data about how other merchant systems have created custom entity types. In some embodiments, a merchant system can create custom records, such as records related to limited-time offers, dealer groups, or product launches, to reflect everything that makes its brand unique. In one embodiment, in response to adding a new employee or creating a new special offer, the knowledge retrieval system can update all corresponding relationships. In one embodiment, the knowledge retrieval system can update one or more connected search experiences in response to changes in information provided by the merchant system.

[0078] In some embodiments, a merchant system may create a custom entity type that is not supported by one or more third-party websites or applications. In some embodiments, the knowledge retrieval system may review the custom entity type requested by the merchant system and recommend an alternative built-in entity type that is supported by one or more third-party websites or applications. In such cases, the merchant system may choose to migrate all data from the custom entity type to a built-in entity type and synchronize the data and entity type with the third-party websites and applications. In other embodiments, the knowledge retrieval system may migrate all data from the custom entity type to a supported built-in entity type and synchronize the associated data with the third-party websites or applications.

[0079] In other embodiments, the knowledge retrieval system may modify the data structure of a third-party website or application to enable support for custom entity types. In such embodiments, the custom entity types may be "locked" so that the third-party website cannot modify the structure. In other embodiments, the knowledge retrieval system evaluates entity types for a particular merchant system and recommends those entity types to similar merchant systems. In some embodiments, recommendations may be made based on recommendation rules that are created to enable sending notifications to applicable merchant users who manage such data on behalf of the merchant systems.

[0080] In one embodiment, the knowledge retrieval system provides custom entity type functionality that allows a merchant system to create, update, or delete one or more custom entity types. In one embodiment, the knowledge retrieval system allows a merchant system to view, enable, or disable entity types within a merchant system account.

[0081] According to embodiments of the present disclosure, the knowledge retrieval system can provide custom entity types specific to a merchant account or subaccount. In one embodiment, the merchant system can define one or more fields associated with the custom entity type. In one embodiment, the custom entity type can be available via one or more services (e.g., information editing, approvals, scheduled updates, templates, uploads, exports, knowledge retrieval system API, live API, ML profiles, custom goals, advanced filters, etc.).

[0082] In one embodiment, the knowledge retrieval system may provide a field registry configured to allow entity types to be defined by specific categories (e.g., by business, etc.). As an example, fields may be processed based on subscription features such as publisher fields. In one embodiment, the knowledge retrieval system provides the flexibility for users to support custom field types and the ability to make custom fields available to subaccounts.

[0083] In one embodiment, the knowledge retrieval system provides information schema management and entity type management. In one embodiment, the information schema is managed by establishing entity type properties such that each entity type (e.g., built-in entity types, custom entity types, etc.) has a corresponding set of properties. In one embodiment, for custom entity types, the merchant system can control one or more properties, such as, for example, the following exemplary properties: name, API name, description, entity type group, availability to subaccounts, entity type icon, merchant system data, representation of the entity type in tabular form, fields, etc.

[0084] In one embodiment, one or more "fields" associated with a custom entity type may be defined by a merchant system using the knowledge retrieval system. In one embodiment, after creating an entity type, the merchant system displays a list of available fields and allows the merchant to select one or more fields to add to the entity type. For example, by default, an entity type may include an entity type identifier (ID) field and a name field.

[0085] In one embodiment, for additional fields of a custom entity type, the merchant system can perform one or more of the following actions: 1) specify whether the field is required for that type (e.g., a centralized concept of required fields across all interfaces may be adopted), 2) specify whether the field is visible on the "Add" screen.

[0086] In one embodiment, the merchant system may display and enable or disable available entity types in an account. In one embodiment, the following aspects may be considered: 1) determining whether the entity type is configurable by the merchant system (e.g., determining whether a merchant user can view and enable or disable it in the Manage Entity Types table); 2) if configurable, determining whether the entity type is available or disabled for the account (e.g., determining whether the merchant system will add instances of the entity type); and 3) if enabled, determining which entity type is the primary type for the account (e.g., determining the default type).

[0087] In one embodiment, if an entity type is "configurable," the merchant system can enable or disable that type in the knowledge retrieval system. In one embodiment, there is a global setting for "configurable" (with a "no" indication used for entity types under test), which can be managed for specific businesses (using inheritance for subaccounts, if applicable), allowing the knowledge retrieval system to "on" the entity type for specific accounts for testing and hide the entity type in the merchant system for specific instances.

[0088] In one embodiment, the merchant system can delete a custom entity type such that the "Customer Preference" field is updated to "No" (e.g., if there are no unarchived instances of the type and the type is disabled).

[0089] In one embodiment, for customer-configurable entity types, the merchant system can enable or disable the type in the knowledge retrieval system. In one embodiment, if entity types are enabled, each account can have a primary type. In one embodiment, primary types can be set for subaccounts.

[0090] In one embodiment, the knowledge retrieval system can utilize the entity types that are created and enabled to perform various operations and functions, including, for example, filtering based on entity type, generating entity type templates, exporting entity types, uploading custom entity types, selecting entity types, creating web pages for entity types, searching for data related to entity types, adding user roles associated with entity types, generating analytics for entity types, generating activity reports for entity types, generating entity type trees organized by groups, and the like.

[0091] According to embodiments of the present disclosure, natural language processing may be performed using a knowledge graph, which may be generated by the entity type manager 110. In one embodiment, the knowledge retrieval system may suggest results in a drop-down list based on information stored in a knowledge graph associated with a merchant system. For example, an end user may perform a search query for insurance agents who speak a particular language. When the end user searches for "agents who speak," a drop-down list containing languages ​​added to the knowledge graph by the merchant system is displayed. In one embodiment, the knowledge retrieval system returns "answers" (e.g., search results that respond to the search query) in the drop-down list based on information stored in a knowledge graph associated with the merchant.

[0092] As an example, a merchant system may update holiday hours in its knowledge graph (e.g., New Year's Day hours from 12:00 to 15:00). When an end-user customer initiates a search on December 30th, a search for "holiday hours" will be initiated. The result "New Year's Day hours are from 12:00 to 15:00" may be returned in a drop-down list so that the end user does not have to perform a full search (e.g., by interacting with or clicking a "Search" button or link).

[0093] In another embodiment, search results may be returned in the form of a drop-down list. As an example, a chat or structured map may be returned, which may not require a "click" on a search link.

[0094] In one embodiment, the knowledge retrieval system can use analytics from the search data to enhance notifications or "knowledge fine-tuning." In one embodiment, the analytics are displayed and used to provide recommendations in the knowledge retrieval system, allowing the merchant system to set recommendation rules based on the recommendations provided by the knowledge retrieval system. In one embodiment, an end user can perform a search on a merchant website, for example, looking for physician specialties for a particular office of the merchant. In one example, the requested information may not exist in a data graph associated with the merchant system. In this example, the knowledge retrieval system can use the analytics to recommend updates to that information and / or create notification rules that prompt other users (e.g., other offices associated with the merchant system) to update their "physician specialty" information. In one embodiment, the knowledge retrieval system can create notification rules based on the analytics and send them to users responsible for the information (e.g., merchant users, etc.).

[0095] In another example, an end user may search for doctors in a particular location who specialize in nutrition. In this example, if the information is not identified, a notification rule may be created to notify platform users (e.g., merchant users) in a particular location to update the information in their account.

[0096] FIG. 11 illustrates an exemplary computer system 1100 that operates according to some embodiments of the present disclosure. In FIG. 11, a diagrammatic representation of a machine is shown in the exemplary form of a computer system 1100 that includes a set of instructions for causing the machine to perform any one or more of the methodologies described herein. In alternative embodiments, the machine 1100 may be connected (e.g., networked) to other machines in a local area network (LAN), an intranet, an extranet, or the Internet. The machine 1100 may operate in the capacity of a server or client machine in a client-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a mobile phone, a web appliance, a server, a network router, a switch, or a bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by the machine 1100. Furthermore, although only a single machine is illustrated, the term "machine" is intended to include any collection of machines that individually or jointly execute a set (or sets) of instructions to perform any one or more of the methodologies described herein.

[0097] The exemplary computer system 1100 may include a processing device 1102 (also referred to as a processor or CPU), a main memory 1104 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM), etc.), a static memory 1106 (e.g., flash memory, static random access memory (SRAM), etc.), and a secondary memory (e.g., data storage device 1116, etc.), which may communicate with each other via a bus 1130.

[0098] The processing device 1102 represents one or more general-purpose processing devices, such as a microprocessor, a central processing device, or the like. More specifically, the processing device may be a complex instruction set computing (CISC) microprocessor, a reduced instruction set computer (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, or a processor implementing another instruction set or a processor implementing a combination of instruction sets. The processing device 1102 may also be one or more application-specific processing devices, such as an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a digital signal processor (DSP), a network processor, or the like. The processing device 1102 is configured to execute the knowledge retrieval system 100, which performs the operations and steps described herein. For example, the processing device 1102 may be configured to execute instructions implementing the processes and methods described herein to support the knowledge retrieval system 100 in accordance with one or more aspects of the present disclosure.

[0099] The exemplary computer system 1100 may further include a network interface device 1122 that may be communicatively coupled to a network 1125. The exemplary computer system 1100 may further include a video display 1110 (e.g., a liquid crystal display (LCD), touch screen, or cathode ray tube (CRT)), an alphanumeric input device 1112 (e.g., a keyboard, etc.), a cursor control device 1114 (e.g., a mouse, etc.), and an audio signal generating device 1120 (e.g., a speaker, etc.).

[0100] The data storage device 1116 may include a computer-readable storage medium (more specifically, a non-transitory computer-readable storage medium) 1124 on which one or more sets of executable instructions 1126 are stored. In accordance with one or more aspects of the present disclosure, the executable instructions 1126 may include executable instructions that encode various functions of the knowledge retrieval system 100 in accordance with one or more aspects of the present disclosure.

[0101] The executable instructions 1126 may also reside, completely or at least partially, within the main memory 1100 and / or within the processing device 1102 during execution by the exemplary computer system 1100, the main memory 1104 and the processing device 1102 constituting computer-readable storage media. The executable instructions 1126 may also be transmitted or received over a network via the network interface device 1122.

[0102] Although the computer-readable storage medium 1124 is shown as a single medium, the term "computer-readable storage medium" should be interpreted to include a single medium or multiple media. The term "computer-readable storage medium" should also be interpreted to include any medium that can store or encode a set of instructions for execution by a machine that cause the machine to perform any one or more of the methodologies described herein. Thus, the term "computer-readable storage medium" includes, but is not limited to, solid-state memory, optical media, and magnetic media.

[0103] Some portions of the above detailed descriptions are presented in terms of algorithms and symbolic representations of operations on data bits in a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art, and an algorithm is here conceived to be a self-consistent sequence of steps leading to a desired result. The steps require physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

[0104] It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless otherwise indicated, as will be apparent from the following description, discussions utilizing terms such as "identify," "determine," "analyze," "select," "receive," "present," "generate," "derive," "provide," and the like throughout the description will be understood to refer to operations and processes of a computer system or similar electronic computing device that manipulates and transforms data represented as physical (electronic) quantities in the computer system's registers and memory into other data represented as physical quantities in the computer system's memory or registers or other data represented as physical quantities in other information storage, transmission, or display devices.

[0105] Examples of the disclosure also relate to apparatus for performing the methods described herein. This apparatus may be specially constructed for the required purposes, or it may be a general-purpose computer system selectively programmed by a computer program stored in the computer system. Such computer program may be stored on any type of computer-readable storage medium, such as a disk, including but not limited to optical disks, CD-ROMs and magneto-optical disks, read-only memory (ROM), random-access memory (RAM), EPROM, EEPROM, magnetic disk storage media, optical storage media, flash memory devices, other types of machine-accessible storage media, or any type of medium suitable for storing electronic instructions, each coupled to a computer system bus.

[0106] The methods and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems appears as described below. Moreover, the scope of the disclosure is not limited to any particular programming language. It will be understood that a variety of programming languages ​​can be used to implement the teachings of the disclosure.

[0107] It should be understood that the above description is intended to be illustrative, and not restrictive. Many other embodiments will be apparent to those skilled in the art upon reading and understanding the above description. While the present disclosure describes particular embodiments, it should be understood that the disclosed systems and methods are not limited to the embodiments described herein, but may be practiced with modification within the scope of the appended claims. Accordingly, the specification and drawings should be regarded in an illustrative rather than a restrictive sense. The scope of the disclosure should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

Claims

1. creating a first entity type in a data graph associated with the merchant system, the first entity type including a first data field that stores a first data value corresponding to the merchant system; creating a second entity type in the data graph, the second entity type including a second data field storing a second data value corresponding to the merchant system; establishing, by a processing device, a first relationship type of a plurality of relationship types based on a selection from a merchant system, the first relationship type defining a relationship between the first entity type and the second entity type; generating a first update to the first data value of the first entity type; determining, based on a first rule associated with the first relationship type, that the second entity type should be updated in light of the first update; generating second updates to second data values ​​of a second entity type in consideration of said determining step; storing the first update of the first entity type and the second update of the second entity type in the data graph.

2. receiving a query regarding the merchant system; 2. The method of claim 1, further comprising searching the first entity type and the second entity type in response to the query.

3. 3. The method of claim 2, further comprising generating a response to the query that includes at least one of the first update to the first data value or the second update to the second data value.

4. The method of claim 1 , further comprising the step of delivering the first update and the second update to a provider system.

5. The method of claim 1 , further comprising receiving the first update from the merchant system.

6. 10. The method of claim 1, wherein one or more of the first update or the second update is provided to an end-user system in response to a query from the end-user system.

7. establishing a plurality of associations between the first entity type and a plurality of additional entity types; and updating the plurality of additional entity types in response to the first update to the first data value of the first entity type, taking into account the plurality of relationships.

8. a memory for storing instructions; a processing device operably coupled to the memory, the processing device comprising: creating a first entity type in a data graph associated with the merchant system, the first entity type including a first data field that stores a first data value corresponding to the merchant system; creating a second entity type in the data graph, the second entity type including a second data field storing a second data value corresponding to the merchant system; establishing a first relationship type of a plurality of relationship types based on a selection from a merchant system, the first relationship type defining a relationship between the first entity type and the second entity type; generating a first update to the first data value of the first entity type; determining, based on a first rule associated with the first relationship type, that the second entity type should be updated in light of the first update; generating second updates to second data values ​​of a second entity type in consideration of said determining step; storing the first update of the first entity type and the second update of the second entity type in the data graph; A system that performs operations including:

9. The operation is receiving a query regarding the merchant system; 9. The system of claim 8, further comprising searching the first entity type and the second entity type in response to the query.

10. 10. The system of claim 9, wherein the operations further comprise generating a response to the query that includes at least one of the first update to the first data value or the second update to the second data value.

11. The system of claim 8 , wherein the operations further comprise delivering the first update and the second update to a provider system.

12. The system of claim 8 , wherein the operations further comprise receiving the first update from the merchant system.

13. 10. The system of claim 8, wherein one or more of the first update or the second update is provided to an end-user system in response to a query from the end-user system.

14. A non-transitory computer-readable storage medium containing instructions that, when executed by a processing device, creating a first entity type in a data graph associated with the merchant system, the first entity type including a first data field that stores a first data value corresponding to the merchant system; creating a second entity type in the data graph, the second entity type including a second data field storing a second data value corresponding to the merchant system; establishing a first relationship type of a plurality of relationship types based on a selection from a merchant system, the first relationship type defining a relationship between the first entity type and the second entity type; generating a first update to the first data value of the first entity type; determining, based on a first rule associated with the first relationship type, that the second entity type should be updated in light of the first update; generating second updates to second data values ​​of a second entity type in consideration of said determining step; storing the first update of the first entity type and the second update of the second entity type in the data graph; 1. A non-transitory computer-readable storage medium for performing operations including:

15. The operation is receiving a query regarding the merchant system; and searching the first entity type and the second entity type in response to the query.

16. 16. The computer-readable storage medium of claim 15, wherein the operations further comprise generating a response to the query that includes at least one of the first update to the first data value or the second update to the second data value.

17. The computer-readable storage medium of claim 14 , wherein the operations further comprise delivering the first update and the second update to a provider system.

18. 15. The computer-readable storage medium of claim 14, wherein one or more of the first update or the second update is provided to an end-user system in response to a query from the end-user system.

19. establishing a plurality of associations between the first entity type and a plurality of additional entity types; and updating the plurality of additional entity types in response to the first update to the first data value of the first entity type, taking into account the plurality of associations.

Images