Patent ID: 12206727

DETAILED DESCRIPTION OF THE INVENTION

Example embodiments of a lock screen content display system for apps executing on a mobile device are described inFIGS.4and5. Before these embodiments are described, a mobile ad delivery system is described inFIGS.2and3. These examples and embodiments are provided solely to add context and aid in the understanding of the invention. Thus, it will be apparent to one skilled in the art that the present invention may be practiced without some or all of the specific details described herein. In other instances, well-known concepts have not been described in detail in order to avoid unnecessarily obscuring the present invention. Other applications and examples are possible, such that the following examples, illustrations, and contexts should not be taken as definitive or limiting either in scope or setting. Although these embodiments are described in sufficient detail to enable one skilled in the art to practice the invention, these examples, illustrations, and contexts are not limiting, and other embodiments may be used and changes may be made without departing from the spirit and scope of the invention.

Methods and system for displaying ads on a mobile device through execution of an app, wherein the ads may be displayed outside the confines of the app as displayed on the device screen are described in the various figures.

The present invention enables app developers to display ads through their apps to app users wherein such ads are displayed outside the confines of the actual app as displayed on the device. That is, the ad may be displayed as what may be characterized as a ‘regular non-app generated’ ad, such as on the device's home or lock screen (that is, display areas not normally associated with an app). These methods decrease clutter within mobile apps that are caused by the ads. Consequently, advertisers are more likely to pay higher rates thereby generating more revenue for app developers or related entities.

As noted, presently software developers designing mobile apps running on mobile devices can generally only display ads within the confines of the app itself. However, because of the limited screen size of many mobile devices, this constraint increases clutter within apps making it difficult for users to enjoy the app and forcing ads to be displayed in small and confined areas within the app. This, in turn, decreases the quality and appeal of this form of mobile advertising from the perspective of the advertisers, thereby driving down the economic value of such ads and negatively impacting revenues earned by software developers. Furthermore, revenues earned by software developers are limited because ads are no longer seen by users once a mobile app is shut down.

This invention, on the other hand, empowers mobile app developers to display ads to their users wherein the ads are displayed from outside of the confines of their mobile apps. This method decreases clutter within mobile apps due to ads, while still providing an outlet for apps to display ads to their users and earn revenue from advertisers or ad publishers.

FIG.2is a block diagram showing numerous modules and components in the mobile ad delivery system of the present invention. At a high level, the system consists of two primary components: a mobile device202, an ad server224, and a rewards server236. Embodiments of the present invention execute primarily on mobile device202.

Mobile device202, such as a mobile phone, tablet, or e-book reader, executes an app206using conventional components, such as those described inFIGS.6A and6B. App206is comprised of app source code208and is installed on mobile device202. Software208incorporates or includes a mobile ad software development kit (SDK)210.

Software development kit210includes several modules. One is a mobile ad programming interface (essentially an API)212which is in communication with an ad manager214. Ad manager214transmits and receives data from three modules: a user module216, a location module218, and a device module220. Ad Manager214also transmits data to an ad display module222. SDK210communicates with app206(specifically, with source code208) through API212. SDK210communicates with an ad server224through ad manager214. Ad server224runs ad network software226which sends and receives messages to and from ad manager214. Ad server224also includes an ad database228and an ad campaign manager230.

Mobile ad SDK210enables mobile app206to display ads on mobile device202. The ads are displayed outside of app206. As noted, SDK210contains mobile ad API212which presents a library of functions used by app source code208. These functions are used to control the display of ads on mobile device202.

Once app source code208signals mobile ad SDK210through API212to begin displaying ads, ad manager214collects information on the app/device user, such as gender and age, through user module216, the geographical location of mobile device202through location module218, and physical information relating to device202, such as make and type, through device module220.

This user, location and device information is packaged by ad manager214as an ad request and is sent to ad server224. The ad request is picked up by ad network software226on ad server224, where it is analyzed to determine the best possible ad that matches the user, location, and device information passed by ad manager214.

If a suitable match is found, details on the ad are fetched from ad database228and returned to ad manager214which constructs the ad based on the details received. Ad manager214passes the result to ad display module222which, ultimately, displays the ad on mobile device202outside the confines of app206. Ad database228is populated with entries by ad campaign manager230which allows advertisers to define ad campaigns through various parameters, such as duration, budget, demographics, and geography.

Mobile app206can disable ad on device202from outside of app206through mobile API212at any time. When this happens, ad manager214stops collecting information from user module216, location module218, and device module220, and stops communicating with ad server224. Consequently, ad display module222stops displaying ads on mobile device202.

When integrating with mobile ad SDK210, app206has the option of enabling ads on device202outside of app206by default or allowing the user to decide. In the latter case, only if the user opts into receiving ads outside of mobile app206are ad requests made to ad server224. When ad requests are received by network software226, it analyzes data sent with the ad request in order to determine the best ad to display given the parameters of the request. The resulting ad, if any, is then displayed on mobile device202.

An app developer uses or integrates SDK210into a mobile app he or she is developing. Furthermore, corresponding ad server224infrastructure is created in order to efficiently and accurately respond to ad requests made by mobile ad SDK210.

In other embodiments, user module216, location module218, and device module220are not needed. They may only be needed to enable ad campaigns to be targeted to certain user demographics, locations, and mobile device types.

An events module232can be added to mobile ad SDK210so that ad on device202can be refreshed at the occurrence of specific operating system events. For example, module232would allow ads appearing on the mobile device's home and lock screens to be refreshed every time device202is put to sleep and re-awakened.

A rewards module234can also be added to SDK210in order to reward users for accepting ads on their mobile devices. If app206does not enable mobile ads outside of app206by default, users could still decide to opt into receiving such ads in return for rewards from mobile app206. For example, if mobile software app206is a game, users could be rewarded with the game's virtual currency, if available, for every extra day that they continue to receive ads on their mobile device outside of the game itself as displayed on the device.

Mobile app developers use ad SDK210of the present invention to integrate with app206by adding a few lines of code in their existing app source code208. Once this is complete, app206can begin to display ads on the user's mobile device202from outside of the confines of app206.

If reward module234is implemented in the system, mobile software developers wishing to reward their users for displaying ads on their mobile device outside of mobile software app206will need the infrastructure of their own rewards server236in place to keep track of individual users' rewards. Next, mobile software developers register the address of their rewards server236with reward module234. Lastly, app developers implement additional code on their server236to handle callbacks from reward module234to update user reward balances every time a user is awarded a new reward.

FIG.3is a flow diagram of a process of enabling the display of ads obtained via a mobile app outside of the app on the device display in accordance with one embodiment. At step302an ad request is created in mobile app206. At step304module218determines the app user's location. At step306module216collects app user information. At step308module220collects mobile device information.

At step310ad manager214creates a request for an appropriate ad in light of user, location and device and to meet the requirements of the ad request created at step302. At step312the request for an appropriate ad is transmitted to ad server224using ad manager214. Server224then searches for a suitable ad in database228using ad campaign manager230. If server224is able to find a suitable ad for display on the mobile device, control goes to step316where the ad is displayed outside the confines of app206. If server224does not find a suitable ad, control goes back to step310where another ad request is created. This continues until an ad is displayed on the device at which time the process is complete.

In another aspect of the present invention, methods and systems for mobile apps to display full screen or full page, media-rich, interactive content on a lock screen or home screen of a mobile device are described inFIGS.4and5. Embodiments of the present invention improve user engagement with mobile apps when apps are not opened; that is, from outside the confines of the mobile apps. A mobile app is able to display full-page, media-rich, interactive content on a lock screen or home screen, thereby easily distinguishing itself from other mobile apps, and allowing users to interact with the content, such as notifications, without unlocking the device or leaving the lock/home screen.

As noted, conventional practice typically limited mobile app developers to relying on content, such as app notifications, consisting of a single icon to convey messages to users when outside the app. Embodiments of the present invention empower mobile apps to utilize the rich-media technologies to communicate with its users via this same type of content.

One specific example or use case of displaying content on a lock screen as implemented by the present invention is the display of app notifications on a lock screen or home screen. In the described embodiment and as noted above, mobile notifications are designed for exactly what their name suggests: notifying users, typically about simple events related to a specific app, such as a reminder, a completed data transmission, an update and the like. Note that none of these require or invite interaction with the app by the user. They were not designed to engage or re-engage users with mobile app content when the app itself is not opened. As a result, such notifications have a very low engagement rate amongst users, generally because such notifications do not have the appeal or draw needed for users to interact or engage with the apps, specifically, they do not motivate users to open the app and see what the notification is about.

As noted, an app notification is a specific type of content and is used to illustrate implementation of one embodiment of the present invention. Methods and systems described herein can be used to display other more general types of content on a device lock screen. For example, a CNN app may display notification content and more general content on a screen of a device when the app is closed, specifically on a lock screen or home screen of a device (herein referred to as “lock screen”). The app may maintain a list of the latest news items on the lock screen. This list is always maintained and updated by the CNN app and, with the invention enabled, is always displayed on the lock screen of the mobile device. The app may also only display breaking news on the lock screen, more in line with a notification type of content. In this case, the app would only display the breaking news on the lock screen (i.e., a notification) but would provide more interactive, media rich content than a conventional notification. The CNN app may also display both types of content on the lock screen, that is, have a constant display of news items and the occasional display of breaking news.

In the described embodiment, notification content can be modified immediately (“on-the-fly”) by the app publisher or developer and as desired or at-will by the app itself even when the app is not opened. The app can perform operations to modify its notifications in real time.

FIG.4is a block diagram showing numerous modules and components in the mobile app notification system of the present invention. Several of these modules and components are similar to those shown inFIG.2and others are specifically for displaying media-rich, descriptive, and interactive notifications (herein also referred to as “content” or “notification content”) of the present invention.

At a high level, the app content display system consists of two primary components: a mobile device402and a notification content management server414. Embodiments of the present invention execute primarily on mobile device402. Mobile device402executes an app404using conventional components, such as those described inFIGS.6A and6B. App404includes an app source code module406and is installed on mobile device402. App source code module406(i.e., the primary or native app software) communicates with an app notification content software development kit (SDK)408. This SDK408creates the interactive, media-rich notification content displayed by app406on a lock screen or home screen of device402.

The primary operations of the app notification system that execute on mobile device402are performed by SDK408comprised of various modules. As with mobile ad SDK210, SDK408has two modules used for communicating with external modules or components: notification content programming interface (API)410and a notification content manager412. As noted, API410is used to communicate with the app's main source code406. In one embodiment, notification content manager412is used by SDK408to communicate with a notification content management server414, described below. Within SDK408, notification content manager412is in communication with a mediation module416and a notification content display module418. In one embodiment, mediation module416is in communication with three modules: a date/time module420, a location module422, and a motion module424.

It may be noted here that mediation module or layer416, a critical module in SDK408, prevents a common problem caused by conventional independent ‘lock screen replacement’ apps that take control of a device's lock screen functionality. The problem arises if there are two or more of these replacement apps on a device in which case the apps essentially compete with each other. For example, if there is a Custom Lock Screen A and Custom Lock Screen B installed on a device, they will overlap, requiring the user to have to unlock the device twice to dismiss both custom lock screens. This problem can be avoided with the use of mediation layer416which mediates between different apps wanting or requesting access to the lock screen through SDK408of the present invention, thereby avoiding the overlap and multiple unlocking issues presented by conventional lock screen replacement apps.

In one embodiment, the system includes a notification content management server414comprised of three components relevant to the present invention. One is primary software running server414, notification content server software426which sends and receives data from mobile device402. Device402uses notification content manager412via the Internet (or other suitable network) for communicating with server software426. Server software426communicates with a content database428which stores the interactive, media-rich notification content of the present invention. In the described embodiment, this database catalogues content according to, but not limited to, type of content (whether an image, HTML, video, etc.), time of creation, and target audience, target location, desired date and time of notification or content display, and desired motion pattern of the device (such as jogging, driving, etc.). A content user interface430allows a user to design the visual content of the notifications or other content, define its target audience, and transmit this data to database428.

As with SDK210, an app developer integrates SDK408into a mobile app thereby enabling the app notification content processes as described in the present invention. This SDK component enables mobile app404to display content on the lock screen or home screen of device402, even when the app has not been opened by the user. Mobile app developers and publishers can integrate SDK408into app404by adding a few lines of code into app source code406. Once this is complete, app404can send notification content as illustrated in the described embodiment in the present invention to the device home screen or lock screen.

FIG.5is a flow diagram of a process of displaying notification content from an app on a lock screen of a device in accordance with one embodiment. Notification content SDK408includes API410which makes available a function library that can be used by app source code406to control the display of notification content on a lock screen of a device. When app source code406signals SDK408via API410that the app has content it wants to display, mediation module416is invoked. Module416verifies whether app404has permission or clearance to display the content on the device's lock screen.

Before the process ofFIG.5begins, the user has turned on the functionality of the present invention by enabling display of notifications and other types of content on a lock screen or home screen. In one embodiment, this may be done when the user downloads and initially configures the app, or switches it on as desired when using the app. It may be noted that even if an app has the functionality of the present invention (i.e., SDK408has been integrated into it), the user may choose to keep conventional functionality and have simple icon notifications displayed.

The process begins at step502where the app makes a request to display notification content on a lock screen. This request (which would be created in a conventional notification system as well) is transmitted from app native source code to the SDK via the API.

At step504the notification content SDK executes and determines whether the app has clearance to display the content as requested. In one embodiment, it determines whether the app has priority to display the content on the lock screen. There may be multiple apps that want to display notifications and other content and therefore priorities for each of these apps must be determined.

Mediation module computes the priority of apps to display notification content. It first examines the position of the app in a content queue, a component of the SDK of the present invention. An app's position in this content queue is based on the order in which notification content requests were made to the SDK. It may also examine how frequently an app is used by the user. Apps that are used more frequently by a user are given a higher priority. Notifications and other content may also have constraints with respect to date and time, geographic location or how the user handles the devices (i.e., device motion patterns as dictated by the user). That is, these factors or constraints may be examined in determining whether content is displayed on a lock screen. Apps that request to display notification contnet that have all their constraints (date, time, location, etc.) satisfied are also given a higher priority.

If the app does not have priority (i.e., has a low position in the content queue) as determined at step504, the SDK informs the app that its request for displaying a notification on the lock screen is denied and control returns to step502where the app can make another request. The app can keep trying until the SDK, specifically the mediation module, determines that the app has priority at step504at which point control goes to step506. The mediation module has cleared the app thereby allowing it to display a notification on the lock screen.

At step506the notification content manager in the SDK obtains the content to be displayed. The content that constitutes the notification may be a full-screen, interactive, and engaging display (in contrast to the small icon of conventional notifications). It may be obtained from either the content server or from the app itself on the mobile device. A flag in the app source code directs the app source code with respect to the source of the content. In the latter embodiment, various types of content may be embedded or stored in the app source code during app development. The content manager in the SDK determines where to obtain the content from based on parameters set through the API.

If the notification content is fetched from a content management server via the Internet or other network, control goes to step508. If not, control goes to step510where notification content is obtained from the app. If the content is fetched from the server, the content manager packages or creates a request at step508.

In one embodiment, besides containing version and other information relating to the app itself, the request contains information on the app user, date, time, location, and motion pattern of the device at the time the notification is being made (i.e., the time at which the request is being packaged). It also contains the type of notification content requested by the app. In many cases, an app may have only one standard notification that it sends to a lock screen. Some apps may have different types of notifications and content, such as for reminders, alerts, data transmissions, and the like. Upon implementing this invention, app developers may want to have various types of content that can be sent to a lock screen. Recall that the notification content request is being formed by an SDK in the app itself or, more specifically, by an SDK in communication with app source code, as described above.

At step512the request is transmitted to the content server. There it is examined by content server software which identifies content in the database that matches the request made by the notification manager. This content must be associated with the app making the request, and match the date and time contained in the request, geographic location, and motion pattern constraints if applicable. If the software finds a match, details on the content (e.g., the notification display) are obtained from a content database on the server. These details include, but are not limited to, resources such as text, images, HTML pages, videos, and other content used in the notification, and URLs used to track impressions and user engagement with the notifications and other types of content. The database stores data, or has access to data, relating to a content user interface for the various apps. The content user interface allows app developers and publishers to define specific notification content (e.g., videos, graphics, text, images, and other design elements) to be displayed on the device. When and what is displayed is based on specific app events, as described above, as well as user location, day/time, device motion patterns, and demographics. The content server software then constructs the actual notification content (e.g., HTML, text/image combination, video, button icon, etc.) which is displayed on the mobile device lock screen.

At step514the notification manager in the SDK determines whether there is a response from the content server. If there is no response, control goes back to step508where a new request is created. If there is a response from the content server, control goes to step516where the notification content is displayed on the lock screen or home screen of the device.

The content database stores data related to one or more user notification interfaces, along with other data. As noted, each app can have one or more notification displays. These interfaces allow mobile app developers and publishers to define specific notification and other types of content to be displayed based on certain app events, reminders, statuses, and the like, as well as user location, demographics, and device motion patterns.

The notification and content display methods of the present invention may be enabled or disabled by the device user when the SDK is integrated into the app. The notification feature may be enabled by default. The API may be used by the app to disable displaying notification content on a mobile device's lock screen. When this happens, the mediation module stops collecting information from the date/time module, location module, and motion module. Because notification has been disabled, the content manager stops communicating with the notification content management server. Consequently, the notification display module stops displaying content on the lock screen of the mobile device. Only if the user opts into receiving notifications from the app on the lock screen are content requests, as described above, transmitted to the mediation module, content manager, and content management server. When requests are received by the server software, it analyzes the data sent with the request in order to determine the best content to display given the parameters of the request. The resulting notification content, if any, is then displayed on the mobile device.

In other embodiments, the date/time module, location module, and motion module are not needed to implement the present invention. As described above, these modules may be used to calibrate the prioritization of notification requests coming from different apps.

In another embodiment, the content management server is not required to implement the present invention. It allows app developers to modify in an ad hoc manner notification content to be displayed on a device's lock screen, but is not required in order to get the benefits of the content display system of the present invention.

In another embodiment, an events module may be added to the SDK. This would allow for new content can be displayed on the lock screen of the mobile device at the occurrence of specific operating system events, such as every time that the mobile device is put to sleep and reawakened.

In one embodiment, an app developer integrates the SDK into the app source code. The SDK is made available to the developer or publisher from a service provider. Furthermore, the notification content server infrastructure may be provided in order to accurately respond to content requests made by the SDK.

FIGS.6A and6Billustrate a computing system600suitable for implementing embodiments of the present invention.FIG.6Ashows one possible physical form of the computing system. Of course, the computing system may have many physical forms including a small handheld device, such as a mobile phone or tablet. Computing system600includes a monitor602, a display604, a housing606, a disk drive608, a keyboard610and a mouse612. Disk614is a computer-readable medium used to transfer data to and from computer system600.

FIG.6Bis an example of a block diagram for computing system600. Attached to system bus620are a wide variety of subsystems. Processor(s)622(also referred to as central processing units, or CPUs) are coupled to storage devices including memory624. Memory624includes random access memory (RAM) and read-only memory (ROM). As is well known in the art, ROM acts to transfer data and instructions uni-directionally to the CPU and RAM is used typically to transfer data and instructions in a bi-directional manner. Both of these types of memories may include any suitable of the computer-readable media described below. A fixed disk626is also coupled bi-directionally to CPU622; it provides additional data storage capacity and may also include any of the computer-readable media described below. Fixed disk626may be used to store programs, data and the like and is typically a secondary storage medium (such as a hard disk) that is slower than primary storage. It will be appreciated that the information retained within fixed disk626, may, in appropriate cases, be incorporated in standard fashion as virtual memory in memory624. Removable disk614may take the form of any of the computer-readable media described below.

CPU622is also coupled to a variety of input/output devices such as display604, keyboard610, mouse612and speakers630. In general, an input/output device may be any of: video displays, track balls, mice, keyboards, microphones, touch-sensitive displays, transducer card readers, magnetic or paper tape readers, tablets, styluses, voice or handwriting recognizers, biometrics readers, or other computers. CPU622optionally may be coupled to another computer or telecommunications network using network interface640. With such a network interface, it is contemplated that the CPU might receive information from the network, or might output information to the network in the course of performing the above-described method steps. Furthermore, method embodiments of the present invention may execute solely upon CPU622or may execute over a network such as the Internet in conjunction with a remote CPU that shares a portion of the processing.

Although illustrative embodiments and applications of this invention are shown and described herein, many variations and modifications are possible which remain within the concept, scope, and spirit of the invention, and these variations would become clear to those of ordinary skill in the art after perusal of this application. Accordingly, the embodiments described are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.