RU2774319C2 - Deep links for native applications - Google Patents

Abstract

FIELD: communication.

SUBSTANCE: invention relates to the creation of deep links for native applications. Data defining a pattern of a unified resource identifier (hereinafter – URI) for a native application is received, including a host name and a path prefix, while URI pattern defines a corresponding issuer for this native application, a set of URI is generated from URI pattern for the mentioned native application, wherein each URI includes a host name and a path prefix attached to this host name; a deep link for the mentioned native application is generated for URI of the mentioned set of URI, wherein the deep link includes URI and additional data that is attached to this URI; and the mentioned set of URI is saved to a data storage.

EFFECT: ensuring automatic indexing of deep links for native applications.

15 cl, 4 dwg

Description

Priority Statement

This 35 U.S.C. 119(e) application claims priority to U.S. Patent Application No. 62/017.193, filed June 25, 2014, the contents of which are hereby incorporated by reference in their entirety.

State of the art

The Internet provides access to a wide variety of information. For example, digital image files, video and/or audio files, and web page resources on specific topics or specific print messages are available over the Internet. As for web page resources, many of these resources are designed to facilitate specific functions such as banking, hotel reservations, shopping, etc., or to provide structured information such as electronic encyclopedias, databases of films, etc.

There are a number of search engines available for identifying specific web page resources available on the Internet. With the advent of tablets and smartphones, native applications that provide the same functionality as provided by the use of web page resources are now being provided in large numbers.

The information needs of the user can then be met by providing search results that install either one of the specific web page resources or a native application (or both) that provides the same functionality that is provided through the use of web resources. pages, or present the same or very similar information as a web page resource.

The essence of the invention

The present invention relates to deep linking of native applications, and more particularly to systems and methods for automatically generating native application deep links.

In general, one aspect of the invention set forth herein can be implemented in methods that include the steps of receiving publisher binding data for native applications that define, for each native application, an associated publisher for the native application; for each native application in the set of native applications, determining, based on the publisher binding data, whether it is associated with a publisher that provides content addressed by the URIs defined for the native application; only for native apps that are identified as being associated with a publisher that provides content addressed by URIs defined for the native app: selecting a URI based on the native app URI pattern, indexing content accessed by the native app URI in an index that allows searching by a search engine. Other embodiments of this aspect include related systems, apparatus, and computer programs capable of performing the actions of the methods encoded on computer storage devices.

Yet another aspect of the invention set forth herein can be implemented in methods that include the steps of defining a Uniform Resource Identifier (URI) template for a native application; instantiating the native application and selecting a first URI based on the URI template to generate an application page in the native application display environment; indexing the application page data on the application page in an index that is searchable by a search engine; iteratively processing the linked application pages for the native application until a stop event occurs, the iterative processing including, for each iteration, determining, from the application page, outgoing URIs, including those on the first page of the application; selecting one or more of the outgoing URIs to generate one or more next application pages in the native application display environment; indexing application page data for each of those one or more next application pages in the index. Other embodiments of this aspect include related systems, apparatus, and computer programs capable of performing the actions of the methods encoded on computer storage devices.

Specific embodiments of the invention set forth in this description, can be implemented in such a way as to realize one or more of the following advantages. Deep link generation makes it easier for app developers to participate in the indexing of native apps, which in turn helps manage the usage and re-engagement of their apps. The system also lowers the barrier to participation.

Details of one or more embodiments of the invention set forth in this specification are explained in the accompanying drawings and the description below. Other features, aspects and advantages of the invention will become apparent from the description, drawings and claims.

Brief description of the drawings

Fig. 1 is a block diagram of an example environment in which deep links are generated for native applications.

Fig. 2 is a block diagram of a traversal and indexing system.

Fig. 3 is a flow diagram of an example process for generating deep links for native applications.

Fig. 4 is a flow diagram of another example process for generating deep links for native applications.

Like reference numerals and designations throughout the various drawings refer to like elements.

Detailed description

The system provides search results for native applications. In this context, the native application operates independently of the browser program of the user device. A native application is an application specifically designed to run on a specific user device operating system and native firmware, rather than in a browser. Native apps, however, are distinct from browsers, browser-based apps, and browser-rendered resources. The latter requires all or at least some of the elements or commands to be downloaded from the web server each time they are instantiated or rendered. In addition, browser-based applications and browser-rendered resources can be handled by all web-enabled mobile devices in a browser and are therefore not operating system-specific as they are native applications. Also, in this context, a native application search result is a search result that matches a particular native application and that, when selected, invokes the particular native application.

Examples of a native application include applications for creating text documents, editing photos, playing music, interacting with a remote banking system, and so on. Mobile native apps are designed to run on mobile devices such as smartphones, tablets, and so on. Native web applications are designed to run within (both visually and functionally) web browser software. At a very high level, native applications, or simply "apps", provide the user with access to content and/or functionality.

Internet search engines provide the ability to search an indexed collection of web pages that exist on the Internet. A typical search engine provides, in response to a query, a list of results matching the query, often with hyperlinks to allow the user to quickly navigate to the result of interest. The user may receive a referenced result, thereby providing the web page(s) containing content about the celebrity, product, business, etc. Links can be to the "home page" of the site (for example, to the search start page for a site that collects cooking information such as recipes) or to a "content page" that a user can access when navigating away from the site's home page. (e.g. a specific recipe on a site with cooking information). Links to content pages, as opposed to home pages, are referred to as "deep linking" (and the process of crawling, indexing, and serving said content pages in a similar manner is referred to as "deep linking").

The ability to navigate by navigating to a page, and the accessibility of the content and functionality that a page provides, is due in part to the nature of the page being published. For example, some pages may contain dynamic content (such as asynchronous JavaScript and XML (AJAX), Adobe Flash, etc.) that is difficult or impossible to crawl and retrieve. Consequently, these pages may not be available in response to a search, the user may not be able to save the page as a bookmark or the like, and navigating the page using browser controls (for example, forward or backward through history) may not function as intended. .

Some native apps don't have some of the basic link building properties of websites. First, when a search engine crawls a native application, it cannot simply check for an existing link to a page in the page's outbound links, as it can by viewing the HTML of a web page. Second, many native apps don't link to each other the way websites naturally do, so search engines can't rely on web traversal to discover app deep links as they can to discover web links. This presents a challenge to native app search engines in that it is much more difficult to discover links that support native apps. If the native app's search engine can't detect links, then it can't index them, get them, and serve them to users.

In addition, some native apps have corresponding web pages for the URIs accessed by native apps, while others do not. Of those that do not have corresponding web apps, some native apps retain duplicate or matching content and functionality between native app and web platforms, and other native apps have little or more difference between mobile platforms and web platforms.

Some systems for indexing native apps rely on developers to publish their native app deep links either as HTML markup on their web pages or on their existing website maps. That is, the native app provider must have both a web platform and at least a map for the native app pages on the website. Some services that provide native app deep linking also rely on developers to publish their native app deep links on their web pages.

In accordance with the present invention, native application deep links can be automatically generated for indexing purposes. There are many ways to generate native application deep links depending on the nature of the native application deep links. For example, some native applications support deep links that have URIs that correspond to web-based Uniform Resource Locators (URLs) such as http://www.example.com and so on. Other native apps use a special URI that doesn't necessarily match the specific HTTP protocol.

For native apps that support deep linking based on web-based URLs, the process of generating native app deep linking includes the following:

1) Native app developers check their official website with a centralized indexing service. The service then indexes the native app based on previously indexed network URLs discovered through network crawling.

2) The native app data crawling and indexing system checks the registration information, such as the manifest file, of the native app to determine if it supports the corresponding website URL structure.

3) If the naive app does support an appropriate URL structure, the native app's data crawling and indexing system can determine and prioritize links based on criteria such as popularity. The native app data crawling and indexing system will also take into account any non-indexed tag in the registration information that specifies which URL path should not be indexed.

In accordance with the second aspect of the present invention, for native applications that support ad hoc deep linking, the system implements a method including the following steps:

1) Native application developers implement a native application indexing application programming interface (API) that allows you to specify the URI of a specific native application document, its corresponding web site URL (if any), and all outgoing application deep links and their corresponding web site URLs (if any) that are in the document.

2) Once the native app is updated in the digital distribution source, the native app data crawl and indexing system checks the native app to determine if it is using the native app indexing API. If yes, then the native app data crawling and indexing system launches the native app and looks for a link to the native app's "home page". The native app data crawling and indexing system also looks for any outgoing URI links on the app page. If there are outgoing URIs, then the native app data crawling and indexing system will index each of those links (or just related links) and will also in turn process the next native app pages for the outgoing URIs. In this way, the system for crawling and indexing native application data is able to automatically detect links. At the same time, at each stage, the system of crawling and indexing data of native applications can check the current link of the application page against the link to the source as a method of authentication.

3) The native application data crawling and indexing system can be used to maintain a list of those links actually viewed by the user in the native application and provide this list to the native application data crawling and indexing system. The crawling and indexing system for native app data uses this list as an additional link source in addition to the automatic discovery described in the previous step. In addition, the lists of links that are actually viewed can be used to determine link popularity, and then the crawling and indexing system of native apps can prioritize crawling based on link popularity.

In this regard, the systems and methods described herein can provide automatic indexing of native application deep links. These systems and methods may further define and use link prioritization based on actual user activity. Prioritization allows, among other things, to optimize the use of search resources. Finally, systems and methods are outlined that can match applications with and without their respective websites, overcoming the limitations of existing methods that require applications to publish links through their respective web pages.

Fig. 1 is a block diagram of an example environment 100 in which deep links are generated for native applications. A computer network 102, such as the Internet, connects resource publisher websites 104, application publishers 106, user devices 108, and search engine 120.

The resource publisher website 104 contains one or more web resources 105 associated with a domain and hosted by one or more servers at one or more locations. Typically, a resource publisher's website is a set of hypertext markup language (HTML) formatted web pages that may contain text, images, multimedia content, and programming elements. Each website 104 is maintained by a content publisher, which is the entity that manages, administers and/or owns the website 104.

A web page resource is any data that can be provided by a publisher website 104 over network 102 and that has a resource address, such as a Uniform Resource Locator (URL). Web resources can be, for example, HTML pages, image files, video files, audio files, and news feed sources. Resources may include embedded information, such as meta information and hyperlinks, and/or embedded commands, such as client scripts.

The application publisher website 106 may also contain one or more web resources 105 and also provide native applications 107. A native application 107 is an application specifically designed to run on a particular user device operating system and native firmware. Native applications 107 may include multiple versions designed to run on different platforms. For example, the native applications corresponding to the movie database website may include a first native application that runs on a first type of smartphone, a second native application that runs on a second type of smartphone, and a third native application that runs on a first type of tablet, and etc.

An application page is a specific display environment in a native application that displays content such as text, images, and the like. The application page is dependent on a particular native application, and the native application is specialized for a particular operating system of the user device 108. The application page differs from a rendered web resource in that the application page is generated in and is specialized for the native application, while - the resource can be rendered in any browser for which the web page resource is compatible and is independent of the operating system of the user device.

Some publishers 104 and 106 may be the same and provide the same content in both web resources and native applications. Administration of the transmission of such content is governed by the server application 130 of the publisher. The publisher server application 130 includes a publisher store 132 that stores content provided by the publisher, a web server 134 that provides content from the publisher store in the form of web resources (e.g., web pages), and a native application server 136 that throttles requests from native application. Web pages correspond to native application pages, and therefore many native application URIs have corresponding web page URIs. Some native applications may also simply use the same URLs as the web pages they correspond to. The content of the publisher store 132 is available for storage both on the web resources and on the corresponding web application pages. As such, such content is referred to as "synchronized" content.

Examples of such publishers are news publishers who may have a "mobile news app" for reading news content on a mobile device. The news content (eg, text of a news article) provided in the web resources 105 is the same content as provided by the corresponding application pages of the native application 107.

User device 108 is an electronic device that is capable of requesting and receiving web page resources 105 and native applications 107 over network 102. Examples of user devices 108 include personal computers, mobile communication devices, and tablet computers.

The web index 116 is an index of publisher content, which is, for example, generated by crawling publisher websites 104, by ingesting news feeds from publisher websites 104, or by other suitable means of collecting and indexing data.

Naive app index 114 stores data related to native apps 107. App index 114 stores, for example, a list of native apps provided by publishers 104 and identifiers that identify native apps. In addition, in some implementations, publishers 104 may specify that some native applications 107 are used to access and display synchronized data, and this information may be stored in an application index. For example, a news publisher may specify that the news reader application it provides displays synchronized content that is displayed on the news publisher's website.

User devices 108 submit search queries to search engine 110. In response to each query, search engine 110 accesses web index 116 and application index 114 to identify content that pertains to the query. The search engine 110 may, for example, identify resources and applications in the form of web resource search results and native application search results, respectively, using the search result generator 116 . Once generated, the search results are provided to the user device 108 from which the request was received.

A web resource search result is data generated by the search engine 110 that identifies a web resource based on the content of the resource that satisfies a particular search query. A web resource search result for a resource may contain the title of the web page, a snippet of text retrieved from the resource, and a Uniform Resource Identifier (URI) for that resource, such as the Uniform Resource Locator (URL) of the web page. When selected on the user device, the web resource search result causes the user device to generate a request for the resource located in the URL. The web resource that is received is then displayed in the browser application.

The native application search result specifies a native application and is generated in response to a search on the application index 114 and the web index 116, as described in more detail below. When selected on the user device, the native app search result causes the native app installed on the user device to request the synchronized content. Once the native app receives the requested content, the native app displays the content in the native app's user interface.

To generate the application index 114, the search engine uses an application crawling and indexing system 120 . Fig. 2 is a block diagram of an application crawling and indexing system 120. The operation of system 120 with respect to native applications that use a URL is described with reference to FIG. 3. Changing the behavior of native applications that use a URL is described with reference to FIG. four.

Fig. 3 is a flow diagram of an example process 300 for generating deep links for native applications. Process 300 is implemented in a data processor of one or more computers.

Process 300 receives, at data collector 204, native application publisher binding data 202 that specifies, for each native application, an associated publisher for the native application (302). For example, publishers provide data that a particular native app is associated with a publisher, such as the association of a native app ID with a publisher site ID. One example of a site identifier is a domain name, but other types of data can be used to define the relationship between the publisher and the native application.

The process 300 for the native application, based on the publisher binding data, determines whether the native application is associated with a publisher that provides content addressed by the URIs defined for the native application (304). For example, the application package crawler 206 retrieves from the application manifest file 109 (or other data specifying similar application specifications) the schema, host, and URI format path for the native application. For example, in the case of an Android manifest, the following is extracted from the intent filter section:

<data android:scheme="http"

android:host="example.com"

android:pathPrefix="/gizmos" />

Here the scheme ('scheme') is "http", the host ('host') is "example.com", and the path ('pathPrefix', 'path prefix') is "/gizmos". This process determines the URI pattern for the native application and whether the URI pattern of the associated native application publisher matches the associated native application publisher specified by the publisher binding data 202 . To illustrate, for the example data above, if the association data 202 specifies the "http" scheme for the native application and the host "example.com" and the native application manifest 109 107 specifies the same scheme and host, then the native application is associated with the host.

If the result of the determination is positive, the URI scheme generator 208 stores the data for the native application in the URI scheme table 210, and then the process 300 selects URIs based on the native application URI template (306). For example, in some implementations, the URI selector 212 receives the URI pattern from the URI schema table 210 . The selector 212 then searches the web index 116 for URLs that contain the URI pattern. In the example above, eligible URLs that contain http://example.com/gizmos/ will be processed by selector 212. Selector 212 may discard URLs that may contain an indication that they should not be parsed when crawled; that have been recently searched and indexed for the native app and that are listed as deleted or inactive; or URLs that meet some other exclusion criteria.

The remaining selectable URLs are provided to the URI processor 214, which collects data from the content accessed by the URL. The process 300 then indexes the URL-accessible content for the native application in an index that is searchable by a search engine (308). Data collection and indexing may be carried out by any suitable process. In one implementation example, system 120 instantiates (instantizes) a virtual machine that emulates an operating system for a user device. The virtual machine may, in some implementations, be a modified version of the operating system and contain extraction tools (extractors) that extract data from application pages, as described in more detail below.

The system 120 also instantiates a native application 107 in the virtual machine that generates application pages for display on the user device in the native application 107 and then accesses the native application application pages generated in response to processing the selected URLs in the virtual machine. For each application page, system 110 generates application page data describing the content of the application page. Page content may include, for example, text displayed on the application page; images displayed on the application page; links on the application page to other application pages or other web resources; and other content that is suitable for indexing.

In some implementations, the virtual machine contains extractors that extract content data for indexing. The extracted content data is, for example, data that is provided to the rendering process of the native application. The rendering process renders content based on data for display on the user device. The use of extractors provides a more accurate identification of the various content of the application page. For example, a text extractor extracts text data that is provided to the rendering process of a native application. The text data specifies the text that should be rendered on the application page. Thus, instead of processing the application page image or processing binary display data, the virtual machine receives the actual text to be rendered in the native application environment 107.

Other extractors, such as an image extractor and a list extractor, can be used similarly. The image extractor provides data about the image to be rendered in the native application environment 107, and the list extractor provides data about the list of scrollable items to be rendered in the native application environment 107. Other data may also be extracted, such as application page link data describing the links. on the application page that link to another application page; web page link data describing links on an application page that link to a web resource referred to by the uniform resource locator and that, when selected, instantiates a browser application that renders the resource in a browser environment separate from the native application; etc.

The extractors described above and other suitable data extractors can be implemented using suitable data handlers for a particular operating system. For example, for the Android ^TM operating system, extractors can be implemented using TextView objects, ImageView objects, and ListView objects, respectively. The virtual machine processes the objects to retrieve the relevant data, for example by issuing commands that cause the virtual machine to store to index the relevant data that is provided for rendering.

Returning to 304, if the result of the determination is negative, then process 300 does not process publisher URIs (310). This makes it easier to index publisher content only for native apps that are associated with a publisher (for example, published by a publisher or approved by a publisher to display publisher content).

For native apps that support configurable deep linking that doesn't necessarily match the website, a different process is used to generate deep links. Fig. 4 is a flow diagram of another example process for generating deep links for native applications. Process 400 is implemented in a data processor of one or more computers.

Process 400 determines the URI template for the native application (402). For example, the application manifest 109 may be accessed to determine the URI scheme. The URI scheme can be used to specify a "top-level" native application resource URI, or can be used to select URIs that are already indexed for the native application.

Process 400 instantiates a native application and selects a first URI based on the URI pattern to generate the application page in the native application display environment (404). For example, a virtual machine is instantiated, and a native application is also instantiated on the virtual machine. The URI is provided to the native app and the app page is rendered.

Process 400 starts an iterative discovery process (406). This process will continue until the full set of URIs has been processed.

Process 400 determines outgoing URIs from the application page, including those on the first page of the application (408). For example, the native app API determines URIs from the app page data that refer to other native app URIs. Such determination may be performed, for example, by processing text retrieved from the application page to match a URI pattern generated by manifest 109; or based on an API that selects markup text that specifies outgoing URIs.

Process 400 selects one or more outgoing URIs to generate one or more next application pages in the native application display environment (410). In some implementations, all outgoing URIs are selected. In some implementations, only outgoing URIs that match the native application's URI pattern are selected.

Process 400 indexes application page data for each of the specified one or more next application pages in the index (412). As described above, system 110 may use a virtual machine or some other construct to retrieve application page data for indexing.

Process 400 determines if the iterative discovery process has completed (414). If the iterative discovery process has completed, then process 400 ends indexing the application for the native application (416). Otherwise, process 400 returns to block 406 and starts another iteration.

In some implementations, when real users are viewing content in native applications, the native application API can be used to notify the application crawling and indexing system 120 of the links that are actually being viewed by users. Application crawling and indexing system 120 can use this information as an additional source of links beyond the natural discovery described above. In addition, application crawling and indexing system 120 may also prioritize crawling based on link popularity.

Embodiments of the invention and the operations set forth herein may be implemented in digital electronic circuits, or in computer software, firmware, or hardware, including the structures set forth herein and their structural equivalents, or in combinations of one or more of them. Embodiments of the invention described herein may be implemented as one or more computer programs, i.e. one or more computer program instruction modules encoded in a computer storage medium for execution by or control of the data processing device. Alternatively or in addition, the program instructions may be encoded in an artificially generated propagating signal, such as a machine generated electrical, optical or electromagnetic signal, which is generated to encode information for transmission to a suitable receiving device for execution by a data processing device. The computer storage medium may be, or be included in, a computer-readable storage device, a computer-readable storage medium, an array or random access or sequential storage device, or a combination of one or more of these. In addition, although computer storage media is not a propagating signal, computer storage media may be the source or destination of computer program instructions encoded in an artificially generated propagating signal. A computer storage medium may also be - or be included in - one or more separate physical components or media (eg, a plurality of CDs, disks, or other storage devices).

The operations described herein may be implemented as operations performed by a data processing device on data stored in one or more computer-readable memories or received from other sources.

The term "data processing device" embraces all kinds of data processing devices, appliances and machines, including by way of example a programmable processor, a computer, a system on a chip, or a plurality of systems on a chip, or combinations of the foregoing. This device may contain, in addition to hardware, code that creates an execution environment for the computer program in question, for example, code that makes up processor firmware, a protocol package, a database management system, an operating system, a cross-platform execution environment, a virtual machine, or a combination of one or more of them. The device and the runtime environment may implement various different computing model infrastructures such as web services, distributed computing, and networked computing infrastructures.

A computer program (otherwise referred to as a program, software tool, software application, script, or code) may be written in any form of a programming language, including compiled or interpreted languages, declarative or procedural languages, and may be deployed in any form, including as a stand-alone program, or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A computer program may, but need not, correspond to a file in the file system. A program may be stored in a portion of a file that contains other programs or data (for example, one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coherent files (for example, files that store one or more modules, subroutines, or pieces of code). A computer program may be deployed to run on a single computer or on multiple computers that are located in a single location or distributed across multiple locations and interact via a data communication network.

The process flows and logical flows described herein may be implemented by one or more programmable processors executing one or more computer programs to perform actions by performing operations on input data and generating output results. Processors suitable for executing a computer program include, by way of example, both general purpose and specialized microprocessors, as well as any one or more processors of any kind of digital computer. Typically, the processor receives instructions and data from read-only memory or random access memory, or both. The most important elements of a computer are a processor for performing actions in accordance with instructions and one or more memory devices for storing instructions and data. Typically, the computer also includes or is operatively coupled to one or more mass storage devices for storing data, such as magnetic, magneto-optical disks, or optical disks, to receive data from or transmit data to them, or both. However, the computer does not have to contain such devices. In addition, the computer may be embedded in another device, such as a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device (such as a flash drive with a Universal Serial Bus (USB) Devices suitable for storing computer program instructions and data include all forms of non-volatile memory, multimedia, and storage devices, including, by way of example, semiconductor memory devices such as erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM) and flash memory devices magnetic disks such as internal hard disks and removable disks magneto-optical disks and CD-ROMs and DVD-ROMs The processor and memory may be configured with dedicated logic circuits or included b in their composition.

To provide user interaction, embodiments of the invention described herein may be implemented on a computer having a display device, such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor for displaying information to the user, as well as a keyboard and a pointing device, such as a mouse or trackball, with which a user can provide input to a computer. Other kinds of devices may also be used to provide user interaction; for example, the feedback provided to the user may be any form of sensory feedback, such as visual feedback, acoustic feedback, or tactile feedback, and input from the user may be in any form, including acoustic, speech, or tactile input. In addition, the computer can interact with the user by sending documents to and receiving documents from the device being used by the user; for example, by sending web pages to a web browser on the user's user device in response to requests received from the web browser.

Embodiments of the invention described herein may be implemented in a computing system that contains an internal component, such as a data server, or that contains a middleware component, such as an application server, or that contains an external component, such as a user's computer. having a graphical user interface or web browser through which a user can interact with an implementation of the invention described herein, or any combination of one or more of such background, middleware, or foreground components. The components of the system can communicate using any form or medium of digital communication, such as a data network. Examples of data communication networks include a local area network ('LAN') and a wide area network ('WAN'), internetwork (eg, the Internet), and peer-to-peer networks (eg, ad hoc peer-to-peer networks).

The computer network may include users and servers. The user and the server are usually remote from each other and usually interact over a data network. The user-server relationship arises from computer programs running on respective computers and having a user-server relationship with each other. In some embodiments, the server transmits data (eg, an HTML page) to the user device (eg, for the purpose of displaying the data to a user interacting with the user device and receiving user input from the user). Data generated at the user device (eg, the result of user interaction) may be received from the user device at the server.

Although this description contains many specific implementation details, they should not be construed as limitations on the scope of any inventions or what may be claimed, but rather as descriptions of features specific to particular embodiments of particular inventions. Some of the features that are set forth in this description in relation to individual variants of implementation may also be implemented together in one embodiment. Conversely, various features that are set forth in relation to one embodiment may also be implemented in multiple embodiments individually or in any suitable subcombination. In addition, while the features may have been set forth above as operating in some combinations, and even as originally claimed as such, one or more of the features from the claimed combination may in some cases be excluded from the combination, and the claimed combination may be directed to a subcombination. or a subcombination option.

Similarly, although the operations are shown in the drawings in a specific order, this should not be understood as requiring that such operations be performed in the particular order depicted or in sequential order, or that all the illustrated operations be performed to achieve the desired results. Under certain conditions, multitasking and parallel processing may be preferable. In addition, the separation of the various system components in the above embodiments should not be understood to require such separation in all embodiments, it being understood that the described software components and systems may generally be combined with each other in a single software product or packaged. in many software products.

Thus, specific embodiments of the invention are described. Other embodiments are within the scope. defined by the following claims. In some cases, the steps listed in the claims may be performed in a different order and still achieve the desired results. In addition, the processes shown in the accompanying drawings do not necessarily require the specific order depicted or sequential order to achieve the desired results. In some implementations, multitasking and parallel processing may be preferred.

Statement 1. A computer-implemented method carried out by a data processing device comprising one or more computers exchanging data, which method comprises the steps of:

receiving publisher binding data for native applications that specifies, for each native application, an associated publisher for that native application;

for each native application of the set of native applications, determining, based on the publisher binding data, whether the native application is associated with a publisher that provides content addressed by the Uniform Resource Identifiers (URIs) defined for that native application;

only for native apps that are defined as being associated with a publisher that provides content addressed by the Uniform Resource Identifiers defined for the native app:

selecting Uniform Resource Identifiers based on the URI template for the native application; and

indexing the content accessed by the native application Uniform Resource Identifier in an index that is searchable by a search engine.

Claim 2: The computer-implemented method of Claim 1, wherein said determining, based on publisher binding data, whether the native application is associated with a publisher that provides content addressed by the URIs defined for the native application comprises the steps of:

define a URI template for the native application;

determining whether the URI template of the associated native application publisher matches the associated native application publisher specified by the publisher binding data; and

determine that the native application is associated with a publisher only when the native application URI pattern specifies an associated native application publisher that matches the associated native application publisher specified by the publisher binding data.

Proposition 3. The computer-implemented method of claim 2, wherein said definition of a native application URI template comprises processing a native application manifest file for data describing the URI template.

Claim 4: The computer-implemented method of Claim 2, wherein the publisher binding data for each native application defines an association between a publisher domain and a native application identifier corresponding to the native application.

Claim 5. The computer-implemented method of Claim 4, wherein said determining whether the URI pattern specifies an associated publisher for a native application comprises determining whether the URI has a hostname that matches the publisher's domain, wherein the hostname matches The URI with the publisher's domain results in a positive result, and a URI hostname mismatch with the publisher's domain results in a negative result.

Claim 6. The computer-implemented method of Claim 2 wherein said URI selection based on the URI template for the native application selects from the index those URIs that include the URI template.

Claim 7. A computer-implemented method according to clause 6, wherein the URIs are Uniform Resource Locators (URLs).

Claim 8. The computer-implemented method of Claim 2, wherein said selecting a URI based on a URI pattern for a native application comprises:

instantiating a native application and selecting a first URI based on the URI pattern to generate an application page in a native application display environment;

perform iterative processing of the linked application pages for the native application up to the occurrence of a stop event, and the iterative processing includes, for each iteration, the steps in which:

determine, from the application page, outgoing URIs, including those on the first page of the application; and

selecting one or more of the outgoing URIs to generate one or more next application pages in the native application display environment.

Statement 9. A computer-implemented method carried out by a data processing device comprising one or more computers exchanging data, which method comprises the steps of:

defining a Uniform Resource Identifier (URI) template for the native application;

instantiating a native application and selecting a first URI based on the URI pattern to generate an application page in a native application display environment;

indexing the application page data of that application page in an index that is searchable by a search engine;

perform iterative processing of the linked application pages for the native application up to the occurrence of a stop event, and the iterative processing includes, for each iteration, the steps in which:

determine, from the application page, outgoing URIs, including those on the first page of the application;

selecting one or more of the outgoing URIs to generate one or more next application pages in the native application display environment;

indexing application page data for each of the one or more next application pages in the index.

Claim 10. The computer-implemented method of claim 9, wherein said selecting one or more of the outgoing URIs to generate one or more next application pages in a native application display environment comprises the steps of:

for each outgoing URI, determining whether this outgoing URI matches the URI pattern; and

select only outgoing URIs that match the URI pattern.

Claim 11. The computer-implemented method according to clause 10, wherein, in said determination of whether an outgoing URI matches a URI pattern, determining whether the outgoing URI contains the URI pattern.

Statement 12. System containing:

data processing device; and

software stored on a non-volatile computer-readable medium that stores instructions that are executable by a data processing device and that, when executed, cause the data processing device to perform operations, including operations to:

receive publisher binding data for native applications that specifies, for each native application, an associated publisher for that native application;

for each native application in the set of native applications, determine, based on the publisher affinity data, whether the native application is associated with a publisher that provides content addressed by the Uniform Resource Identifiers (URIs) defined for that native application;

only for native apps that are defined as being associated with a publisher that provides content addressed by the Uniform Resource Identifiers defined for the native app:

select Uniform Resource Identifiers based on the URI pattern for the native application; and

index the content accessed by the native app Uniform Resource Identifier in an index that is searchable by a search engine.

Claim 13: A system according to clause 12, wherein said determining, based on publisher affinity data, whether the native application is associated with a publisher that provides content addressed by the URIs defined for the native application comprises:

defining a URI template for a native application;

determining whether the URI template of the associated native application publisher matches the associated native application publisher specified by the publisher binding data; and

determining that the native application is associated with a publisher only when the native application URI pattern specifies an associated native application publisher that matches the associated native application publisher specified by the publisher binding data.

Claim 14. The system as claimed in Claim 13, wherein said native application URI template definition includes processing a native application manifest file for data describing the URI template.

Claim 15: A system as in clause 13, wherein the publisher binding data for each native application defines an association between a publisher domain and a native application identifier corresponding to the native application.

Clause 16: The system as claimed in Clause 15, wherein said determination of whether the associated publisher URI template for the native application specifies whether the URI contains a hostname that matches the publisher's domain, wherein matching the URI's hostname to the publisher's domain results in a positive the result of the determination, and a mismatch between the host name of the URI and the domain of the publisher results in a negative result of the determination.

Claim 17. The system as claimed in Claim 13, wherein said selection of a URI based on a URI pattern for a native application comprises selecting from an index of those URIs that include the URI pattern.

Clause 18. A system under clause 17 in which the URIs are Uniform Resource Locators (URLs).

Clause 19. A system according to clause 18, wherein said URI selection based on a URI pattern for a native application comprises:

instantiating the native application and selecting a first URI based on the URI template to generate an application page in the native application display environment;

iteratively processing the linked application pages for the native application until a stop event occurs, where the iterative processing includes, for each iteration:

determining, from the application page, outgoing URIs, including those on the first page of the application; and

selecting one or more of the outgoing URIs to generate one or more next application pages in the native application display environment.

Statement 20. A system comprising:

data processing device; and

software stored in a non-volatile computer-readable medium that stores instructions that are executable by the data processing device and which, when executed, cause the data processing device to perform operations comprising:

defining a Uniform Resource Identifier (URI) template for the native application;

instantiating the native application and selecting a first URI based on the URI template to generate an application page in the native application display environment;

indexing the application page data of that application page in an index that is searchable by a search engine;

iteratively processing the linked application pages for the native application until a stop event occurs, where the iterative processing includes, for each iteration:

determining, from the application page, outgoing URIs, including those on the first page of the application;

selecting one or more of the outgoing URIs to generate one or more next application pages in the native application display environment;

indexing application page data for each of the one or more next application pages in the index.

Statement 21. A non-volatile computer-readable medium storing instructions that are executable by a data processing device and which, when executed, cause the data processing device to perform operations comprising the steps of:

receiving publisher binding data for native applications that specifies, for each native application, an associated publisher for that native application;

for each native application of the set of native applications, determining, based on the publisher binding data, whether the native application is associated with a publisher that provides content addressed by the Uniform Resource Identifiers (URIs) defined for that native application;

only for native apps that are defined as being associated with a publisher that provides content addressed by the Uniform Resource Identifiers defined for the native app:

selecting a Uniform Resource Identifier based on the URI pattern for the native application;

indexing the content accessed by the native application Uniform Resource Identifiers in an index that is searchable by a search engine.

Statement 22. A non-volatile computer-readable medium storing instructions that are executable by a data processing device and which, when executed, cause the data processing device to perform operations comprising the steps of:

defining a Uniform Resource Identifier (URI) template for the native application;

instantiating a native application and selecting a first URI based on the URI pattern to generate an application page in a native application display environment;

indexing the application page data of that application page in an index that is searchable by a search engine;

perform iterative processing of the linked application pages for the native application until a stop event occurs, the iterative processing comprising, for each iteration, steps in which:

determine, from the application page, outgoing URIs, including those on the first page of the application;

selecting one or more of the outgoing URIs to generate one or more next application pages in the native application display environment;

indexing application page data for each of the one or more next application pages in the index.

Claims (29)

1. A computer-implemented method for automatically generating deep links of native applications, carried out by a data processing device containing one or more computers exchanging data, the method comprising the steps of: receiving data for the native application specifying a Uniform Resource Identifier (URI) template for the native application, the URI template specifying the corresponding publisher for the native application, the data including a hostname and a path prefix; generating from the URI template a plurality of URIs for said native application, each URI including a hostname and a path prefix appended to that hostname; for at least one or more URIs from said set of URIs, generating a deep link for said native application, the deep link including the URI and additional data that is attached to that URI; and storing said plurality of URIs in a data store. 2. The computer-implemented method of claim 1, wherein the data store is an index adapted to be searched by a search engine. 3. The computer-implemented method of claim 1, wherein said receiving data specifying a URI template for a native application comprises processing the native application manifest file for data describing the URI template. 4. The computer-implemented method of claim 1, wherein the hostname matches the name of said respective publisher of said native application. 5. The computer-implemented method of claim 1, wherein the URIs are Uniform Resource Locators (URLs). 6. System for automatic generation of deep links of native applications, containing: data processing device; and software stored in a non-volatile computer-readable medium containing instructions that are executable by a data processing device and which, when executed, cause the data processing device to perform operations comprising: receiving, for a native application, data specifying a Uniform Resource Identifier (URI) template for that native application, wherein the URI template specifies the appropriate publisher for that native application, the data including a hostname and a path prefix, generating, from the URI template, a plurality of URIs for said native application, each URI including a hostname and a path prefix appended to that hostname, for at least one or more URIs from said set of URIs, generating a deep link for said native application, wherein the deep link includes the URI and additional data that is attached to that URI, and storing said plurality of URIs in a data store. 7. The system of claim 6, wherein the data store is an index adapted to be searched by a search engine. 8. The system of claim 6, wherein said receiving data specifying a URI template for a native application comprises processing the native application manifest file for data describing the URI template. 9. The system of claim 6, wherein the host name is the same as the name of said respective publisher of said native application. 10. The system of claim 6, wherein the URIs are Uniform Resource Locators (URLs). 11. A non-volatile computer-readable medium that stores instructions executable by a data processing device that, if so executed, instruct the data processing device to perform operations comprising: receiving, for the native application, data specifying a Uniform Resource Identifier (URI) template for that native application, the URI template specifying the appropriate publisher for that native application, the data including a hostname and a path prefix; generating, from the URI template, a plurality of URIs for said native application, each URI including a hostname and a path prefix appended to that hostname; for at least one or more URIs from said set of URIs, generating a deep link for said native application, the deep link including the URI and additional data that is attached to that URI; and storing said plurality of URIs in a data store. 12. The durable computer-readable medium of claim 11, wherein the data store is an index adapted to be searched by a search engine. 13. The durable computer-readable medium of claim 11, wherein said receiving data specifying a URI template for a native application comprises processing a native application manifest file for data describing the URI template. 14. The durable computer-readable medium of claim 11, wherein the host name is the same as the name of said respective publisher of said native application. 15. The durable computer-readable medium of claim 11, wherein the URIs are Uniform Resource Locators (URLs).

Images