Patent Description:
The present description relates generally to adaptive in-application messaging, including providing for adaptive in-application messaging to suggest features and/or content of an application to a user based on the user's interactions with the application.

An application may provide for in-application messaging to users. In in-application messaging, messages can be displayed to users within the application. <CIT> discloses an apparatus and method for providing a streaming banner promoting one or more items/content on mobile devices. User activity information is determined based on a user interfacing with a mobile device. <CIT> discloses that filtering rules for incoming messages can be dynamically generated by a message management service based on patterns in the user's behavior.

As noted above, in in-application messaging, a message is displayed within an application for a user to view. For example, a user may receive an in-application message suggesting a feature and/or content of the application, for increased user engagement with the application. It may be desirable for an in-application message to be displayed at an appropriate time, when the user is more likely to engage in the suggested feature and/or content.

The subject system provides for adaptive in-application messaging in which message content and and/or rules for when to display the message content can be pre-defined (e.g., by a message administrator), so that the message can be adaptively provided to the user. Using a music streaming application as an example, an administrator may wish to provide a message suggesting the user to add music to his/her music library. The administrator may create content for the message, and may further specify rules for when the message is to be displayed within the application. For example, the rules may state that the message is to be displayed for a user who has no music in his/her library, and after that user has streamed a predefined amount of songs (e.g., eight songs).

Thus, the user's device may receive the message (e.g., to add music to his/her library), together with the rule specifying when the message is to be displayed (e.g., when the user has no songs in his/her library, and has eight streamed songs). The device may store the message and the rule in local memory, and evaluate user interaction with respect to the application. When the user activity performed with respect to the application satisfies the rule, the device may adaptively retrieve the message from memory and display the message in association with the application (e.g., as a banner or a modal window).

By virtue of allowing rules corresponding to user interaction to be pre-defined (e.g., by an administrator), it is possible to adaptively display a message to a user at a time which is appropriate and/or helpful to the user. Moreover, by storing the message in local memory (as opposed to downloading the message at the time when the condition is met), it is possible to reduce wait time when displaying the message, thereby increasing the likelihood that the user may engage in the feature and/or content suggested by the message.

<FIG> illustrates an example network environment for providing in-application messaging in accordance with one or more implementations. Not all of the depicted components may be used in all implementations, however, and one or more implementations may include additional or different components than those shown in the figure. Variations in the arrangement and type of the components may be made. Additional components, different components, or fewer components may be provided.

The network environment <NUM> includes electronic devices <NUM>, <NUM>, <NUM> and <NUM> (hereinafter <NUM>-<NUM>), a network <NUM> and a server <NUM>. The network <NUM> may communicatively (directly or indirectly) couple, for example, any two or more of the electronic devices <NUM>-<NUM> and the server <NUM>. In one or more implementations, the network <NUM> may be an interconnected network of devices that may include, and/or may be communicatively coupled to, the Internet. For explanatory purposes, the network environment <NUM> is illustrated in <FIG> as including electronic devices <NUM>-<NUM> and a single server <NUM>; however, the network environment <NUM> may include any number of electronic devices and any number of servers.

One or more of the electronic devices <NUM>-<NUM> may be, for example, a portable computing device such as a laptop computer, a smartphone, a smart speaker, a peripheral device (e.g., a digital camera, headphones), a tablet device, a wearable device such as a smartwatch, a band, and the like, or any other appropriate device that includes, for example, one or more wireless interfaces, such as WLAN radios, cellular radios, Bluetooth radios, Zigbee radios, near field communication (NFC) radios, and/or other wireless radios. In <FIG>, by way of example, the electronic device <NUM> is depicted as a smartphone, the electronic device <NUM> is depicted as a laptop computer, the electronic device <NUM> is depicted as a smartwatch, and the electronic device <NUM> is depicted as a smart speaker.

The electronic devices <NUM>-<NUM> may be configured to communicate or otherwise interact with the server <NUM>, for example, to receive messages for displaying within an application, and/or rule(s) for when to display the messages. For example, the rule(s) may specify condition(s) to be satisfied prior to displaying the messages. Each of the electronic devices <NUM>-<NUM> may be, and/or may include all or part of, the device discussed below with respect to <FIG>, and/or the electronic system discussed below with respect to <FIG>.

The server <NUM> may be, and/or may include all or part of the electronic system discussed below with respect to <FIG>. The server <NUM> may include one or more servers, such as a cloud of servers, that may be used to provide messages and/or rules for displaying the messages to one of more of the electronic devices <NUM>-<NUM>. For explanatory purposes, a single server <NUM> is shown and discussed with respect to various operations. However, these and other operations discussed herein may be performed by one or more servers, and each different operation may be performed by the same or different servers.

<FIG> illustrates an example device that may implement a system for providing in-application messaging in accordance with one or more implementations. For explanatory purposes, <FIG> is primarily described herein with reference to the electronic device <NUM>. However, <FIG> may correspond to any of the electronic devices <NUM>-<NUM> of <FIG>. Not all of the depicted components may be used in all implementations, however, and one or more implementations may include additional or different components than those shown in the figure. Variations in the arrangement and type of the components may be made. Additional components, different components, or fewer components may be provided.

The electronic device <NUM> may include a processor <NUM>, a memory <NUM>, and a communication interface <NUM>. The processor <NUM> may include suitable logic, circuitry, and/or code that enable processing data and/or controlling operations of the electronic device <NUM>. In this regard, the processor <NUM> may be enabled to provide control signals to various other components of the electronic device <NUM>. The processor <NUM> may also control transfers of data between various portions of the electronic device <NUM>. Additionally, the processor <NUM> may enable implementation of an operating system or otherwise execute code to manage operations of the electronic device <NUM>.

The memory <NUM> may include suitable logic, circuitry, and/or code that enable storage of various types of information such as received data, generated data, code, and/or configuration information. The memory <NUM> may include, for example, random access memory (RAM), read-only memory (ROM), flash, and/or magnetic storage.

In one or more implementations, the memory <NUM> may store one or more messages (e.g., received from the server <NUM>) for displaying within respective application(s) running on the electronic device <NUM>. The memory <NUM> may further store rules (e.g., received from the server <NUM>) specifying conditions to be satisfied prior to displaying the one or more messages within the application(s).

The communication interface <NUM> may include suitable logic, circuitry, and/or code that enables wired or wireless communication, such as between any of the electronic devices <NUM>-<NUM> and the server <NUM> over the network <NUM>. The communication interface <NUM> may include, for example, one or more of a Bluetooth communication interface, a cellular interface, an NFC interface, a Zigbee communication interface, a WLAN communication interface, a USB communication interface, or generally any communication interface.

In one or more implementations, one or more of the processor <NUM>, the memory <NUM>, the communication interface <NUM>, and/or one or more portions thereof, may be implemented in software (e.g., subroutines and code), may be implemented in hardware (e.g., an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a Programmable Logic Device (PLD), a controller, a state machine, gated logic, discrete hardware components, or any other suitable devices) and/or a combination of both.

<FIG> illustrates an example architecture of a system for in-application messaging in accordance with one or more implementations. For explanatory purposes, <FIG> is primarily described herein with reference to the electronic device <NUM>. However, <FIG> may correspond to any of the electronic devices <NUM>-<NUM> of <FIG>. The electronic device <NUM> may implement a daemon <NUM> for storing events <NUM>, messages <NUM> and resources <NUM>. The electronic device <NUM> may further implement an in-application messaging framework <NUM> for an application <NUM> running on the electronic device <NUM>. The daemon <NUM>, the application <NUM> and/or the in-application messaging framework <NUM> may be implemented by one or more software modules running on the processor <NUM> of the electronic device <NUM>. In another example, the daemon <NUM>, the application <NUM> and/or the in-application messaging framework <NUM> can be implemented by custom hardware (e.g., one or more coprocessors) configured to execute respective functions.

Moreover, <FIG> illustrates an analytic events service <NUM>, a message content service <NUM> and a message framework service <NUM> (the services <NUM>-<NUM>). The services <NUM>-<NUM> may be implemented by the server <NUM> (e.g., such that the services <NUM>-<NUM> run on the same server <NUM>) and/or by other servers (e.g., such that the services <NUM>-<NUM> share and/or run on different servers). Not all of the components depicted in <FIG> may be used in all implementations, and one or more implementations may include additional or different components than those shown in the figure. Variations in the arrangement and type of the components may be made. Additional components, different components, or fewer components may be provided.

In one or more implementations, the daemon <NUM> may correspond to a process (e.g., a background process) running on the electronic device <NUM>, for storing messages <NUM> to be displayed within the application <NUM>, records of events <NUM> associated with the respective application <NUM>, and/or resources <NUM> (e.g., videos, images or other content) to obtain for displaying with the message. In one or more implementations, the events <NUM>, the messages <NUM> and/or the resources <NUM> may be sandboxed (e.g., with respect to the application <NUM>).

Moreover, the application <NUM> may include and/or otherwise interface with an in-application messaging framework <NUM>. The in-application messaging framework <NUM> may be configured to evaluate the rules/conditions for displaying messages against events generated by the application <NUM>. The in-application messaging framework <NUM> may further be configured to store the state of the messages <NUM>, such that the state is maintained when the application <NUM> is running and not running (e.g., the state is maintained across multiple executions of the application <NUM>). In addition, the in-application messaging framework <NUM> may be configured to provide views to display the various types of messages <NUM>, and to report the events <NUM> back to the server <NUM> after the messages <NUM> are shown.

As shown in <FIG>, the electronic device <NUM> may communicate with the analytic events service <NUM>, the message content service <NUM> and the message framework service <NUM>. The analytic events service <NUM> may be configured to receive and/or store indications of events (e.g., the events <NUM>), such as user interactions within the application <NUM>. In one or more implementations, the analytic events service <NUM> may receive event data from the applications of multiple devices (e.g., the electronic devices <NUM>-<NUM>) corresponding to multiple users. User identifying information may be removed from the event data so as to maintain user anonymity and preserve user privacy. The analytic events service <NUM> may store the analytic events data, for providing to the message content service <NUM>.

The message content service <NUM> may be configured to receive the analytic events data from the analytic events service <NUM>, with respect to determining new rules and/or modifying existing rules that specify when messages (e.g., the messages <NUM>) should be displayed. In one or more implementations, the rules may be defined by an administrator (e.g., a member of a business development team for the application and/or a machine learning model) who determines the conditions for when the messages should be displayed. Thus, the message content service <NUM> may store and/or maintain the messages (e.g., the messages <NUM>) for sending to the electronic device <NUM>, together with the rules specifying the conditions for displaying the messages. The message content service <NUM> may be configured to send the messages and/or rules to the electronic device <NUM>, for local storage thereon. For example, the message content service <NUM> may provide for push notifications with respect to the messages, such that notifications of new messages and/or updates to existing messages are pushed to the electronic device <NUM>. Alternatively or in addition, the message content service <NUM> may provide for message updates on a periodic basis.

The message framework service <NUM> may store and/or maintain one or more templates to be used when displaying respective messages. For example, the template(s) may indicate various parameters for display of message content including, but not limited to, formatting, size, style and shape of the message content (e.g., text, images). In this way, it is possible for different messages (e.g., for display within different applications) to be presented in appropriate manners within their respective applications.

In one or more implementations, one or more of the daemon <NUM>, the application <NUM>, the in-application messaging framework <NUM>, the analytic events service <NUM>, the message content service <NUM> and/or the message framework service <NUM> are implemented via software instructions, stored in memory, which when executed by respective processor(s), cause the processor(s) to perform particular function(s).

In one or more implementations, one or more of the daemon <NUM>, the application <NUM>, the in-application messaging framework <NUM>, the analytic events service <NUM>, the message content service <NUM> and/or the message framework service <NUM> may be implemented in software (e.g., subroutines and code) and/or hardware (e.g., an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a Programmable Logic Device (PLD), a controller, a state machine, gated logic, discrete hardware components, or any other suitable devices) and/or a combination of both. In one or more implementations, some or all of the depicted components may share hardware and/or circuitry, and/or one or more of the depicted components may utilize dedicated hardware and/or circuitry. Additional features and functions of these modules according to various aspects of the subject technology are further described in the present disclosure.

<FIG> illustrates an example process for providing in-application messaging in accordance with one or more implementations. For explanatory purposes, the process <NUM> is primarily described herein with reference to the electronic device <NUM> of <FIG>. However, the process <NUM> is not limited to the electronic device <NUM> of <FIG>, and one or more blocks (or operations) of the process <NUM> may be performed by one or more other components of the electronic device <NUM> and other suitable devices (e.g., any of the electronic devices <NUM>-<NUM>). Further for explanatory purposes, the blocks of the process <NUM> are described herein as occurring in serial, or linearly. However, multiple blocks of the process <NUM> may occur in parallel. In addition, the blocks of the process <NUM> need not be performed in the order shown and/or one or more blocks of the process <NUM> need not be performed and/or can be replaced by other operations.

As noted above, the analytic events service <NUM> may receive and/or store event data (e.g., in an anonymized form) from the applications of multiple devices corresponding to multiple different users. For example, the analytic events service <NUM> may receive this data from respective daemons of the electronic devices. In one or more implementations, the users of the electronic devices may opt-in and/or consent to the use of the analytic data. At operation <NUM>, the analytic events service <NUM> provides the analytic events data to the message content service <NUM>.

The message content service <NUM> may provide for evaluation of the analytic events data (e.g., by providing a user interface to an administrator), in order to define rules specifying the conditions for displaying messages. A rule may define a number of times that a predefined user action is to be performed before displaying a given message. Alternatively or in addition, a rule may define a predetermined sequence of user actions to be performed before displaying the message. The subject system may provide for the administrator to define simple rules (e.g., a user interaction reaching a predefined count value) and/or compound rules (e.g., relating to multiple based counts, nested rules and/or predefined sequences of user interactions).

The predefined user actions may include but are not limited to, the user consuming content (e.g., streaming a song, playing a video, viewing an image, viewing an article/page, scrolling to particular portion of an article/page), adding content to a user's library (e.g., adding a song, video or image to a library), downloading and saving content (e.g., downloading and saving a song, video or image) and/or performing another type of function (e.g., with respect to content). The rules may define a number of times (e.g., X times) that a predefined action is performed, and/or a sequence of actions to be performed (e.g., performing a first action X times, a second action Y times, and a third action Z times) to trigger the display of a message.

For example, the application <NUM> may be an application for streaming music, and the given message may relate to suggesting that music be added to a user's library (e.g., for saving and/or cataloging music for the user). The rule may specify that the message may be displayed if the user has streamed eight songs (e.g., in full) and does not have any songs within his/her music library. On the next playback of a song, album, playlist and/or radio station, the rule may indicate that the message be displayed.

In another example, the message may relate to suggesting that a playlist be created. The rule may specify that the message be displayed if the user's playlist does not contain any songs (e.g., from a streaming catalog) or the user's library does not contain any playlists created by the user, and the library includes at least eighteen add events (e.g., songs, albums and/or playlists) from the streaming catalog. On the next playback of a song, album, playlist and/or radio station, the rule may indicate that the message be displayed.

In another example, the message may relate to suggesting that music be downloaded (e.g., saved offline). The rule may specify that the message be displayed if the user's library contains no music saved for offline playback, and the library includes at least eight add events (e.g., songs, albums and/or playlists) from the streaming catalog. On the next playback of a song, album, playlist and/or radio station, the rule may indicate that the message be displayed.

In one or more implementations, the subject system may provide for global rules that apply to all messages and/or predefined groups of messages (e.g., messages for music streaming). For example, the global rules may set a limit on the number of messages displayed to a user over a given time period (e.g., two messages per day). In this manner, a message that is ready for display (e.g., based on satisfying a first rule), but for which the displaying would violate a global rule, may be queued for display at a later time (e.g., when the time period defined by the global rule expires).

In one or more implementations, the message content service <NUM> may be updated to include new messages and/or rule(s). Alternatively or in addition, the message content service <NUM> may be updated to include changes to existing messages and/or rules (e.g., in the form of updated message content and/or changes to the rules for displaying the messages). The message content service <NUM> may be configured to provide a push notification for messages and rules as updates occur (e.g., new or updated messages and/or rules). Thus, at operation <NUM>, the message content service <NUM> sends a push notification to the daemon <NUM>, where the push notification indicates that one or more messages and/or rules have changed. The push notification includes a revision number (e.g., an identifier) for the message.

In response, the daemon <NUM> may send a request to the message content service <NUM>, for the updated message(s) and/or rule(s) corresponding to the revision number (<NUM>). In response, the message content service <NUM> may return the updated messages and/or rules to the daemon <NUM> (<NUM>). The updated messages may include a parameter for message type (e.g., modal, banner and/or native, which is described below with respect to <FIG>).

As noted above, the daemon <NUM> may correspond to a process (e.g., a background process) running on the electronic device <NUM>, for storing messages <NUM> to be displayed within the application <NUM>, records of events <NUM> associated with the respective application <NUM>, and/or resources <NUM> (e.g., videos, images or other content) to obtain for displaying with the message. Thus, in response to receiving the message update, the daemon <NUM> may store the update (e.g., as a new message/rule, or to replace an existing message/rule) as part of the messages <NUM>.

At operation <NUM>, the application <NUM> may instantiate the in-application messaging framework <NUM> (e.g., when the application is opened). As noted above, the in-application messaging framework <NUM> may be configured to: evaluate the rules/conditions for displaying messages against events generated by the application <NUM>; store the state of the messages <NUM> (e.g., when the application is running and not running); provide views to display the various types of the messages <NUM>; and report the events <NUM> back to the analytic events service <NUM>.

At operation <NUM>, the in-application messaging framework <NUM> requests the messages corresponding to the application <NUM> from the daemon <NUM>. For example, a set of messages and associated rules for the application <NUM> may be identified by a bundle identifier. Thus, the request provided by the in-application messaging framework <NUM> to the daemon <NUM> may include the bundle identifier. In response to the request, the daemon <NUM> may return the messages <NUM> and corresponding rules for when the to display the messages (<NUM>).

While the user interacts with the application <NUM>, the application <NUM> may generate analytic events (e.g., the user playing a song, the user adding a song to his/her library) corresponding to the user interaction. The application <NUM> may provide these analytic events to the in-application messaging framework <NUM> (<NUM>).

The in-application messaging framework <NUM> receives the events and evaluates the events against the rules (<NUM>). The in-application messaging framework <NUM> may also send periodic updates on the stored state of a message (e.g., a count for particular user actions) to the daemon <NUM>. In turn, the daemon <NUM> may send an indication of the analytic events to the analytics events service <NUM> (<NUM>). The analytics events service <NUM> may store an indication of the analytic events, for example, for subsequent evaluation by an administrator with respect to creating and/or updating rules for triggering the display of messages.

In one or more implementations, the in-application messaging framework <NUM> may pre-fetch resources that were not included with the payload of a message. For example, the resources <NUM> may correspond to content (e.g., videos, images or other content) for display with the original message that was not included with the original message. The in-application messaging framework <NUM> may determine that a predefined portion (or percentage) of the rule has been satisfied (e.g., reaching a count of <NUM> of the <NUM> user action needed to trigger display of a message). Based on satisfying the predefined portion, the in-application messaging framework <NUM> may request the content that will be displayed with the message. By pre-fetching the content in this manner, it is possible to reduce wait time in displaying the message once the triggering event for the message occurs.

In a case where the analytic events trigger the display of the message (e.g., by reaching the predefined count and/or a sequence of user actions), the in-application messaging framework <NUM> may request a template for displaying the message from the message framework service <NUM> (<NUM>). The request may include an identifier of the message, for reference by the message framework service <NUM>. The template(s) may indicate various parameters for display of message content including, but not limited to, formatting, size, style and shape of the message content (e.g., text, images).

The message framework service <NUM> returns the template for the message (<NUM>). The in-application messaging framework may populate the template with the respective message content (e.g., a suggestion for user interaction, such as adding a song to the library), based on the message type (e.g., modal, banner and/or native, discussed below with respect to <FIG>) for display within the application <NUM> (<NUM>). After being displayed, the electronic device <NUM> may clear the message from the messages <NUM> (e.g., corresponding to clearing the message from local cache).

When presented with a message (e.g., suggesting a feature or content of the application for the user to engage in), the application <NUM> may continue to provide analytic events corresponding to user interaction to the in-application messaging framework <NUM>. Thus, at operations <NUM>-<NUM>, the in-application messaging framework <NUM> provides update(s) of the message state from all messages and analytic events from user interaction with the message to the daemon <NUM> (<NUM>). The daemon <NUM> stores the message state and provides a report of the message state to the message content service <NUM> (<NUM>). The message content service <NUM> receives the analytic events and provides them to the analytic events service <NUM> (<NUM>).

In one or more implementations, the analytic events may indicate that the user proceeded with engaging in the feature and/or content suggested by the message (e.g., by adding a song to his/her library after suggested to by the message). Such interaction by the user may indicate that the message was appropriate and/or helpful for the user. On the other hand, the analytic events may indicate that the user did not proceed with engaging in the suggested feature and/or content, thereby suggesting that the message was not appropriate and/or helpful for the user.

As noted above, the analytic events service <NUM> may receive the analytic events (e.g., in an anonymous manner) across multiple devices of multiple users. By evaluating user interactions across multiple users, it may be possible to determine when messages are appropriate and/or helpful (e.g., based on a predetermined number and/or ratio of users engaging in the suggested features/content). An administrator may be able to delete messages, update messages and their rules and/or create new messages and/or rules based on the analytic events evaluated across the multiple users. In one or more implementations, the administrator may correspond to a machine learning model, which is updated based on analytic event data. Thus, the machine learning model may automatically delete messages, update messages and their rules and/or create new messages and/or rules based on the analytic events (e.g., across multiple users).

A user account may be associated with more than one electronic device. For example, the user may have logged into the electronic device <NUM> via a user account ID, and may have used the same user account ID to log into other electronic devices (e.g., one of more of the electronic devices <NUM>-<NUM>).

In one or more implementations, message state (e.g., counts) are not synchronized across the electronic devices associated with the same user account. For example, if a user streamed a device five times at the electronic device <NUM> and three times at the electronic device <NUM>, separate counts (e.g., five and three) may be maintained at each of the respective devices <NUM>-<NUM>. Alternatively, message state (e.g., counts) may be synchronized across the electronic devices associated with the same user account (e.g., where the separate counts of five and three are added to total eight on each of the electronic devices <NUM>-<NUM>).

In one or more implementations, in receiving the message at the electronic device <NUM> (<NUM>), it may be redundant and/or undesirable for the user to receive the same message at one of the other electronic devices logged into the same user account. At operation <NUM>, the message content service <NUM> may send a notification (e.g., a push notification) that causes the message to not be displayed on the other electronic devices of the user. For example, the message content service <NUM> may provide an update which deletes the message as stored locally on the other electronic devices (e.g., by clearing the message from cache), and/or which modifies the rule to indicate that the message is not to be displayed. The other electronic devices may receive the update, such that the message will no longer be displayed at the other electronic devices.

The subject system provides that in-application messages may be controlled by a series of commands. The commands may be sequential in nature and prepare the various message capable applications to activate or deactivate banners of various shapes and sizes at pre-defined on-screen locations.

Commands may be delivered by pushes (e.g., silent pushes) to push-capable platforms or they may be polled by platforms lacking this support. In one or more implementations, client devices may be expected to maintain state both in terms of the specific banners activated and the serial number of the last command received. Where state is lost or corrupted, a client my drop all active banners and request to be brought back up to date with the expected state.

One or more services may be provided to verify the latest command serial number, and/or to fill in any gaps when the server state is different from the client state or, indeed, if the client is explicitly re-building state from scratch.

In one or more implementations, commands may not cause focus to switch within applications or for applications to be launched. Rather, they may simply indicate what optional banners will be displayed in pre-defined positions if a user naturally arrives at that destination.

Tables <NUM> and <NUM> below describe examples of command content that may be used in association with in-application messaging as described herein. For example, each command may include the fields shown in Table <NUM>.

Moreover, the payload may include the fields shown in Table <NUM>.

With respect to above Tables <NUM> and <NUM>, in one or more implementations: the client may be required to honor the various usage instructions, maintain counts of banner usage and the like; carousel and priority banners may not be mixed; the whole banner location should honor the usage instructions of the most recently received command for that location; the template may typically exist in-cache on-device and be re-used extensively across banners; the parameters supplied may vary according to template, but will typically include wording (e.g., language-based words), links, changes to color or style and/or references to image resources; where a template expects more parameters than are supplied, the client should may consider the banner corrupt and discard it.

In one or more implementations, the combined use of shared templates and (e.g., if applicable) silent pushes may be intended to result in a situation whereby the client is able to render new banners purely from client held data and not require a new server round-trip.

In one or more implementations, example services may include: serial check - returns the current command serial number so the client can determine whether it is up to date (e.g., this data may be appended to an existing service so as not to necessitate additional round trips in the case of push-capable clients); update (form version number) - fills in all the missing commands (e.g., adds and removes) since the supplied serial number; reset - returns all add commands necessary to restore a blank client to latest state.

In one or more implementations, a client may elect to restore fully periodically as a safeguard against server drift. The client may also be expected to (e.g., fully) restore to do so by a command. Templates and images may be treated as static resources and subject to content delivery network (CDN) caches.

<FIG> illustrate example user interfaces for displaying an in-application message in accordance with one or more implementations. For explanatory purposes, <FIG> are primarily described herein with reference to the electronic device <NUM>. However, <FIG> may correspond to any of the electronic devices <NUM>-<NUM> of <FIG>.

As noted above, the message may have a message type corresponding to modal, banner and/or native, for example. <FIG> illustrates an example user interface in which an in-application message is a modal message <NUM>. In one or more implementations, the modal message <NUM> is a message that disables a main window <NUM> of an application (e.g., the application <NUM>). In the example of <FIG>, the modal message <NUM> disables the main window <NUM> of an application "App ABC" while displayed. The main window <NUM> may include image data (e.g., app image <NUM>) and/or other application content (e.g., app content lines <NUM>-N). Although disabled by display of the modal message <NUM>, the main window <NUM> may be visible in the background.

The modal message <NUM> may include image data (e.g., a modal message image <NUM>) and/or other message content. The modal message <NUM> may be displayed in a partial screen mode or a full screen mode. Moreover, the modal message <NUM> may require user interaction before enabling the main window <NUM> of the application, for example, by requiring the user to click the call to action button <NUM>. For example, the call to action button <NUM> may correspond to a link/button for navigating to additional content (e.g., by redirecting to another application and/or website). In another example, the call to action button <NUM> may correspond to a cancel/close button which deletes the modal message <NUM> and enables the main window <NUM>.

On the other hand, <FIG> illustrates an example user interface in which an in-application message is a banner message <NUM>. In one or more implementations, the banner message <NUM> is rectangular graphic that stretches across the top, bottom or sides of another window, and may scroll with the content of the other window. In the example of <FIG>, the banner message <NUM> stretches along the top of the main window <NUM>. The banner message <NUM> may include image data and/or message content. The banner message <NUM> may not disable the main window <NUM>, but may include a call to action component <NUM> (e.g., for redirecting to another application and/or website, or cancelling/closing the banner message <NUM>).

Of course, other types of message types may be applied to the in-application messages described herein. For example, the message type of "native" may be used to create a customized version of the modal and/or banner type messages described above. Alternatively or in addition, the native message type may be used to designate and/or otherwise modify a message type such as, but not limited to: a pop-up message (e.g., a notification which persists until the user explicitly selects to close the message), a popover message (e.g., hover content) and/or a lightbox message (e.g., content which is enlarged or otherwise given focus relative to other content).

<FIG> illustrates a flow diagram of an example process for providing in-application messaging in accordance with one or more implementations. For explanatory purposes, the process <NUM> is primarily described herein with reference to the electronic device <NUM> and the server <NUM> of <FIG>. However, the process <NUM> is not limited to the electronic device <NUM> and the server <NUM> of <FIG>, and one or more blocks (or operations) of the process <NUM> may be performed by one or more other components of the server <NUM> and other suitable devices (e.g., any of the electronic devices <NUM>-<NUM>). Further for explanatory purposes, the blocks of the process <NUM> are described herein as occurring in serial, or linearly. However, multiple blocks of the process <NUM> may occur in parallel. In addition, the blocks of the process <NUM> need not be performed in the order shown and/or one or more blocks of the process <NUM> need not be performed and/or can be replaced by other operations.

The electronic device <NUM> receives, from the server <NUM>, a message and a rule (<NUM>). The rule specifies a condition to be satisfied prior to displaying the message in association with an application. The condition corresponds to user interaction with respect to the application.

The condition may correspond to a number of times that a predefined user action is to be performed before displaying the message. The electronic device <NUM> may maintain a count of the number of times the predefined user action has been performed. The count may be maintained when the application is running and not running (e.g., the count is maintained across multiple executions of the application). Alternatively or in addition, the condition may correspond to a predetermined sequence of user actions to be performed (e.g., performing a first action X times, a second action Y times, and/or a third action Z times) before displaying the message.

The electronic device <NUM> stores the message in local memory (<NUM>). The electronic device <NUM> determines that user activity performed with respect to the application satisfies the condition corresponding to the user interaction (<NUM>). The message may relate to suggesting a feature or content of the application for a user of the application to engage in, the feature or content relating to the user activity.

Prior to this determination, the electronic device <NUM> may request content associated with the message based on a determination that the user activity has satisfied a predefined portion of the condition corresponding to the user interaction, and receive the content based on the request.

In response to the determining, the electronic device <NUM> retrieves the message from the local memory, and displays the message (e.g., and the above-mentioned content associated with the message, if applicable) in association with the application (<NUM>). The message may be displayed as at least one of a banner, a window or in full screen.

The retrieving and the displaying may further be in response to a determination that a second rule is satisfied, the second rule being independent of the user activity. For example, the second rule may set a limit on a number of messages to display with respect to the application over a given time period.

The electronic device <NUM> may send, to the server <NUM>, an indication of the user activity performed with respect to the application, for server-side evaluation in determining a second rule specifying a second condition to be satisfied before displaying a second message in association with the application, the second condition corresponding to second user interaction with respect to the application.

The first electronic device <NUM> may be associated with a user account. The electronic device <NUM> may clear a cache on the first electronic device <NUM> with respect to the user activity, and send, to the server <NUM>, a notification for notifying one or more second electronic devices (e.g., one or more of the electronic devices <NUM>-<NUM>) associated with the user account to clear their respective caches with respect to the user activity.

<FIG> illustrates a flow diagram of another example process for providing in-application messaging in accordance with one or more implementations. For explanatory purposes, the process <NUM> is primarily described herein with reference to the electronic device <NUM> and the server <NUM> of <FIG>. However, the process <NUM> is not limited to the electronic device <NUM> and the server <NUM> of <FIG>, and one or more blocks (or operations) of the process <NUM> may be performed by one or more other components of the server <NUM> and other suitable devices (e.g., any of the electronic devices <NUM>-<NUM>). Further for explanatory purposes, the blocks of the process <NUM> are described herein as occurring in serial, or linearly. However, multiple blocks of the process <NUM> may occur in parallel. In addition, the blocks of the process <NUM> need not be performed in the order shown and/or one or more blocks of the process <NUM> need not be performed and/or can be replaced by other operations.

The electronic device <NUM> receives, from a server <NUM> and based on a server-side push operation, an indication of a message for displaying in association with an application (<NUM>). The message may correspond to an update to a prior message, or may correspond to a new message.

The electronic device <NUM> sends, to the server <NUM> and in response to the receiving, a request for the message (<NUM>). The electronic device <NUM> receives, from the server <NUM> and in response to the sending, the message (<NUM>).

The electronic device <NUM> displays the message in association with the application (<NUM>). The message is displayed when user interaction performed with respect to the application satisfies a pre-determined condition. The message may relate to suggesting a feature or content of the application for a user of the application to engage in, the feature or content relating to the user activity.

The condition may correspond to a number of times that a predefined user action is to be performed before displaying the message. Alternatively or in addition, the condition may correspond to a predetermined sequence of user actions to be performed before displaying the message.

The condition may be specified by a first rule received from the server <NUM>. The message may be displayed in response to a determination that a second rule is satisfied, the second rule being different than the first rule and independent of the user activity.

As described above, one aspect of the present technology is the gathering and use of data available from specific and legitimate sources for in-application messaging. The present disclosure contemplates that in some instances, this gathered data may include personal information data that uniquely identifies or can be used to identify a specific person. Such personal information data can include demographic data, location-based data, online identifiers, telephone numbers, email addresses, home addresses, data or records relating to a user's health or level of fitness (e.g., vital signs measurements, medication information, exercise information), date of birth, or any other personal information.

The present disclosure recognizes that the use of such personal information data, in the present technology, can be used to the benefit of users. For example, the personal information data can be used for in-application messaging. Accordingly, use of such personal information data may facilitate transactions (e.g., on-line transactions). Further, other uses for personal information data that benefit the user are also contemplated by the present disclosure. For instance, health and fitness data may be used, in accordance with the user's preferences to provide insights into their general wellness, or may be used as positive feedback to individuals using technology to pursue wellness goals.

Despite the foregoing, the present disclosure also contemplates embodiments in which users selectively block the use of, or access to, personal information data. That is, the present disclosure contemplates that hardware and/or software elements can be provided to prevent or block access to such personal information data. For example, in the case of in-application messaging, the present technology can be configured to allow users to select to "opt in" or "opt out" of participation in the collection of personal information data during registration for services or anytime thereafter. In addition to providing "opt in" and "opt out" options, the present disclosure contemplates providing notifications relating to the access or use of personal information. For instance, a user may be notified upon downloading an app that their personal information data will be accessed and then reminded again just before personal information data is accessed by the app.

<FIG> illustrates an electronic system <NUM> with which one or more implementations of the subject technology may be implemented. The electronic system <NUM> can be, and/or can be a part of, one or more of the electronic devices <NUM>-<NUM>, and/or one or the server <NUM> shown in <FIG>. The electronic system <NUM> may include various types of computer readable media and interfaces for various other types of computer readable media. The electronic system <NUM> includes a bus <NUM>, one or more processing unit(s) <NUM>, a system memory <NUM> (and/or buffer), a ROM <NUM>, a permanent storage device <NUM>, an input device interface <NUM>, an output device interface <NUM>, and one or more network interfaces <NUM>, or subsets and variations thereof.

Finally, as shown in <FIG>, the bus <NUM> also couples the electronic system <NUM> to one or more networks and/or to one or more network nodes, such as the server <NUM> shown in <FIG>, through the one or more network interface(s) <NUM>. In this manner, the electronic system <NUM> can be a part of a network of computers (such as a LAN, a wide area network ("WAN"), or an Intranet, or a network of networks, such as the Internet. Any or all components of the electronic system <NUM> can be used in conjunction with the subject disclosure.

It is understood that any specific order or hierarchy of blocks in the processes disclosed is an illustration of example approaches. Based upon design preferences, it is understood that the specific order or hierarchy of blocks in the processes may be rearranged, or that all illustrated blocks be performed. Any of the blocks may be performed simultaneously. In one or more implementations, multitasking and parallel processing may be advantageous.

The word "exemplary" is used herein to mean "serving as an example, instance, or illustration". Any embodiment described herein as "exemplary" or as an "example" is not necessarily to be construed as preferred or advantageous over other implementations. Furthermore, to the extent that the term "include", "have", or the like is used in the description or the claims, such term is intended to be inclusive in a manner similar to the term "comprise" as "comprise" is interpreted when employed as a transitional word in a claim.

Claim 1:
A method (<NUM>), comprising:
receiving (<NUM>), at a device from a server, a message and a rule, the rule specifying a condition to be satisfied prior to displaying the message in association with an application at the device, the condition corresponding to a number of times that a predefined user action is to be performed with respect to the application before displaying the message and the device being associated with a user account;
storing (<NUM>) the message in local memory of the device;
receiving, by the device, user input to the application, the user input corresponding to the predefined user action performed with respect to the application;
synchronizing, with another device associated with the user account and having received the message and/or the rule, a count of the number of times that the predefined user action has been performed with respect to the application on the device and at the other device;
determining (<NUM>), by the device and based on the synchronizing, that the number of times that the predefined user action has been performed with respect to the application on the device and at the other device satisfies the condition; and
in response (<NUM>) to the determining,
retrieving the message from the local memory of the device, and
displaying, at the device, the message in association with the application; and after the displaying,
clearing the message from the local memory of the device, and
sending, to the server, an indication that the message has been displayed at the device,
after sending the indication to the server, the server sends a notification to the other device associated with the user account to: (i) delete the message when stored locally on the other device, and/or (ii) modify the rule to indicate that the message is not to be displayed on the other device.