Patent Description:
An application, executing on a device, may be displaying content that, when selected, causes another application to be launched. However, the delay from selecting the content and then launching and rendering the application linked to the content may be relatively long. <CIT> discloses a messaging system in one embodiment including a messaging app and one or more extension apps configured to create content that is displayed in a view hosted by the messaging app. The messaging app can launch the one or more extension apps, and content can be communicated between each extension app and the messaging app through an interprocess communication. <CIT> discloses a computer-implemented method including executing, on a computing device, a non-browser application; displaying, by the non-browser application on a display of the computing device, a link to web content; and receiving an indication that the link has been selected. In response to the indication that the link has been selected, allocating a tab of a browser application to the non-browser application; displaying the allocated browser tab within a user interface of the non-browser application, and displaying, by the allocated browser tab, the web content within the user interface. <CIT> discloses methods, systems, and apparatus, for selecting one or more native application deep links from search results and instantiating, for each native application deep link that is selected, a background instance of the native application to which the native application deep link corresponds. <CIT> discloses systems and methods of pre-launching applications in a computer system, said applications being likely to be activated by a user from a terminated and/or suspended process state. <CIT> discloses an application program preloading method and mobile terminal.

The claimed subject-matter is defined by the independent claims. Dependent claims describe embodiments thereof. This disclosure relates to pre-launching an application using interprocess communication (IPC) to improve deep link landing latency. For example, application A may be executing as a foreground process, where application A is displaying content on a device's display. If a user selects the content, application B may be launched and displayed within the computing device's display. However, according to the embodiments, before receipt of an action is taken with respect to the displayed content (e.g., before the user selects the content), application A may call an initialization API of application B so that application B can be launched as a background process. Then, when the user actually selects the content, application B can be rendered on the display relatively quickly since application B was pre-launched.

This disclosure relates to pre-launching an application using interprocess communication. For example, application A may be executing as a foreground process, where application A is displaying content on a display of a computing device (e.g., a mobile computing device). The content is associated with an action of application B. For example, if a user selects the content, application B may be launched and displayed within the computing device's display. However, according to the embodiments, before receipt of an action is taken with respect to the display content (e.g., before the user selects the content), application A may transmit an initialization request to application B so that application B can be launched as a background process. Then, when the user actually selects the content, application B can be rendered on the display relatively quickly since application B was pre-launched. In some examples, the initialization request also specifies one or more prefetching parameters, which causes application B to prefetch and store content in the background. Then, when the user actually selects the content, the prefetched content can be rendered in application B relatively quickly.

Application B includes an interface definition language that defines an initialization application programming interface (API) that gives a calling application (e.g., application A) the ability to call the pre-launch service. In other words, the initialization API (e.g., also referred to as a pre-launch API) defines a pre-launch interface that can be used by other applications (e.g., application A) to pre-launch application B as a background process of the operating system. The initialization request is received at the initialization API, which causes application B to be launched as a background process. In some examples, receipt of the initialization request causes the creation (or establishment) of an interprocess communication (IPC) connection between application A and application B to enable application A and application B to communicate with each other.

The IPC connection is a communication protocol that allows processes (e.g., applications) to communicate with each other and synchronize their actions. In some examples, receipt of the initialization request binds application A and application B so that information can be exchanged between application A and application B. In some examples, in response to a call to the initialization API from the calling application (e.g., application A), application B can provide a service instance (e.g., a binder) to application A, where the binder is used to identify methods to be invoked and pass arguments between the applications. While the IPC connection remains active, application A and application B can communicate with each other. In some implementations, while the calling application is bound to the called application, the operating system may not terminate the called application.

In some examples, if the IPC connection is terminated (e.g., deactivated), the underlying service (e.g., the pre-launching service) is terminated, thereby causing the background process that is executing application B to be terminated. In some example, in response to the content being moved off the screen (e.g., the content no longer being displayed in application A) or upon the expiration of a timer (e.g., one minute, two minutes, etc.), application A may transmit a termination request (e.g., an unbind service call) to the initialization API of application B, which causes the IPC connection to be terminated, thereby terminating the background process that is executing application B. In this manner, if it is likely that the user will not select the content, application B (which has been pre-launched as a background process) will be closed in order to have those computer resources (e.g., memory, processor) available for other programs.

<FIG> illustrate a system <NUM> for pre-launching an application 108a using interprocess communication according to an aspect. For example, the system <NUM> enables an application 108b to transmit an initialization request <NUM> to an initialization application programming interface (API) <NUM> of an application 108a to initialize (e.g., launch) the application 108a as a background process <NUM> of an operating system <NUM> of a computing device <NUM>.

The computing device <NUM> may include one or more processors <NUM> formed in a substrate configured to execute one or more machine executable instructions or pieces of software, firmware, or a combination thereof. The processors <NUM> can be semiconductor-based - that is, the processors can include semiconductor material that can perform digital logic. The computing device <NUM> may include one or more memory devices <NUM>. The memory devices <NUM> may include a main memory that stores information in a format that can be read and/or executed by the processors <NUM>. The memory devices <NUM> may store the applications <NUM>, the operating system <NUM>, and modules (e.g., a request decision module <NUM>, a termination decision module <NUM>) that, when executed by the processors <NUM>, perform certain operations.

In some examples, the computing device <NUM> is a mobile computing device. In some examples, the computing device <NUM> is a smartphone or tablet. In some examples, the computing device <NUM> is a wearable device, smart television, or other computing device. In some examples, the computing device <NUM> is a gaming console. In some examples, the computing device <NUM> is an automotive heat unit. The operating system <NUM> is a system software that manages computer hardware, software resources, and provides common services for computing programs. In some examples, the operating system <NUM> is operable to run on a mobile computer such as a smartphone or tablet. The computing device includes a display <NUM> (e.g., a touchscreen display, an LED display, etc.) that can display a user interface for an application <NUM> that is being executed by the computing device <NUM>. More than one application <NUM> can be executed at a time. However, in some examples (e.g., in the case of a smart phone), the size of the display <NUM> is better suited for a single executing application <NUM> to be displayed at a time.

The applications <NUM> may include any type of computer program executable by the operating system <NUM>. The applications <NUM> may include mobile applications, e.g., software programs that are developed for a mobile platform or mobile device. The applications <NUM> includes an application 108a and an application 108b. The application 108b is a software program that is different (and separate) from the application 108a. The application 108a and the application 108b are installed on the operating system <NUM> of the computing device <NUM>. In some examples, the application 108a and/or the application 108b are downloaded from an online digital store and installed by the operating system <NUM> of the computing device <NUM>. In some examples, the application 108a and/or the application 108b have been pre-installed on the operating system <NUM> of the computing device <NUM>.

In some examples, the application 108a is a mobile application (e.g., an application configured to be executed by a mobile platform or a mobile device). In some examples, the application 108b is a mobile application. If a user selects an icon of the application 108a (or the application 108b) that is displayed on a display <NUM> of the computing device <NUM>, the operating system <NUM> may launch as a foreground process <NUM> and display application content of the application 108a (or the application 108b) in the display <NUM>. In some examples, the application 108a is a digital store application that can download and install digital media (e.g., applications <NUM> (e.g., mobile apps)) on the computing device <NUM>. In some examples, the application 108a is an ecommerce application. In some examples, the application 108b is a non-browser application (e.g., not a web browser or a mobile web browser). However, the application 108a and the application 108b may be any type of application configured to execute on the operating system <NUM> of the computing device <NUM>.

Referring to <FIG> and <FIG>, the application 108b may be displaying content <NUM> on the display <NUM> of the computing device <NUM>, where the application 108b is executing as the foreground process <NUM>. A foreground process <NUM> is required for what the user is doing and has the highest memory priority. For example, when system memory is low, the operating system <NUM> may terminate background processes first to free up memory. In some examples, an application <NUM> that is executing as the foreground process <NUM> generates content that is displayed on the display <NUM>. In some examples, an application <NUM> that is executing as the foreground process <NUM> may refer to an application <NUM> that is positioned on the display <NUM>, or in other words, an application the user is currently using. In some examples, an application <NUM> that is executing as the foreground process <NUM> may refer to an active application which can consume data and/or is currently running on the operating system <NUM>.

The content <NUM> from application 108b that is displayed on the display <NUM> may be associated with an action <NUM> executable by a different application, e.g., the application 108a. In other words, the application 108b may display content <NUM> (while it is executing as the foreground process <NUM>), but the content <NUM> (when selected) may initiate an interface in the application 108a. For example, if a user-provided action is taken with respect to the content <NUM> (e.g., the user selects (e.g., taps, clicks on, etc.) on the content <NUM>), the display <NUM> may switch to the application 108a as shown in <FIG>. In <FIG>, the application 108a is now executing as the foreground process <NUM>.

The content <NUM> may be any type of content generated by the application 108b that includes a link to an action <NUM> performed by another application <NUM> (e.g., application 108a). In some examples, the content <NUM> includes information about a product or service, which, when selected, causes the application 108a to be launched in the foreground process <NUM>. In some examples, the content <NUM> includes advertisement content (e.g., a mobile ad). In some examples, the content <NUM> includes an advertisement installment ad. For example, the content <NUM> may reference another application that is not installed on the computing device <NUM>, but when selected, causes the operating system <NUM> to launch an application 108a (e.g., a digital store application) so that the user can download and install the application referenced by the content <NUM>. In some examples, the selection of the mobile ad (e.g., the content <NUM>) causes an action <NUM> of launching the digital store application (e.g., application 108a) with a deep link or specific intent, e.g., to a user interface for downloading the other application. However, it is noted that the content <NUM> may be any type of content provided by the application 108b, which, when selected, requires an action <NUM> of another application <NUM>.

Referring to <FIG> and <FIG>, in advance of a user action taken with respect to the content <NUM> (e.g., before the user selects the ad), the application 108b causes the application 108a to be pre-launched as a background process <NUM> of the operating system <NUM>. In some examples, an application <NUM> that is executing as the background process <NUM> does not render a user interface that is displayed on the display <NUM> of the computing device <NUM> (e.g., does not have an active UI). In some examples, an application <NUM> that is executing as the background process <NUM> may refer to a non-active application but is performing an activity in the background. In some examples, the user is not aware a background process <NUM> is running. A background process <NUM> may be less important to what the user is currently doing than a foreground process <NUM>, and, in some examples, is given a lower memory priority by the operating system <NUM>.

Referring to <FIG>, the application 108a defines an interface definition language <NUM>. The interface definition language <NUM> defines a programming interface that permits the application 108a to communicate with other applications <NUM> including application 108b. According to the embodiments discussed herein, the interface definition language <NUM> defines an initialization API <NUM>, which a calling application (e.g., application 108b) uses to call the pre-launch service. In other words, the initialization API <NUM> (e.g., also referred to as a pre-launch API) defines a pre-launch interface that can be used by other applications <NUM> (e.g., application 108b) to pre-launch the application 108a as a background process <NUM>.

In some examples, when the content <NUM> of the application 108b is displayed on the display <NUM> (which is before the user has selected the content <NUM>)), the application 108b may call the initialization API <NUM> by transmitting an initialization request <NUM> to the initialization API <NUM> of the application 108a. The initialization request <NUM> is received at the initialization API <NUM>, which causes the operation system <NUM> to launch the application 108a as a background process <NUM> (e.g., running in the background but not displaying an active UI). In some examples, the launching operations may include allocating new memory for the new process (e.g., the background process <NUM>), loading the application code into the process memory, and/or scheduling the new process for CPU time. In some examples, the receipt of the initialization request <NUM> causes the creation (or establishment) of an interprocess communication (IPC) connection <NUM> between the application 108a and application 108b to enable the application 108a and the application 108b to communicate with each other.

The IPC connection <NUM> is a communication protocol that allows processes to communicate with each other and synchronize their actions. In some examples, receipt of the initialization request <NUM> binds the application 108a and the application 108b (e.g., application 108a and application 108b are linked) so that information can be exchanged between the application 108a and the application 108b. In some examples, their execution states are linked or binded when the IPC connection <NUM> is established. For example, if the user closes application 108b, application 108a will be closed.

In some examples, when the application 108a binds to the application 108b (in other words, the foreground process <NUM> binds to the background process <NUM>), the background process <NUM> is given the same high priority as the foreground process <NUM>, which allows the pre-launching process to continue even if the device memory is low. For example, conventionally, if the device memory is below a threshold level, the operating system <NUM> may terminate the background processes. However, when the foreground process <NUM> binds to the background process <NUM> (e.g., upon establishment of the IPC connection <NUM>), and, if the device memory is below the threshold level, the operating system <NUM> is prevented from terminating the background process <NUM> which is executing the pre-launch process.

In some examples, the application 108a can provide a service instance (e.g., a binder) to the application 108b where the service instance (e.g., binder) is used to identify methods that can be invoked and to pass arguments between the application 108a and the application 108b. While the interprocess communication connection <NUM> remains active, the application 108a and the application 108b can communicate with each other. In some examples, if the interprocess communication connection <NUM> is terminated (e.g., deactivated), the underlying service (e.g., the pre-launching service) is terminated, thereby causing the background process <NUM> executing the application 108a to be terminated.

Because application 108a is pre-launched, in response to receipt of a user action taken with respect to the content <NUM> (which requires the action <NUM> of the application 108a), the user interface of application 108a may be rendered on the display <NUM> more quickly, thereby reducing the latency of displaying information associated with the application 108a. For example, when the content <NUM> is selected in <FIG>, the application 108a can be quickly loaded into the display <NUM> (in the foreground process <NUM>) as shown in <FIG>, where the latency of loading application <NUM> can be reduced (e.g., significantly reduced) because the application 108a is pre-launched as the background process <NUM>.

<FIG> illustrates an example of prefetching content <NUM> as a background process <NUM> according to an aspect. In some examples, as shown in <FIG>, the initialization request <NUM> indicates to prefetch content <NUM>. In some examples, the term prefetch may refer to the retrieval of information from a server computer <NUM> connected to the computing device <NUM> over a network <NUM> while the application 108a is executing as the background process <NUM> of the operating system <NUM>.

The application 108b may be displaying content <NUM> in the foreground process <NUM>, and before the user has selected the content <NUM>, the application 108b may transmit an initialization request <NUM> that calls the initialization API <NUM> to pre-launch the application 108a, where the initialization request <NUM> may specify one or more prefetch parameters <NUM>. In some examples, if the application 108a is a digital store application, the prefetch parameter(s) <NUM> may provide an application identifier for the application referenced by the content <NUM>, and the application 108a may prefetch details about the application such as the name, downloads, ratings, and/or reviews, etc. In some examples, the prefetch parameter(s) <NUM> includes an identifier of a resource (e.g., product, application, service, etc.) referenced by the content <NUM>. In some examples, the prefetch parameter(s) <NUM> includes an application identifier. In some examples, the prefetch parameter(s) <NUM> include a product or service identifier. In some examples, the prefetch parameter(s) <NUM> include a uniform resource locator (URL). However, the type of prefetch parameter(s) <NUM> may be dependent upon the type of application 108a. In some examples, if the application 108a is an ecommerce site, the prefetch parameter(s) <NUM> may include the product identifier and/or a product page to prefetch.

If the initialization request <NUM> specifies one or more prefetch parameters <NUM>, the application 108a can prefetch content <NUM> according to the prefetch parameter(s) <NUM> in the background and store (e.g., cache) the content <NUM> in memory (e.g., memory device <NUM>) in advance of a user action taken with respect to the content <NUM> (e.g., before the user selects the ad). In some examples, in order to prefetch the content <NUM>, the application 108a can communicate with the server computer <NUM>, over a network <NUM>, in order to retrieve the content <NUM> from resources <NUM> stored at the server computer <NUM>. Then, when the user selects the content <NUM>, the display <NUM> can be quickly switched to the application 108a (e.g., because the application 108a is pre-launched), where the application 108a quickly displays the content <NUM> (e.g., because the content <NUM> is prefetched).

The server computer <NUM> may be computing devices that take the form of a number of different devices, for example a standard server, a group of such servers, or a rack server system. In some examples, the server computer <NUM> may be a single system sharing components such as processors and memories. The resources <NUM> may be any type of computer resources such as web pages or information accessible via the network <NUM>. The network <NUM> may include the Internet and/or other types of data networks, such as a local area network (LAN), a wide area network (WAN), a cellular network, satellite network, or other types of data networks. The network <NUM> may also include any number of computing devices (e.g., computer, servers, routers, network switches, etc.) that are configured to receive and/or transmit data within network <NUM>. Network <NUM> may further include any number of hardwired and/or wireless connections.

The server computer <NUM> may include one or more processors <NUM> formed in a substrate, an operating system (not shown) and one or more memory devices <NUM>. The memory devices <NUM> may represent any kind of (or multiple kinds of) memory (e.g., RAM, flash, cache, disk, tape, etc.). In some examples (not shown), the memory devices <NUM> may include external storage, e.g., memory physically remote from but accessible by the server computer <NUM>. The server computer <NUM> may include one or more modules or engines representing specially programmed software.

In some examples, the initialization request <NUM> indicates pre-launch. In some examples, the initialization request <NUM> includes information to pre-launch and prefetch. In some examples, separate requests are used to instruct the application 108a to pre-launch and prefetch. For example, a first request may be transmitted to the initialization API <NUM> to pre-launch the application 108a as a background process <NUM>, and then a second request may be transmitted to the initialization API <NUM> to prefetch content <NUM> as a background process <NUM>, where the second request may be sent after the first request or the first and second requests may be transmitted around the same time.

The application 108b may transmit the initialization request <NUM> in response to the content <NUM> being displayed on the display <NUM>. In some examples, the application 108b includes a request decision module <NUM> that determines whether the application 108b should transmit the initialization request <NUM> to the initialization API <NUM> to pre-launch and/or prefetch. In some examples, the decision to pre-launch and/or prefetch occurs when the content <NUM> is displayed on the display <NUM>. In some examples, the decision to pre-launch and/or prefetch occurs at a time instance before the content <NUM> is displayed on the display <NUM>. In some examples, the decision to pre-launch and/or prefetch occurs at a time instance after the content <NUM> is displayed on the display <NUM>.

The request decision module <NUM> may determine whether to transmit the initialization request to the initialization API <NUM> based on one or more signals <NUM>. The signals <NUM> may include one or more signals generated by the computing device <NUM>. In some examples, the signals <NUM> may include one or more signals generated by a server computer. <FIG> illustrates various examples of signals <NUM> used to determine whether to pre-launch and/or prefetch. For example, referring to <FIG>, the signal(s) <NUM> may include battery charge level <NUM>, available memory level <NUM>, a network condition(s) <NUM> of the computing device <NUM>, a click-through rate <NUM>, and/or predicted conversion rate <NUM>.

The battery charge level <NUM> indicates a current charge level of the battery of the computing device <NUM>. The available memory level <NUM> indicates a current level of memory of the computing device <NUM> available to be used. The click-through rate <NUM> is the ratio of the number of times that the content <NUM> has been selected by users and the number of times that the content <NUM> has been shown to users. The predicted conversion rate <NUM> is that predicted rate at which users will perform a certain goal (e.g., download the application referenced by the content <NUM>). The network condition(s) <NUM> may include one or more network metrics about the bandwidth/speed of the connection of the computing device <NUM> to the network <NUM>.

<FIG> illustrates example operations of determining whether to pre-launch the application 108a according to an aspect. Referring to <FIG>, in operation <NUM>, the request decision module <NUM> may obtain one or more signals <NUM>. In some examples, the request decision module <NUM> may obtain the signal(s) <NUM> in response to the content <NUM> of the application 108b being displayed on the display <NUM> (e.g., see <FIG>) and before the user has selected the content <NUM>. In some examples, the request decision module <NUM> may obtain the signal(s) <NUM> in response to the content <NUM> being requested. Then, in operation <NUM>, the request decision module <NUM> may determine whether to pre-launch the application 108a based on the signal(s) <NUM>. In some examples, if the battery charge level <NUM> is below a threshold level (e.g., low battery) and/or if the available memory level <NUM> is below a threshold level (e.g., low available memory), the request decision module <NUM> may determine to not pre-launch the application 108a. In some examples, if the click-through rate <NUM> is below a threshold level and/or if the predicted conversion rate <NUM> is below a threshold level, the request decision module <NUM> may determine to not pre-launch the application 108a.

In some examples, if the battery charge level <NUM> is above a threshold level, the request decision module <NUM> may determine to pre-launch. In some examples, if the available memory level <NUM> is above a threshold level, the request decision module <NUM> may determine to pre-launch. In some examples, if the click-through rate <NUM> is above a threshold level, the request decision module <NUM> may determine to pre-launch. In some examples, if the predicted conversion rate <NUM> is above a threshold level, the request decision module <NUM> may determine to pre-launch. In some examples, if the network condition <NUM> is above a threshold level, the request decision module <NUM> may determine to pre-launch. In some examples, the request decision module <NUM> may use any combination of the above signals <NUM> to determine whether to pre-launch.

In some examples, the request decision module <NUM> inputs the signal(s) <NUM> into a scoring algorithm that generates a pre-launch scoring value, and if the pre-launch scoring value is above a threshold value, the request decision module <NUM> determines to pre-launch the application 108a. In some examples, the request decision module <NUM> may execute a machine learning algorithm that determines whether to pre-launch the application 108a. In some examples, the machine learning algorithm includes a neural network.

If the request decision module <NUM> determines to pre-launch (Yes), in operation <NUM>, the application 108b may transmit the initialization request <NUM>. For example, the application 108b may transmit the initialization request <NUM> to the initialization API <NUM> of the application 108a, which causes the application 108a to be launched as a background process <NUM>. If the request decision module <NUM> determines not to pre-launch (No), in operation <NUM>, the application 108b may not transmit the initialization request <NUM>, which causes the application 108a not to be launched as a background process <NUM>.

<FIG> illustrates example operations of determining whether to pre-launch and prefetch according to an aspect. Referring to <FIG>, in operation <NUM>, the request decision module <NUM> may obtain one or more signals <NUM>. In some examples, the request decision module <NUM> may obtain the signal(s) <NUM> in response to the content <NUM> of the application 108b being displayed on the display <NUM> (e.g., see <FIG>) and before the user has selected the content <NUM>. Then, in operation <NUM>, the request decision module <NUM> may determine whether to pre-launch the application 108a based on the signal(s) <NUM>. The operation <NUM> may be similar to operation <NUM> of <FIG> and may include any of the details discussed with reference to that operation. If the request decision module <NUM> determines not to pre-launch (No), in operation <NUM>, the request decision module <NUM> may not transmit the initialization request <NUM> to the initialization API <NUM>.

If the request decision module <NUM> determines to pre-launch (Yes), in operation <NUM>, the request decision module <NUM> may determine whether to prefetch based on the signal(s) <NUM>. In some examples, the request decision module <NUM> may use the network condition(s) <NUM> to determine whether to prefetch content <NUM>. For example, if a network condition <NUM> (e.g., bandwidth/speed) of the device's connection to the network <NUM> is below a threshold level, the request decision module <NUM> may determine to not prefetch the content <NUM>. However, if the network condition <NUM> is equal to or greater than the threshold level, the request decision module <NUM> may determine to prefetch the content <NUM>. In some examples, the request decision module <NUM> may use another signal <NUM> (or a number of signals <NUM>) to determine whether to prefetch the content <NUM>. For example, the request decision module <NUM> may compare one or more of the signals <NUM> to one or more thresholds, use a scoring algorithm, or use a machine learning algorithm to determine whether to prefetch the content <NUM>.

If the request decision module <NUM> determines not to prefetch (<NUM>, No), in operation <NUM>, the application 108b transmits the initialization request <NUM> to the application 108a, where the initialization request <NUM> indicates to only pre-launch the application 108a. For example, the application 108b may transmit the initialization request <NUM> to the initialization API <NUM> of the application 108a without the prefetch parameter(s) <NUM>. If the request decision module <NUM> determines to prefetch (<NUM>, Yes), in operation <NUM>, the application 108b determines the prefetch parameter(s) <NUM>. The prefetch parameter(s) <NUM> may identify the content <NUM> to be prefetched and/or the source(s) of where the content <NUM> is to be retrieved. In some examples, the prefetch parameter(s) <NUM> includes an identifier of a resource (e.g., product, application, service, etc.) referenced by the content <NUM>. In some examples, the prefetch parameter(s) <NUM> includes an application identifier. In some examples, the prefetch parameter(s) <NUM> include a product or service identifier. In some examples, the prefetch parameter(s) <NUM> include a uniform resource locator (URL).

In operation <NUM>, the application 108b transmits the initialization request <NUM> with the prefetch parameter(s) <NUM> to the initialization API <NUM> of the application 108a. In some examples, separate requests are transmitted for the pre-launching and prefetching. For example, in response to the determination that application 108a should be pre-launched, the application 108b can transmit a first request to the initialization API <NUM>, and, in response to the determination that application 108a should prefetch content <NUM>, the application 108b can transmit a second request to the initialization API <NUM> with the prefetch parameter(s) <NUM>.

In some examples, the signals <NUM> include a user control signal. For example, a user may be able to opt out of pre-launching/prefetching. If the request decision module <NUM> receives a signal that indicates that the user has opted out of pre-launching, the request decision module <NUM> may determine to not transmit the initialization request <NUM> (e.g., to not pre-launch the application 108a). In some examples, the signals <NUM> include a signal that indicates a number of times that the device has pre-launched an application <NUM> over a period of time (e.g., past hour, etc.). If the number of times exceeds a threshold, the request decision module <NUM> may determine to not transmit the initialization request <NUM> (e.g., skip pre-launching/prefetching if the device initiated pre-launching at least X times over the past hour).

Upon receipt of the initialization request <NUM> at the initialization API <NUM> of the application 108a, the application 108a can be pre-launched as a background process <NUM>. Also, in some examples, the initialization request <NUM> may include prefetch parameter(s) <NUM>, which would instruct the application 108a to prefetch and store content <NUM>. In some examples, the application 108b includes a termination decision module <NUM> to determine whether to terminate the background process <NUM> executing the application 108a. For example, if the termination decision module <NUM> determines to terminate the background process <NUM>, the application 108b may transmit a termination request <NUM> to the initialization API <NUM>, which causes the operation system <NUM> to terminate the background process <NUM> that is executing the application 108a. In some examples, the termination request <NUM> causes the application 108b and the application 108a to become un-binded (e.g., interprocess communication connection <NUM> being terminated). In some examples, the termination decision module <NUM> transmits the termination request <NUM> when the content <NUM> is not displayed in the application 108b (e.g., the user has moved the content <NUM> off the screen) or a timer <NUM> has expired. In some examples, the termination decision module <NUM> transmits the termination request <NUM> when the user closes the application 108b. In this manner, memory that has been allocated to the background process <NUM> that is executing the application 108a can be available for other programs since there is a relatively good chance that the user will not select the content <NUM>.

<FIG> illustrates example operations of the termination decision module <NUM>. Referring to <FIG>, the termination decision module <NUM> may execute a process <NUM> and a process <NUM>. In some examples, the process <NUM> is executed in parallel with the process <NUM>.

With respect to process <NUM>, in operation <NUM>, the termination decision module <NUM> determines (e.g., continuously or periodically) whether the content <NUM> is no longer displayed on the display <NUM> (e.g., whether the content has moved off the screen). If the content <NUM> is still displayed on the display <NUM> (No), the termination decision module <NUM> continues to monitor whether the content <NUM> has moved off the display <NUM>. If the content <NUM> is no longer displayed on the display (Yes), in operation <NUM>, the termination decision module <NUM> transmits the termination request <NUM> to the initialization API <NUM> of the application 108a. In response to the receipt of the termination request <NUM> at the initialization API <NUM>, the background process <NUM> that is executing the application 108a is terminated (or closed). In some examples, in response to the receipt of the termination request <NUM> at the initialization API <NUM>, the interprocess communication connection <NUM> is terminated, which causes the background process <NUM> that is executing the application 108a to be terminated. In other words, the interprocess communication connection <NUM> is established in response to the receipt of the initialization request <NUM>, and the interprocess communication connection <NUM> remains active until a termination request <NUM> is received at the initialization API <NUM>. While the interprocess communication connection <NUM> is active, the application 108a and the application 108b can communicate with each other. However, in response to receipt of the termination request <NUM>, the interprocess communication connection <NUM> is deactivated (e.g., terminated), which causes the underlying service (e.g., the pre-launching service) to be terminated.

With respect to process <NUM>, in operation <NUM>, the termination decision module <NUM> determines whether a timer <NUM> has expired. The timer <NUM> may be set to any length of time such as <NUM> seconds, one minute, two minutes, five minutes, etc. The initiation of the timer <NUM> may start in response to the time at which the application <NUM> is pre-launched and/or the time at which the interprocess communication connection <NUM> is established (e.g., created or activated). If the termination decision module <NUM> determines that the timer has not expired (No), the termination decision module <NUM> continues to determine whether the timer has expired. If the termination decision module <NUM> determines that the timer has expired (Yes), in operation <NUM>, the termination decision module <NUM> transmits the termination request <NUM> to the initialization API <NUM> of the application 108a. In response to the receipt of the termination request <NUM> at the initialization API <NUM>, the background process <NUM> that is executing the application 108a is terminated (or closed). Processes <NUM> and <NUM> ensure that system resources consumed by pre-launching application 108a are freed as early as possible, e.g., once a user is no longer likely to or cannot select content <NUM>. This ensures the computing device <NUM> operates efficiently while still reducing latency for loading application 108a if a user does select content <NUM>.

<FIG> illustrates a computing device <NUM> that enables one application (e.g., application 108b) to pre-launch another application (e.g., application 108a) as a background process before the user has selected content <NUM> that requires an action <NUM> of the application 108a. The computing device <NUM> of <FIG> may be an example of the system of <FIG> and may include any of the details discussed with reference to those figures. For example, the application 208a and the application 208a may be examples of the application 108a of <FIG> and the application 108b of <FIG>, respectively.

The application 208a includes an interface definition language <NUM> that defines an initialization API <NUM> (e.g., a pre-launch API) that is used by a calling application (e.g., application 208b) to pre-launch the application 208a in advance of an action taken with respect to content <NUM> of application 208b, where the application 208b is executing as a foreground process of an operating system of the computing device <NUM>. For example, in response to the content <NUM> being displayed on the display <NUM>, the application 208b may call the initialization API <NUM> by transmitting a pre-launch service call <NUM> to the initialization API <NUM>. The pre-launch service call <NUM> may be an example of the initialization request <NUM> of <FIG>.

In further detail, in response to the content <NUM> being displayed on the display <NUM> (or in response to the request decision module <NUM> of <FIG> determining to pre-launch the application 208a), the application 208b may create an intent <NUM> that references the initialization API <NUM> defined in the interface definition language <NUM>. The intent <NUM> may be an abstract description of the pre-launch operation to be performed. Then, the application 208b transmits a pre-launch service call <NUM> to the initialization API <NUM>, where the pre-launch service call <NUM> includes the intent <NUM>, a service connection object <NUM>, and a flag <NUM>. In some examples, the pre-launch service call <NUM> is a bind service method that binds the application 208b to the pre-launch service of the initialization API <NUM>. In some examples, the service connection object <NUM> defines an interface for monitoring the state of the pre-launch service. In some examples, the flag <NUM> is a flag that, when set, automatically creates the pre-launch service as long as the binding exists (e.g., when the interprocess communication connection <NUM> is active).

In response to receipt of the pre-launch service call <NUM>, the application 208a is launched as a background process of the operating system of the computing device <NUM>. Also, in response to receipt of the pre-launch service call <NUM>, the application 208a obtains a binder <NUM> (e.g., a service instance) (defined in the interface definition language) and returns the binder <NUM> to the application 208b. The binder <NUM> may define one or more methods <NUM> that the application 208b uses (e.g., invokes) to transmit information to the application 208a. The interprocess communication connection <NUM> may be established in response to receipt of the binder <NUM>. The interprocess communication connection <NUM> may remain active until an unbind service call <NUM> is received at the initialization API <NUM>, where the unbind service call <NUM> terminates the interprocess communication connection <NUM>. The unbind service call <NUM> may be an example of the termination request <NUM> of <FIG>. During the time the interprocess communication connection <NUM> remains active, the application 208b can invoke a method <NUM> defined by the binder <NUM> to transmit information to the application 208a.

According to the embodiments discussed herein, the unbind service call <NUM> is delayed because application 208a would need to be running by the time the user selects the content <NUM>. For example, the unbind service call <NUM> is delayed until a timer (e.g., timer <NUM> of <FIG>) has expired or the content <NUM> is not displayed in the foreground process. In other words, the application 208b (e.g., the termination decision module <NUM> of <FIG>) determines whether the content <NUM> has moved off the screen or whether a timer has expired, and if the content <NUM> has moved off the screen or the timer has expired, the application 208b transmits the unbind service call <NUM> to terminate the interprocess communication connection <NUM>, which causes the background process that is executing the application 208a to be terminated.

In some examples, before the unbind service call <NUM> is transmitted to the initialization API <NUM> of the application 208a, one or more prefetch parameters <NUM> can be passed to the application 208a by invoking a method <NUM> defined by the binder <NUM>. For example, as indicated above, the application 208a returns a binder <NUM> to the application 208b in response to the pre-launch service call <NUM>, where the binder <NUM> defines one or more methods <NUM> that are invoked by the application 208b to pass information to the application 208a. In some examples, the application 208b uses one or more of the methods <NUM> to call the initialization API <NUM> to provide the application 208a with the prefetch parameter(s) <NUM>.

<FIG> illustrates a computing device <NUM> having an application (e.g., 308b) that can cause two applications (e.g., application 308a, application 308c) to be pre-launched and/or prefetched according to an aspect. The computing device <NUM> may be an example of the computing device <NUM> of <FIG> and/or the computing device <NUM> of <FIG> and may include any of the details discussed with respect to those figures. For example, the computing device <NUM> may include one or more processors <NUM>, one or more memory devices <NUM>, an operating system <NUM>, and applications <NUM> (e.g., application 308a, application 308b, application 308c).

As shown in <FIG>, the application 308b may be executing as a foreground process <NUM>, where the application 308b displays content <NUM> on a display <NUM> of the computing device <NUM>. The content <NUM> may be associated with an action <NUM>-<NUM> of application 308a and with an action <NUM>-<NUM> of application 308c. In some examples, when the content <NUM> of the application 308b is displayed on the display <NUM> (which is before the user has selected the content <NUM>), the application 308b may transmit a first initialization request (e.g., the initialization request <NUM> of <FIG>) to an initialization API <NUM>-<NUM> of the application 308a, and may transmit a second initialization request (e.g., the initialization request <NUM> of <FIG>) to an initialization API <NUM>-<NUM> of the application 308c. The initialization API <NUM>-<NUM> is defined at an interface definition language of the application 308a. The initialization API <NUM>-<NUM> is defined at an interface definition language of the application 308c. In some examples, the second initialization request and the first initialization request are transmitted at least partially in parallel with each other. In some examples, the first initialization request includes one or more prefetching parameters to cause the application 308a to prefetch content. In some examples, the second initialization request includes one or more prefetching parameters to cause the application 308c to prefetch content.

The first initialization request is received at the initialization API <NUM>-<NUM>, which causes the application 308a to be launched as a background process <NUM>. In some examples, the receipt of the first initialization request causes the creation (or establishment) of a first IPC connection <NUM>-<NUM> between the application 308a and application 308b to enable the application 308a and the application 308b to communicate with each other. The second initialization request is received at the initialization API <NUM>-<NUM>, which causes the application 308c to be launched as a background process <NUM>. In some examples, the receipt of the second initialization request causes the creation (or establishment) of a second IPC connection <NUM>-<NUM> between the application 308c and application 308b to enable the application 308c and the application 308b to communicate with each other. Then, when receipt of a user action is taken with respect to the content <NUM>, the application 308a and/or the application 308c may be switched to the display <NUM> in a relatively quick fashion since both of these applications were pre-launched.

<FIG> and <FIG> illustrate a system <NUM> that enables an application (e.g., application 408b) to pre-launch another application (e.g., digital store application 408a) and/or causes the digital store application 408a to prefetch content. The system <NUM> may be an example of the system <NUM> of <FIG>, the computing device <NUM> of <FIG>, and/or the computing device <NUM> of <FIG> and may include any of the details discussed with reference to those figures. For example, the system <NUM> may include a server computer <NUM> having one or more processors <NUM>, one or more memory devices <NUM>, an online digital store <NUM> that stores digital media <NUM> in which users can download and install, and an ad engine <NUM> configured to insert app install content <NUM> into applications. The system <NUM> includes a computing device <NUM> configured to communicate with the server computer <NUM> over a network <NUM>. The computing device <NUM> includes an operating system <NUM> that executes a number of applications <NUM> includes a digital store application 408a and an application 408b.

The application 408b may be displaying app install content <NUM> on the display <NUM> of the computing device <NUM>, where the application 408b is executing as the foreground process <NUM>. For example, the app install content <NUM> may reference another application (e.g., application 408c) that is not installed on the computing device <NUM>, but when selected, causes the operating system <NUM> to launch the digital store application 408a so that the user can download and install the application 408c referenced by the app install content <NUM>. In some examples, the selection of the app install content <NUM> causes an action of launching the digital store application 408a.

In advance of a user action taken with respect to the app install content <NUM> (e.g., before the user selects the ad), the application 408b causes the digital store application 408a to be pre-launched as a background process <NUM> of the operating system <NUM>. The digital store application 408a defines an interface definition language <NUM>. The interface definition language <NUM> defines a programming interface that permits the digital store application 408a to communicate with other applications <NUM> including application 408b. According to the embodiments discussed herein, the interface definition language <NUM> defines an initialization API <NUM> in which a calling application (e.g., application 408b) uses to call the pre-launch service. In other words, the initialization API <NUM> (e.g., also referred to as a pre-launch API) defines a pre-launch interface that can be used by other applications <NUM> (e.g., application 408b) to pre-launch the digital store application 408a as a background process <NUM>.

In some examples, when the app install content <NUM> of the application 408b is displayed on the display <NUM> (which is before the user has selected the app install content <NUM>), the application 408b may transmit an initialization request <NUM> to the digital store application 408a. The initialization request <NUM> is received at the initialization API <NUM>, which causes the digital store application 408a to be launched as a background process <NUM>. In some examples, the receipt of the initialization request <NUM> causes the creation (or establishment) of an interprocess communication (IPC) connection <NUM> between the digital store application 408a and the application 408b to enable the digital store application 408a and the application 408b to communicate with each other.

The IPC connection <NUM> is a communication protocol that allows processes to communicate with each other and synchronize their actions. In some examples, receipt of the initialization request <NUM> binds the digital store application 408a and the application 408b (e.g., the digital store application 408a and the application 408b are linked) so that information can be exchanged between the digital store application 408a and the application 408b. In some examples, the digital store application 408a and the application 408b are linked according to the techniques described with reference to <FIG>. While the interprocess communication connection <NUM> remains active, the digital store application 408a and the application 408b can communicate with each other. In some examples, if the interprocess communication connection <NUM> is terminated (e.g., deactivated), the underlying service (e.g., the pre-launching service) is terminated, thereby causing the background process <NUM> executing the digital store application 408a to be terminated.

Then, when receipt of a user action is taken with respect to the app install content <NUM>, the digital store application 408a may load more quickly, thereby reducing the latency of displaying information associated with the digital store application 408a. For example, when the app install content <NUM> is selected, the digital store application 408a can be quickly loaded into the display <NUM> (in the foreground process <NUM>), where the latency of rendering the digital store application 408a can be reduced (e.g., significantly reduced) because the digital store application 408a is pre-launched as a background process <NUM>.

In some examples, the initialization request <NUM> specifies one or more prefetch parameter(s) <NUM>. In some examples, the prefetch parameter(s) <NUM> may provide an application identifier for application 408c referenced by the app install content <NUM>, and the digital store application 408a may prefetch details about the application 408c such as the name, downloads, ratings, and/or reviews, etc. For example, if the initialization request <NUM> specifies one or more prefetch parameters <NUM>, the digital store application 408a can prefetch content according to the prefetch parameter(s) <NUM> as a background process <NUM> and store (e.g., cache) the content in memory in advance of a user action taken with respect to the app install content <NUM> (e.g., before the user selects the ad). Then, when the user selects the app install content <NUM>, the display <NUM> can be quickly switched to the digital store application 408a (e.g., because the digital store application 408a is pre-launched), where the digital store application 408a quickly displays the prefetched content.

In some examples, the application 408b includes a request decision module <NUM> that determines whether the application 408b should transmit the initialization request <NUM> to the initialization API <NUM> to pre-launch and/or prefetch. In some examples, the request decision module <NUM> determines whether to transmit the initialization request to the initialization API <NUM> based on one or more signals <NUM>. The signals <NUM> may be any of the signals <NUM> described with reference to <FIG>. The request decision module <NUM> may perform any of the operations described with reference to <FIG>.

Upon receipt of the initialization request <NUM> at the initialization API <NUM> of the digital store application 408a, the digital store application 408a can be pre-launched as a background process <NUM>. Also, in some examples, the initialization request <NUM> may include prefetch parameter(s) <NUM>, which would instruct the digital store application 408a to prefetch and store content. In some examples, the application 408b includes a termination decision module <NUM> to determine whether to terminate the background process <NUM> executing the digital store application 408a. For example, if the termination decision module <NUM> determines to terminate the background process <NUM>, the application 408b may transmit a termination request <NUM> to the initialization API <NUM>, which causes the background process <NUM> to be terminated. In some examples, the termination decision module <NUM> transmits the termination request <NUM> when the app install content <NUM> is not displayed in the application 408b (e.g., the user has moved the app install content <NUM> off the screen) or a timer <NUM> has expired. In this manner, memory that has been allocated to the background process <NUM> executing the digital store application 408a can be available for other programs since there is a relatively good chance that the user will not select the app install content <NUM>. The termination decision module <NUM> may perform any of the operations described with reference to the termination decision module <NUM> of <FIG>.

<FIG> is a flowchart <NUM> depicting example operations of pre-launching an application using interprocess communication according to an aspect. Although the flowchart <NUM> of <FIG> is explained with respect to the system <NUM> of <FIG>, the flowchart <NUM> may be applicable to any of the embodiments discussed herein. Although the flowchart <NUM> of <FIG> illustrates the operations in sequential order, it will be appreciated that this is merely an example, and that additional or alternative operations may be included. Further, operations of <FIG> and related operations may be executed in a different order than that shown, or in a parallel or overlapping fashion. The operations of the flowchart <NUM> may be from the perspective of a calling application (e.g., application 108b, application 208b, application 308b, application 408b).

Operation <NUM> includes executing a first application 108b as a foreground process <NUM> of an operating system <NUM> of a computing device <NUM>. Operation <NUM> includes displaying, by the first application 108b, content <NUM> on a display <NUM> of the computing device <NUM>, where the content <NUM> is associated with an action <NUM> executable by a second application 108a. Operation <NUM> includes transmitting, by the first application 108b, an initialization request <NUM> to an initialization application programming interface (API) <NUM> of the second application 108a in advance of a user action taken with respect to the content <NUM> displayed on the display <NUM> of the computing device <NUM>, where the initialization request <NUM> configured to cause the second application 108a to be launched as a background process <NUM> of the operating system <NUM> of the computing device <NUM>.

In some examples, the operations include transmitting, by the first application 108b, a termination request <NUM> to the initialization API <NUM> of the second application 108a in response to the content <NUM> not being displayed on the display <NUM>, where the termination request <NUM> is configured to cause the background process <NUM> that is executing the second application 108a to be terminated.

In some examples, the operations include transmitting, by the first application 108b, a termination request <NUM> to the initialization API <NUM> of the second application 108a in response to an expiration of a timer <NUM>, where the termination request <NUM> configured to cause the background process <NUM> that is executing the second application 108a to be terminated.

In some examples, the initialization request <NUM> is configured to cause an interprocess communication connection <NUM> to be established between the first application 108b and the second application 108a to enable the first application 108b and the second application 108a to communicate with each other.

In some examples, the operations include transmitting, by the first application 108b, a termination request <NUM> to the initialization API <NUM> of the second application 108a in response to the content <NUM> not being displayed on the display <NUM> or in response to an expiration of a timer <NUM>, where the termination request <NUM> is configured to terminate the interprocess communication connection <NUM>.

In some examples, the operations include determining, by the second application 108a, whether to transmit the initialization request <NUM> to the initialization API <NUM> of the second application 108a based on at least one signal <NUM>.

In some examples, the at least one signal <NUM> includes a battery charge level <NUM>, where the initialization request <NUM> is transmitted in response to the battery charge level <NUM> being greater than a threshold level. In some examples, at least one signal <NUM> includes an available memory level <NUM>, where the initialization request <NUM> is transmitted in response to the available memory level <NUM> being greater than a threshold level. In some examples, the at least one signal <NUM> includes a click-through rate <NUM> associated with the content <NUM> displayed by the first application 108b, where the initialization request <NUM> is transmitted in response to the click-through rate <NUM> being greater than a threshold level. In some examples, the at least one signal <NUM> includes a predicted conversion rate <NUM> associated with the content <NUM> displayed by the first application 108b, where the initialization request <NUM> is transmitted in response to the predicted conversion rate <NUM> being greater than a threshold level. In some examples, the at least one signal <NUM> includes a network condition <NUM> of the computing device <NUM>, where the initialization request <NUM> is transmitted in response to the network condition <NUM> being greater than a threshold level. In some examples, the initialization request <NUM> includes at least one prefetching parameter <NUM> to enable the first application 108b to prefetch content <NUM> over a network <NUM> from a server computer <NUM> as a background process <NUM>.

<FIG> is a flowchart <NUM> depicting example operations of pre-launching an application using interprocess communication according to an aspect. Although the flowchart <NUM> of <FIG> is explained with respect to the computing device <NUM> of <FIG>, the flowchart <NUM> may be applicable to any of the embodiments discussed herein. Although the flowchart <NUM> of <FIG> illustrates the operations in sequential order, it will be appreciated that this is merely an example, and that additional or alternative operations may be included. Further, operations of <FIG> and related operations may be executed in a different order than that shown, or in a parallel or overlapping fashion. The operations of the flowchart <NUM> may be from the perspective of a calling application (e.g., application 108b, application 208b, application 308b, application 408b).

Operation <NUM> includes receiving a pre-launch service call <NUM>. For example, the initialization API <NUM> of the application 208a receives the pre-launch service call <NUM> from the application 208b in response to the determination that the application 208a would be pre-launched (which is in advance of a user action taken with respect to content <NUM> of an application 208b displayed on a display <NUM> of a computing device <NUM>. In some examples, the pre-launch service call <NUM> includes the intent <NUM>, the service connection object <NUM>, and the flag <NUM>. In some examples, receipt of the pre-launch service call <NUM> causes the application 208a to be pre-launched.

Operation <NUM> includes transmitting a service instance (e.g., a binder <NUM>), where the service instance (e.g., the binder <NUM>) includes one or more methods <NUM> to be used by an application (e.g., application 208a) to call the initialization API <NUM>. In some examples, receipt of the service instance causes the interprocess communication connection <NUM> to be established where the application 208a and the application 208b can communicate with each other while the interprocess communication connection <NUM> is active.

Operation <NUM> includes initiating a timer (e.g., timer <NUM> of <FIG>) associated with the interprocess communication connection <NUM>. In some examples, the timer is initiated when the interprocess communication connection <NUM> is established. In some examples, the timer defines a duration which can be any value such as <NUM> seconds, one minute, two minutes, <NUM> minutes, etc..

Operation <NUM> includes determining whether the content <NUM> has moved off the screen or whether the timer has expired. For example, the application 208b monitors the timer and whether the content <NUM> is still displayed on the display <NUM> or whether it is no longer being displayed. If no, the process returns to operation <NUM> to continue to determine whether the content <NUM> has moved off the screen or whether the timer has expired. If yes, the process continues to operation <NUM>.

Operation <NUM> includes terminating the interprocess communication connection <NUM>. In some examples, the application 208b transmits an unbind service call <NUM> to the initialization API <NUM>, which causes the background process that is executing the application 208b to be terminated.

<FIG> is a flowchart <NUM> depicting example operations of pre-launching an application using interprocess communication according to an aspect. Although the flowchart <NUM> of <FIG> is explained with respect to the system <NUM> of <FIG>, the flowchart <NUM> may be applicable to any of the embodiments discussed herein. Although the flowchart <NUM> of <FIG> illustrates the operations in sequential order, it will be appreciated that this is merely an example, and that additional or alternative operations may be included. Further, operations of <FIG> and related operations may be executed in a different order than that shown, or in a parallel or overlapping fashion. The operations of the flowchart <NUM> are from the perspective of a linked application (e.g., application 108a, application 208a, application 308a, digital store application 408a).

Operation <NUM> includes receiving, at an initialization application programming interface (API) <NUM> of a first application 108a, an initialization request <NUM> from a second application 108b that is executing as a foreground process <NUM> of an operating system <NUM> of a computing device <NUM> in advance of a user action taken with respect to content <NUM> displayed on a display <NUM> of the computing device <NUM>.

Operation <NUM> includes establishing, in response to the initialization request <NUM>, an interprocess communication connection <NUM> between the first application 108a and the second application 108b to enable the first application 108a and the second application 108b to communicate with each other. Operation <NUM> includes launching, in response to the initialization request <NUM>, the first application 108a as a background process <NUM> of the operating system <NUM> of the computing device <NUM>.

Although the disclosed inventive concepts include those defined in the attached claims, it should be understood that the inventive concepts can also be defined in accordance with the following embodiments:.

<FIG> shows an example of a computer device <NUM> and a mobile computer device <NUM>, which may be used with the techniques described here. In some implementations, the computer device <NUM> is an example of the computing device <NUM>, the computing device <NUM>, the computing device <NUM>, or the computing device <NUM>. In some implementations, the computer device <NUM> is an example of the server computer <NUM>. In some implementations, the mobile computer device <NUM> is an example of the computing device <NUM>, the computing device <NUM>, the computing device <NUM>, or the computing device <NUM>. Computing device <NUM> is intended to represent various forms of digital computers, such as laptops, desktops, tablets, workstations, personal digital assistants, televisions, servers, blade servers, mainframes, and other appropriate computing devices. Computing device <NUM> is intended to represent various forms of mobile devices, such as personal digital assistants, cellular telephones, smartphones, and other similar computing devices.

The processor <NUM> can be a semiconductor-based processor. The memory <NUM> can be a semiconductor-based memory. Also, multiple computing devices <NUM> may be connected, with each device providing portions of the necessary operations (e.g., as a server bank, a group of blade servers, or a multiprocessor system).

Each of such devices may contain one or more of computing devices <NUM>, <NUM>, and an entire system may be made up of multiple computing devices <NUM>, <NUM> communicating with each other.

Thus, for example, expansion memory <NUM> may be provided as a security module for device <NUM>, and may be programmed with instructions that permit secure use of device <NUM>.

The information carrier is a computer- or machine-readable medium, such as the memory <NUM>, expansion memory <NUM>, or memory on processor <NUM> that may be received, for example, over transceiver <NUM> or external interface <NUM>.

In addition, short-range communication may occur, such as using a Bluetooth, Wi-Fi, or other such transceiver (not shown).

It may also be implemented as part of a smart phone <NUM>, personal digital assistant, or another similar mobile device.

Further to the descriptions above, a user may be provided with controls allowing the user to make an election as to both if and when systems, programs or features described herein may enable collection of user information (e.g., information about a user's social network, social actions or activities, profession, a user's preferences, or a user's current location), and if the user is sent content or communications from a server. In addition, certain data may be treated in one or more ways before it is stored or used, so that personally identifiable information is removed. For example, a user's identity may be treated so that no personally identifiable information can be determined for the user, or a user's geographic location may be generalized where location information is obtained (such as to a city, ZIP code, or state level), so that a particular location of a user cannot be determined. Thus, the user may have control over what information is collected about the user, how that information is used, and what information is provided to the user.

In this specification and the appended claims, the singular forms "a," "an" and "the" do not exclude the plural reference unless the context clearly dictates otherwise. Further, conjunctions such as "and," "or," and "and/or" are inclusive unless the context clearly dictates otherwise. For example, "A and/or B" includes A alone, B alone, and A with B. Further, connecting lines or connectors shown in the various figures presented are intended to represent exemplary functional relationships and/or physical or logical couplings between the various elements. Many alternative or additional functional relationships, physical connections or logical connections may be present in a practical device. Moreover, no item or component is essential to the practice of the embodiments disclosed herein unless the element is specifically described as "essential" or "critical".

Terms such as, but not limited to, approximately, substantially, generally, etc. are used herein to indicate that a precise value or range thereof is not required and need not be specified. As used herein, the terms discussed above will have ready and instant meaning to one of ordinary skill in the art.

Moreover, use of terms such as up, down, top, bottom, side, end, front, back, etc. herein are used with reference to a currently considered or illustrated orientation. If they are considered with respect to another orientation, it should be understood that such terms must be correspondingly modified.

Further, in this specification and the appended claims, the singular forms "a," "an" and "the" do not exclude the plural reference unless the context clearly dictates otherwise. Moreover, conjunctions such as "and," "or," and "and/or" are inclusive unless the context clearly dictates otherwise. For example, "A and/or B" includes A alone, B alone, and A with B.

Claim 1:
A method for pre-launching an application using interprocess communication, the method comprising:
executing (<NUM>) a first application (108b) as a foreground process (<NUM>) of an operating system (<NUM>) of a computing device (<NUM>);
displaying (<NUM>), by the first application (108b), content (<NUM>) on a display (<NUM>) of the computing device (<NUM>), the content (<NUM>) being associated with an action (<NUM>) executable by a second application (108a); and
transmitting (<NUM>), by the first application (108b), an initialization request (<NUM>) to an initialization application programming interface, API (<NUM>), of the second application (108a) in advance of a user action taken with respect to the content (<NUM>) displayed on the display (<NUM>),
the initialization request (<NUM>) configured to establish an interprocess communication connection (<NUM>) between the first application (108b) and the second application (108a) to enable the first application (108b) and the second application (108a) to communicate with each other, and to cause the second application (108a) to be launched as a background process (<NUM>) of the operating system (<NUM>) of the computing device (<NUM>),
characterized in that, in response to the interprocess communication connection (<NUM>) being established, the foreground process (<NUM>) binds to the background process (<NUM>) so that the background process (<NUM>) is given, by the operating system (<NUM>), a memory priority that corresponds to a memory priority of the foreground process (<NUM>).