Patent Application
20120124061
Recent changes in technology have generated multiple platforms for publisher created applications or “apps.” For example, iPhone® (manufactured by Apple, Inc. in Cupertino, Calif.), iPad® (manufactured by Apple, Inc. in Cupertino, Calif.), Android® (manufactured by Google. in Mountain View, Calif.), Facebook® (manufactured by Facebook in Palo Alto, Calif.), Windows Mobile® (manufactured by Microsoft Corporation in Redmond, Wash.), X-Box® (manufactured by Microsoft, Inc. in Redmond, Wash.), and others are capable of installing and running apps. For the most part, these apps are specific to the platform for which they were designed (e.g., an iPad® app will not run on an Android® device and vice versa). Each platform operates an app store or marketplace of their own apps, etc.
These new technologies offer app publishers many additional opportunities for reward, and have become a catalyst for explosive growth in application development. The result is an organically grown critical mass of applications in the ecosystem. However, current app stores do not provide an effective way to search this ever growing mass of apps.
An application search system allows users to search for apps. The application search system may maintain an index of apps available in one or more app databases. The app index includes parameters, such as features and/or content of the app. When a user submits a query, the system may derive contextual information pertaining to a user device used to submit the query, applications that are installed on a particular user device and/or usage information for the installed apps. The system then may determine one or more apps relevant to the search query. In one example, depending on the contextual information derived, the system may provide an entry point to access a particular application at a task level, may prompt the user to install the application, or may provide a web result related to the particular app.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
The detailed description refers to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The use of the same reference numbers in different figures indicates similar or identical items.
Today, individual application stores provide marketplace specific discovery tools, however, they are limited to searching a particular application or “app” and linking only to the app from the marketplace's user interface or “UI”.
As discussed above, there are many limitations to this approach. For instance, the user must enter the application store with the intent of “finding an app” vs. a more natural intent to “complete a task.” Current app stores' discovery solutions are device specific and generally provide rudimentary discovery capabilities based on user provided parameters and keywords. Because the user's intent is often to “complete a task,” neither the device nor the associated application store takes into account whether an already installed app will meet the user's need. Moreover, there is currently no way for users to search across multiple app stores and/or the web to obtain the most relevant results from all of these sources simultaneously.
The search architecture described below provides the user with a richer and more useful application search result than has previously been available. From a high-level, given a query, the search provider can infer a task the user is trying to perform. The search provider can also identify if application-based solutions are available and appropriate and rank the available and appropriate applications. Finally, the search provider can check to see if any of the ranked applications are already installed on a user's device and surface a search result such that if the application is not installed, the user is provided a link to the appropriate application store so it can be installed. If the application is already installed, the user can be provided with an entry point to access the app and, more specifically, a feature of the app relevant to the task the user desires to perform. In other words, the user may be taken directly to a specific feature level within the application (e.g., launch an app and initiate a specific action within the app). In one specific example, the system might provide a link to launch a previously installed movie app and to display movie listings for nearby theaters.
The search architecture described below may also include a domain name system that provides a registry of apps according to a protocol that may be used in conjunction with the application search architecture to provide better search results. The protocol may be a part of an index entry in the app database or the app index component and may replace or supplement the familiar http protocol (hypertext transfer protocol) used to transfer and format text and images.
The foregoing explanation provides a brief overview of the application search architecture, however, a more detailed description follows. An illustrative architecture is described, followed by a description of illustrative processes.
The installed apps 110 include any apps currently installed on the searcher computing device 104. The installed apps 110 are updated as more apps are installed on the searcher computing device 104 such that each time a new search is initiated, a list of installed apps on the searcher computing device 104 is current.
The device ID 112 is a unique identifier for the searcher computing device 104. The device ID 112 may be used to identify the searcher computing device 104 as a device authorized to access, update and/or purchase a particular app. In one example, the device ID 112 comprises the Media Access Control (MAC) address. However, any other unique identifier could be used in other examples.
Content 114 may be in the form of audio or video content as well as text, images or graphical representations. Content 114 may also include any other type of content that is useful to the searcher 102, the particular application or others who may interact with the searcher computing device 104 and is authorized to access the content 114. For example, content 114 may be reviews associated with a particular establishment or maps indicating the location of a particular establishment.
Usage information 116 may include usage of the application by one or more particular users, popularity of the application and social ratings of the application in addition to any other data accumulated for a particular application. The usage of the application may include such items as the amount of time an app is used, the number of times the app is accessed, the features within the app that are accessed, popularity of the application and social ratings of the application in addition to any other data accumulated for a particular app. The usage information for installed applications on the particular device may also include additional indicators for a search provider's dynamic ranking. For example, a user may use the UrbanSpoon™ application more often than the Yelp® application when looking for local restaurants. This information is useful in ranking the applications for that device and user.
Browser 118 may be any commercially available browser such as Bing® from Microsoft Corporation in Redmond, Wash. or Google® from Google in Mountain View, Calif.
App client 120 provides for management of the installed apps 110 and the various information contained on the searcher computing device 104. Searcher computing device 104 contains contextual information, app information and usage information for the installed apps 110.
The installed apps 110, device ID 112 and usage information 116 are also collectively referred to as contextual information. Contextual information is used to identify information related to the device and to the searcher to assist in the search. As will be discussed further below, content 114 forms a portion of information called parameters. Parameters are features and/or content within an app and include both the various functions to perform a task and also content that is the object of the task. Content 114 may include items such as a map, a review of an establishment or some other type of content relating to the task.
Searcher computing device 104 is connected to a network 122. Network 122 may include one or more wired and/or wireless networks. Network 122 is also connected to other services and applications that interact with the searcher computing device 104.
App search service 124 is one such service that interacts with searcher computing device 104. App search service 124 includes one or more processors 126, memory 128, app index component 130, ranking component 132, protocol component 134, presentation component 136, context information 138, inference module 140 and domain name system 141.
App index component 130 accesses one or more app databases 142(1) . . . 142(N) (collectively “142”). App databases 142 include apps available from one or more app stores and/or different app publishers. In some examples, applications from various sources or application stores are all aggregated and/or searchable across stores in order to obtain results for all different types of devices across all the different applications and different stores. This may be accomplished, in one example, by standardizing protocols across all applications and encouraging broad use by application developers. One such protocol described herein is an app transfer protocol, which is described below with reference to
Ranking component 132 determines the relevance and the ranking of an application in relation to other applications as well as in relation to other traditional web results. Traditional or standard web results include web results that do not directly access a feature of an application or the application itself. This would include such results as the listing one obtains from using the Bing® search engine, that includes web sites and online retail stores, etc. The web result may also include descriptions of apps (e.g., those not available for a client device of the user).
The protocol component 134 uses the information from the app index component 130, the ranking component 132 and the parameters and contextual information from the searcher computing device 104 to create a protocol to call the application. As discussed above, the contextual information includes installed apps 110, device ID 112 and usage information 116. Parameters include the content 114 and functions to perform tasks within an app.
The protocol component 134 is used to interpret app data and commands during indexing and searching. The interpretation is sufficiently detailed to call an application to a specific feature or task level within the application. For instance, from the user's query and the information described above, the protocol component 134 may conclude that the user wants to see reviews for a particular restaurant. Instead of calling the application at a top level so the home page is called, thus forcing the user to navigate through the application to get to the reviews, the protocol would call the application to the specific feature, which, in this example, is reviews for the particular restaurant in which the user is interested. The protocol component is more fully described in
The presentation component 136 takes the results from the protocol component 134 and displays them in a presentable form to the searcher 102. The results may be presented in different ways depending on the information gathered from the particular device. For instance, it may be that an application for a particular user inquiry is not available. Another possibility is that an application is identified but is not installed on the device. Finally, in the event the application is available, the user is taken to the specific feature within the application that best satisfies the search query.
The presentation component 134 takes into account these different possibilities and presents the searcher 102 with options depending on the results. For instance, if no application exists, the searcher 102 may be presented with standard web results that do not take the searcher to a feature within an app.
In the second possibility, the searcher 102 may be presented with the option to install the identified application when an application is available but not installed on the user's device. This option may be in addition to or instead of presentation of the standard web results. If the searcher 102 selects an option to install the application, the application is installed and once installed; the user 102 may be taken to the specific task in the application that is identified in the application search. The searcher 102 may also decide not to install the application and instead select one of the standard web results.
Finally, in the event an application is identified and it is already installed on the device, the searcher 102 will be taken to the specific task within the application as discussed herein.
The inference module 140 receives both the query and the contextual information from the searcher computing device 104. The contextual information discovered for the searcher computing device 104 may include the type of device being used, an inventory of applications currently installed on the device and/or usage information for the installed applications. The usage information for installed applications on the particular device provides additional indicators for a search provider's dynamic ranking. The information from the inference module 140 is accessed by the ranking component 132 to rank available apps associated with the information from the inference module 140.
The domain name system 141 may provide a registry of apps according to a protocol. The domain name system 141 is optional and, when provided, may be used in the search architecture 100 to improve access to particular features within an application and to improve search across app stores. In the event the domain name system 141 is used, the protocol may be part of an index entry in the app database 142 or the app index component 130. As such, the domain name system 141 may be analogous to the domain name server (DNS) technology employed to direct browser requests for uniform resource locators (URL) on the Internet. Accordingly, the domain name system 141 supplements and/or replaces DNS technology related to apps. In particular, the protocol defined by the domain name system 141 provides enhanced methods of locating, operating, managing, downloading and installing of applications on devices. The domain name system 141 may provide better search, management, transfer, etc., of applications. Accordingly, the protocol may replace or supplement the familiar http protocol (hypertext transfer protocol) used to transfer and format text and images.
The protocol could be standardized across all applications (e.g., the “apps” used by smart phones, personal computers, gaming consoles, TVs and other devices) and could encourage wide adoption by developers. In other examples, the protocol may be applied across less than all app platforms/types. The protocol may be managed in part by the domain name system 141, and may be invoked by identifying or indicating the following aspects: a protocol handler, a domain and parameters.
As described above, the application search architecture 100 is implemented within a computing system environment. For instance, the components of a particular computing system within the environment can include, but are not limited to, one or more processors (e.g., any of microprocessors, controllers, and the like), a system memory, and a system bus that couples the various system components. The one or more processors process various computer executable instructions to control the operation of the computing system and to communicate with other electronic and computing devices. The system bus represents any number of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures.
The computing system may be implemented using any form of computer-readable media. Computer-readable media may include, for example, computer storage media and communications media. Computer storage media is configured to store data on a physical memory storage device, while communications media is not configured to store data on a physical memory storage device.
Computer storage media includes volatile and non-volatile, 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. Computer storage media includes, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission memory medium that can be used to store information for access by a computing device. Computer readable storage media does of include modulated data signals, carrier waves or other communication media.
In contrast, communication media may embody computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave, or other transport mechanism.
The presentation component 136 determines the final result to be presented on the device 104. The presentation component 136 uses the information aggregated from the ranking component 132 to determine whether an application in response to the search query exists in operation 202. If an application does not exist, then web results are presented to the user in operation 204. If an application does exist, operation 206 determines whether an identified application is installed on the device 104. If the application is not installed, the application is installed and presented to the user at a specific feature level along with or without the web results in operation 208. The system may also be set up to ask the user whether or not to install the application before the system installs the application. In one example, the service will provide opt-in and/or opt-out functionality. For example, in one instance, prior to an application being installed, the user will be notified and given the option to opt-out. Further, in one aspect, enhanced security measures will be employed in order to protect the user and/or application data.
If the application is installed, the application is launched at a specific entry point to a task or feature of the application in response to the search query and presented to the user with or without the web results in operation 210.
Referring to
The protocol could be standardized across all applications (e.g., the “apps” used by smart phones, personal computers, tablet/pad devices, gaming consoles, TVs and other devices) and could encourage wide adoption by developers. In other examples, the protocol may be applied across less than all app platform/types. The protocol may be managed in part by the domain name system 300, and may be invoked by identifying or indicating the following aspects: the protocol 402, a domain 404 and parameters 406.
In one example, the protocol 402 may be identified by a protocol handler; for example, “app://”. Accordingly, a name such as “app://” may identify a protocol to replace the familiar http:// protocol handler. The domain and/or top level domain 404 may be identified (strictly for purposes of example only, and not as a required feature) as “microsoft.bing,” optionally with a top level domain such as “.com” or “.org.” The app DNS system may be administered by an authority analogous to Internet Corporation for Assigned Names and Numbers (ICANN). This is by way of example only, and the example would allow a user to access and/or manage an application associated with the Bing® service provided by Microsoft®. In a further example, the domain level 404 could be indicated by “corporation.department” or similar, as required to indicate a particular application or resource. The parameters 406 may include, by way of example and not limitation, one or more search term(s) used to find an application, content associated with the app from a device or other locations, input variable values for use by a specifically identified application, a command to an application and/or to an application store, server or host of the application. A generic protocol may be generated in the form of app://corporation.application/parameters. The application portion and/or the parameters portion may define a version of an app and/or a platform on which the app is to run.
Consequently, in one specific example, the protocol architecture 141 may read app://microsoft.bing/restaurant/ilikesushi.com/bellevue/reviews in response to a query that results in the user's intent being restaurant reviews for a restaurant called I Like Sushi in Bellevue, Wash. and employing the Bing® app from Microsoft Corporation.
The query 604 and the contextual information 606 is used by inferred task(s) 608 to determine an entry point or task within an app to access in response to the query 604. The inferred task(s) 608 includes general information about each installed application on the device 602 and other more detailed information, such as reservations, check-in information and reviews. These are examples that may apply to a restaurant such as in the current example. Other applications may include many different features depending on the focus of the application.
The inferred task 608 and contextual information 606 are used in the architecture to rank applications in response to the query 604 in the application index 610. In this example, the application index 610 has identified several applications including Facebook 612, Maps 614, OpenTable 616 and Yelp 618. The architecture uses the query 604 and the contextual information 606 and the inferred tasks 608 to rank the applications and direct the user to a specific feature level within the chosen application as the result of the search. In this example, the ranking has identified Yelp® as the highest ranked app and Reviews as the inferred task the user desires to access. Consequently, the user is taken directly to the reviews section in Yelp® so the user can either write a review or read the existing reviews.
This is very helpful to the user because in the past, search results simply identified an application and took the user to the application. The user then had to navigate through the application to find the particular feature the user wanted. This mechanism greatly reduces the user's efforts.
Operation 706 determines a plurality of information for a particular user device. The information discovered for a particular device includes the device being used; an inventory of applications currently installed on the device and usage information for the installed applications and the usage information for installed applications on the particular device provides additional indicators for a search provider's dynamic ranking.
In operation 708, applications are ranked in relation to a plurality of other applications and in relation to a plurality of web results. Web results are traditional or standard web results that include web results that are not specifically directed to an entry point in an application.
A protocol is initiated to implement a user's intent by creating a result that accesses a particular application at a task level in operation 710. The protocol is sufficiently detailed to call an application to a specific task within the application. The query and the data from operations 704, 706 and 708 are used to configure the protocol.
The result is presented to the client device in operation 712. The result is typically directed to a specific task within an application installed on the client device. However, this operation may also include offering other options in the event the application is not available or is not installed on the user's device.
Operation 806 determines one or more applications relevant to the search query. As stated earlier, the architecture will use the ranking component and the query, contextual information and app index information to arrive at the one or more applications determined to be relevant.
In operation 808, an action to take is determined based, at least in part, on the contextual information. The contextual information is important in determining the intent of the user in connection with the search query.
The result is presented to the user in operation 810. The result is typically directed to a specific task or feature within an application installed on the user device. However, this operation may also include offering other options in the event the application is not available or is not installed on the user's device.
Crawling an application database to generate application information for each application is conducted in operation 906. The information obtained from crawling the application database is used in constructing the index of the applications in the application database.
In operation 908, the application information is indexed for each application according to an application transfer protocol. The application transfer protocol may be in the generic form of app://company.application/one or more parameters.
One or more applications are determined to be relevant to the search query in operation 910 and the application transfer protocol is implemented in operation 912. The result is presented to the client device in operation 914.
In operation 1006, each application is dynamically ranked utilizing the parameters. One or more applications are determined to be relevant to the search query and the dynamic ranking in operation 1008. The results are presented to the client device in operation 1010.
Although the subject matter herein has been described in language specific to structural features and/or methodological operations, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or operations described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
