Patent Application
20140344061
The present invention relates primarily to data management techniques for mobile devices and to pre-existing applications for such devices, and more particularly relates to methods and techniques for modifying existing mobile applications to permit either of both insertion of content adapted for operation on the target device, and retrieval of appropriate user and usage information from the device.
Most mobile applications (those designed to run on mobile devices, such as cell phones, smart phones, PDAs, and portable game consoles) are developed in languages such as Java and C++. The source code for these applications must be compiled into an object code format and packaged (typically in conjunction with application resources and application descriptor files) for distribution. If an application publisher wishes to introduce new functionality into an existing application, the application source code must be modified, recompiled, and redistributed.
There are many examples of useful functionality that could be added to a mobile application after it has been developed and sent to an application distributor. A primary example of additional functionality is receipt and display of advertising content, although numerous other examples of such functionality exist, including: billing and subscription management, market research, personalization, and networked game support.
A large number of mobile applications have been developed which are provided to end users free of charge and which provide no direct revenue to the application publishers. In fact, in the U.S. market, usage of such free applications exceeds usage of purchased applications by an order of magnitude. Application publishers are interested in monetizing these applications via advertising content, but most have not yet done so due to the cost of retrofitting application source code. Further, to date, there has been no viable method for retrieving appropriate user data to assist in monetizing these applications.
There has, therefore, been a long-standing need for systems and techniques for managing distribution of data (such as advertising content) and for retrieval of appropriate data (such as advertising impression counts) to and from pre-existing mobile applications.
Existing web advertising systems such as DoubleClick distinguish between the concepts of advertisements and creatives in that an advertisement is a collection of creatives, where all creatives within a collection are images of the same dimensions. The advertisement collection construct helps the advertiser organize creatives based on similarities in advertising message. Such advertising systems first select an ad for placement in a specific website location (this selection is often manually configured) and then select from the creatives within the ad collection. Because all creatives within an ad collection share the same image dimensions, image dimension is not included in the criteria for creative selection. More generally, existing online advertising systems assume that all creatives can be presented (displayed and interacted with) on all computers that attempt to view the website into which the creative is served. Because different devices have differing capabilities and this has not been addressed by existing web ad systems, there has been a need for a system for serving ads which takes into account the differing capabilities of the device to which the ad is being served. This is particularly true for mobile devices.
The present invention substantially improves upon the prior art by providing systems, methods and techniques for adding content and control logic to pre-existing applications for mobile devices and also for retrieving user and usage data from such mobile devices. In at least some arrangements, the techniques include analyzing the pre-existing application in the context of its target platform, identifying appropriate points for insertion of the new content and control logic, and automatically rewriting the application to permit the new content to be supplied and control logic to be invoked at the appropriate times. An aspect of the invention is directed to a business method for the distribution of content and the apportionment of revenues according to the roles of the participants in that distribution.
In an alternative arrangement, which is preferable in at least some instances, the application publisher sends the original application 200 first to the application instrumentation server 220 and then to the distribution server 210. Upon receiving an original mobile application, the instrumentation server 220 performs the analysis and instrumentation methods which are aspects of this invention. The analysis and instrumentation methods include analyzing the mobile application in object code form and adding, deleting, or modifying the constituent object code instructions. After an original application has been subjected to analysis and instrumentation, it is referred to for purposes of the present invention as an “instrumented application”. The application distribution server 210 transmits (distributes) an instrumented mobile application to an end user's mobile device 260 in response to an end user request for download.
In some arrangements, the analysis and instrumentation methods results in the addition of new control logic to the application. One example of such additional control logic is the capability of retrieving, rendering, and reporting viewing statistics for advertising content. Placement opportunities (such as screen regions) for such advertising content are conventionally known as “inventory”. In one arrangement of the present invention, content is added to the application during instrumentation, in which case the instrumentation server retrieves content from a content management server 230, which can include storage for such information, or can alternatively receive content from a separate content provider 240. Alternatively, content can also be retrieved at runtime by the new control logic from a content management server; in addition to retrieving content, in some arrangements the new control logic uploads information to the content management server such as content viewing statistics. The instrumented application 250, which in the illustrated example comprises the original screens 250A plus new content management code 250B, plus one or more new splash screens 250C, is then distributed in a conventional manner to a suitable receiver such as a cellular telephone 260 or other similar device over the carrier network 270, where the instrumented application 200 is provided to the user 280.
Examples of advertising content, as referred to above, include both input and output elements. Output elements include graphical elements, such as splash screens, which are typically displayed before application execution, after application completion, or between application screen transitions. Output elements can also include graphical elements such as banners, marquees, flyovers, pop-ups, and videos, all of which can be shown at various times during application execution, potentially in combination with existing application graphical content. Output elements can also include other known output mechanisms such as audio content or tactile content, such as device vibration. Input elements typically involve opportunities for users to enter data or make choices, and can for example take the form of user interface (“UI”) text boxes or selection controls. Input elements are used, for example, in conjunction with output elements to create interactive content, such as customer surveys or lead generation, such as email acquisition. Input elements can also include monitoring of lower-level input mechanisms such as touch-sensitive screen, tilt sensor, accelerometers, special function buttons, and switches indicating phone mechanical configuration. Input elements can also include monitoring of low-level input and data sources that are not typically under direct user control, including for example radio signal receiver status and data, GPS chipset status and data, RFID transceiver status and data, IR transceiver status and data, Bluetooth transceiver status and data, clock, camera, and light sensors.
A single application can be instrumented multiple times, resulting in multiple instrumented versions of that application, and each instrumented version can have support for different advertising content. A single application can be instrumented multiple times, over a period of time, such that later instrumented versions can have support for advertising content not existing at the time of the prior instrumentations. In this manner, as advertising content types (also known as ad formats) are created over time, a given application can be re-instrumented to include support for each new ad format.
The following sections provide further detail on aspects of instrumentation initiation, analysis and instrumentation methods, object code modification techniques, and runtime system interactions for an instrumented mobile application.
As described previously, the instrumentation process is initiated when an original application is provided to the instrumentation server either by the developer prior to application distribution or by the distribution server during application distribution.
In a further alternative arrangement, a combination of both approaches can be used, such that an application undergoes multiple instrumentation steps, some before and some during the distribution process. An application can also be instrumented or re-instrumented after it has been downloaded to a mobile device. Such instrumentation is performed either by the instrumentation server code executing on the mobile device; or by uploading the application from the device to an instrumentation server, instrumenting the application, and then downloading the application back to the device. It will be appreciated by those skilled in the art that numerous other permutations can be used, and the present invention is intended to include each such permutation.
For the example illustrated in the Figures, the analysis and instrumentation modules are categorized as follows. “Shim” modules 605 provide a layer on top of existing platform APIs and allow the instrumentation code to intercept platform API usage as called for by the original application. Typically, but not necessarily, there is a shim module for each distinct set of platform APIs; for example, in one embodiment there is a shim module for each of the J2ME CLDC and MIDP API sets as well as shim modules for each of the vendor-specific UI APIs, such as those provided by Nokia, Motorola and other vendors of cellular telephones or similar wireless devices. Content management modules 610 provide infrastructure for transferring content between a mobile device and a network server and for managing storage of that content on the mobile device. The device-resident storage is typically a persistent storage mechanism such as FLASH memory or local disk drive and is accessed via file or record oriented platform APIs. Examples of typical content management modules include: an Ad Manager module, which coordinates reception of advertisement content from and transmission of usage data to the network server; a Network Transport module, which provides an abstraction layer to the Ad Manager module on top of the network transport mechanisms available on the mobile device, such HTTP, WAP, raw TCP, and SMS; and a Persistent Storage module, which provides an abstraction layer to the Ad Manager module on top of the persistent storage mechanisms available on the mobile device, such as J2ME RMS (Record Management System) and JSR-75 File Connection. Environment setup modules 615 provide access to environmental information, such as user identification and GPS location. Other modules can use information provided by the environment modules to influence their behavior; for example, the Ad Manager module can use GPS location information to request location-specific advertising content from the network server. Inventory modules provide logic for presenting content at specific locations within an application, such as Presplash, Postsplash and Text Marquee. Action modules 620 provide logic for executing some set of actions in response to user input related to an inventory placement, for example Click-to-Web and Click-to-Call.
The modules described above are typical examples, but other modules are also possible, including but not limited to the following: Content management modules can be provided for managing other types of content, such as billing and subscription data, market research data, personalization data, and networked game data. Inventory modules can be provided for rendering images at other locations within an application, such as during screen transitions. Inventory modules can also be provided for rendering video or audio content. The presentation of any form of content—including visual, audio, and tactile as well as manipulation of any advertising output elements described previously—is generally herein referred to as rendering. Action modules can be provided for accepting survey input and transmitting resulting survey data to a network server. Action modules can also be provided for sending an SMS/MMS in response to user action (“click-to-SMS”). Environment modules can be provided to obtain cell ID information to provide coarse-grained location when GPS is not available. Environment modules can also be provided to detect physical environment conditions, such as ambient light conditions via a device-resident camera or ambient noise levels via the phone microphone. Environment modules can also be provided to obtain the mobile device “profile” setting (which can include “silent”, “normal”, “meeting”, “outdoors”), which can indicate whether use of the device audio output is permitted.
In a typical arrangement, the instrumentation manager invokes modules in order based on their categories, in such a way that later invoked modules can make use of analysis and instrumentation performed by earlier modules. Invocation order can also be defined within a module category. In one embodiment, invocation order is defined by assigning each module category a non-overlapping priority range and by assigning each module an integer priority value within its category's priority range. An example of this layering of module functionality is shown in
Just as higher-level modules can make use of the analysis output of lower-level modules as reflected in the configuration database 630, External Systems 640 can also query and modify the configuration database. One such interaction is shown in the UML sequence diagram of
It should be noted that the database 630 and communications paths described above are conceptual descriptions and can be realized by a number of different embodiments. For example, rather than using a database, configuration data can simply be passed by inter-process communication between the instrumentation server and modules and the optional external systems.
The following sections describe the analysis and instrumentation methods in more detail.
Original Application Analysis
An original mobile application is analyzed in order to: identify target application platform and operating environment; identify options for code rewriting; and identify demographic or other ad targeting information.
Object code analysis is performed in general by searching for application entry points and invocations of target platform APIs. Whereas most object code is difficult to interpret, application entry points and use of platform APIs follow well-defined rules. For example, in the case of Java, source code is compiled into a standardized classfile format (and classfiles are packaged together into a JAR file), where the classfile header includes a string table; reference to platform API classes and methods take the form of well-defined instruction bytecodes which identify the target API elements via reference to the header string table. The application entry points in a Java application are implied by a text entry (“MIDlet:”) in the application descriptor JAD file. Applications developed using other technologies (such as Macromedia Flash) in which source code is compiled to an object code format that executes on a virtual machine follow a similar structure; while the object code and application package formats are different, the formats are nonetheless well-defined. Applications developed using technologies which compile directly to machine code (such as native Symbian or BREW applications) rather than to virtual machine bytecodes also follow similar rules: application entry points are identified at well-defined offsets from the start of the object code binary representation, and any reference to platform APIs must reference entries in a symbol table within the object code.
Identification of the target application platform is performed by searching for use of platform APIs. Specifically, certain APIs are supported only on certain platforms. Most mobile platform vendors (such as Nokia, Motorola, etc.) provide APIs which allow applications to use functions specific to their platform. For example, Motorola provides an API class “com.motorola.iden.lcdui.ExternalDisplay”. If an application makes use of this class, then the application is known to execute only on Motorola devices (and more specifically only on a specific class of Motorola devices). Identification of target application platform allows the subsequent code rewriting phase to make use of the target application APIs. Using, for example, the foregoing Motorola API class, the code rewriting phase only has the option of displaying graphics on a secondary cell phone screen via the Motorola API class if the analysis phase determines that the API is supported, based on its identification of the target platform.
Similarly, identification of target operating environment is performed by searching for use of specific APIs. In this case, the APIs can not be specific to vendor or platform but rather incur some user impact. For example, target platform identification can indicate that GPS functions are supported (via the JSR179 API), but the application can or can not make use of those functions; this can be significant in some instances, since use of those functions typically requires explicit user authorization. In this example, identification of operating environment with respect to GPS usage can be determined by searching for use of the API class javax.microedition.location.LocationProvider. If operation environment identification detects that this GPS API is used, then the subsequent code rewriting phase would typically also choose to make use of this API.
Identification of options for code rewriting uses the same techniques. As described in more detail below, conventional code rewriting techniques generally follow one of the following patterns: modification of application entry point(s) as identified in the application descriptor or object code header; replacement of platform API references with references to new code which delegates to the original platform APIs; modification or insertion of code within existing code blocks (i.e., within existing methods or functions). Relevant API references and code insertion locations include but are not limited to the following:
Application entry points. For example, as described previously, Java application entry points are implied by the MIDlet: reference within the JAD file. This reference identifies a classfile in the JAR file, and that classfile must include definitions of the following methods: startApp, pauseApp, destroyApp. These entry points can be replaced, or the code within the methods can be modified in order to perform work (such as display a graphical splash screen) when the application starts, pauses, resumes, or exits.
Application transition points. Example application transition points include invocation or implementation of the javax.microedition.lcdui.MIDlet API methods notifyPaused, notifyDestroyed, resumeRequest, and platformRequest. A further example includes instantiation of the platform API class javax.microedition.lcdui.Canvas and implementation of the Canvas method showNotify; code rewriting can insert code within this method in order to display, for example, interstitial splash screens. A further example includes implementation of the API class javax.microedition.lcdui.CommandListener and its method commandAction, which is an API used to process user menu selections. For example, code can be inserted in this method to detect a game restart condition by analyzing the method arguments and detecting if the menu invoked has a label similar to “New game”; in such cases, code rewriting can insert display code for interstitial splash screens.
Graphical elements that can be interfaced with ad content. For example, references to classes such as javax.microedition.lcdui.Ticker can be replaced with references to a delegating class, where the delegating class displays text advertisements before or after the original ticker contents. Similarly, references to javax.microedition.lcdui.game.Sprite can be replaced with references to a delegating class, where the delegating class displays graphical advertising content in addition to or in place of the original graphical sprite elements.
Other multimedia elements that can be interfaced with ads. For example, the platform API classes javax.microedition.media.Manager and javax.microedition.media.Player are used to control playback of various multimedia types, including audio. References to these API classes can be replaced with references to delegating classes which play multimedia advertisements before or after the original multimedia content.
Access to network services. For example, the API class javax.microedition.io.Connector is used to initiate most network connections. References to this class can be replaced with references to a delegating class which monitors all network traffic for the purpose of collecting advertising targeting data. For example, there are a number of mobile applications which provide weather information retrieved from one of a number of well known web sites (such as www.weather.com). Weather information is typically retrieved by sending a location string, such as a zip code, to the web server. A delegating class can monitor such network traffic for the purpose of determining user location and using that information for ad targeting.
Lastly, information such as demographic indicators can be extracted during code analysis for the purpose of ad targeting. A demographic indicator is any information that narrows the target audience for the application; an example demographic indicator would be text strings within the application code related to sports cars, which would likely indicate that the application users are interested in sports cars. To this end, all text content is extracted from the original application and can be provided to an ad targeting system. Text content can be extracted directly from string constants or can be inferred based on analysis of string concatenation code. Other content, such as graphics and audio, can also be extracted and presented to targeting systems. For example, audio content can be presented to a song recognition service, such as Gracenote Mobile MusicID, where recognized audio content directly implies target demographics. Graphical content can similarly be extracted and analyzed, for example, to extract textual content from images via optical character recognition techniques.
Note that while analysis is typically applied to original applications that have been developed without the intention of submitting the applications to analysis, the analysis can also be applied to applications that have been developed with this analysis in mind. For example, it is described above how the analysis can determine potential opportunities for splash screen insertion based on detecting references to standard platform APIs. The analysis process can also be directed to detect references to non-standard APIs provided by the implementer of the methods of this invention. A developer can make use of such references in order to provide control directives to the instrumentation process. Although these references are inserted during source code development, it is still useful to submit the resulting application to the code instrumentation process for inclusion of additional functionality, such as presentation of static ad content, which cannot generally be provided at source code development time.
The instrumentation process can optionally accept from external systems additional control input and content, such as user identification and static ad content. In one embodiment, these external systems interface with the instrumentation server via the configuration database, as shown in
As described previously, in the case of instrumentation during application download, the download server typically knows the identification of the downloading mobile device or user; this user identification can be provided to the instrumentation process so that it can be added to the instrumented application.
Static ad content can also be provided to the instrumentation process for inclusion in the instrumented application. Ad targeting information gathered during analysis, such as demographic information, can be queried by an external system in order to influence the ad content that will be either statically included into the application or served to the application dynamically via a network connection at a later time. For example, a conventional “Ad Network” server (such as those operated by 24/7 Real Media or Experelick) can organize its available advertising content by interest categories (such as sports, finance, music, etc.). As described previously, instrumentation analysis of an application can determine demographic indicators; these demographic indicators can be mapped to these interest categories and used by Ad Network servers in order to provide targeted ads to the application.
The final step of the instrumentation process is modification of the application based on the results of the preceding analysis and optionally based on external control input. Code rewriting techniques are described in more detail below.
The complete format of Java object code is well-documented in the prior art, but
As described previously, the entry point for a Java mobile application is indicated in a text JAD file via the entry labeled MIDlet:. This identifies a classfile by name within the JAR file. The application entry point can be modified by simply changing the JAD file MIDlet: entry to reference a different classfile within the JAR. Typically, the newly referenced classfile is a new classfile not existing in the original application.
As described previously, the code analysis and modification procedures can be performed in the context of references to platform APIs. Such references include class instantiation, class derivation, interface implementation, field reference, and method invocation. These references can identified as follows: Instantiation of a specific API class can be found by scanning the bytecodes of each method in each classfile and searching for the bytecodes corresponding to the new instruction, where the instruction operand references a corresponding classfile constant_pool string (by way of a separate CONSTANT_Class entry) that is the internal form of the name of the API class of interest. Direct derivation of a class from a specific API class can be found by inspecting the super_class field of each classfile and checking if the field references a corresponding classfile constant_pool string (by way of a separate CONSTANT_Class entry) that is the internal form of the name of the API class of interest; indirect derivation can be identified by recursively applying the foregoing procedure to the identified superclass. Implementation of a specific API interface can be found by inspecting the interfaces field of each classfile and checking if the field contains a reference to a corresponding classfile constant_pool string (by way of a separate CONSTANT_Class entry) that is the internal form of the name of the API interface of interest. Reference to a specific API class field or method can be found by scanning the bytecodes of each method in each classfile and searching for the bytecodes corresponding to a field access instruction (getfield, getstatic) or a method invocation instruction (invokevirtual, invokestatic, invokeinterface) where the operand references corresponding classfile constant_pool strings (by way of a separate CONSTANT_Fieldref, CONSTANT_Methodref, or CONSTANT_InterfaceMethodref entries) that identify the internal form of the name of the API class of interest and the name of the API field or method of interest.
Modifying any of the foregoing references amounts to modifying the index into the corresponding classfile constant_pool. Typically, the new reference involves a new class not existing in the original application, in which case the new entries to be referenced must first be added to the classfile constant_pool.
A new classfile can be added to a mobile application simply by adding the classfile to the application JAR. In order to add code to an existing classfile, the appropriate code insertion point must first be identified. New code insertion points can be categorized as: before or after reference to an API element; or at the beginning or end of an overriding API method implementation. Identification of API element reference locations is described above. An API method implementation can be found by first identifying classfiles corresponding to subclasses of the API class of interest and then searching those classfiles for implementation of the API methods of interest. Identification of derivation from an API class is described above. API method implementation within a classfile of interest can be identified by searching each entry in the methods field of the classfile and checking for entries that reference a constant_pool string that matches the internal form of the name of the API method of interest.
Once a code insertion point is chosen, new bytecodes can simply be inserted into the existing method bytecodes. After insertion of new bytecodes, any reference to pre-existing bytecode offsets that follow the new bytecodes must be updated. For example, pre-existing goto instructions which occur before the new bytecodes but reference a branch offset after the new bytecodes will need to be updated to reflect the changed branch offset.
New resource files, including binary data such as images and audio clips, can simply be added to the application JAR file, as depicted in
Since most of the application modifications described above involves addition of new code, classfiles, or resources, the resulting application JAR will increase in size. This can be unacceptable for certain devices, since some mobile device platforms impose maximum JAR size constraints.
An instrumented mobile application can be non-network enabled, in which case all required advertising content is inserted into the application at instrumentation time. More typically, an instrumented mobile application will be network enabled in order to acquire new advertising content over time.
The application can piggyback on user accesses of the internet, and only use those opportunities to update or replace ads. This can avoid unwanted airtime charges to a user. The user might access the internet for web browsing, to contact another player for a game, etc. The updates could involve removing an ad to save memory space, such as by uploading part or all of the application, modifying it, and re-downloading it.
Execution of application code that implements the server communications, including processing of any data received from the server, can occur simultaneously with execution of original application code. For example, retrieval of ad content can execute on a separate thread of execution that does not interact with the mobile device user interface, such that the end user can interact with the original application behavior without waiting for the ad content retrieval to complete.
Effective ad targeting is an important function, since poorly targeted ads annoy users and decrease application usage. Ad targeting depends on collection of user demographic and contextual information. A number of techniques are outlined above for acquiring such information, including: acquisition of user identity during download process; analysis of static application content such as text and multimedia content; analysis of network usage at runtime; tracking usage location based on GPS. Additional techniques are outlined below.
It is generally not permissible by advertising industry standard practices to transmit or store any user-related information in such a way that the user identity can be determined from that information; such information (such as phone number, direct connect number, device email address, or device serial numbers) is conventionally referred to as Personally Identifying Information (PII). To avoid the use of PII, instrumented applications for at least some embodiments of the present invention do not store user identity as determined either during the download process or via use of platform APIs. Rather, in such embodiments a one-way hash of the PII is generated using well known techniques such as MD5 or SHA-1. This PII hash is stored by and communicated between the instrumented application and the ad server. The carrier and typically the application distributor also know the PII as well as other user demographic information. This demographic information can include for example location of residence, age, income level, gender, race, nationality, education level, consumer preferences, spending patterns, marital status, family size, languages spoken, health factors, and bodily characteristics. This demographic information can be obtained directly or indirectly from the end user, or it can be inferred from other demographic data determined for example at the time of application analysis or instrumentation. In order to request demographic information from the carrier or distributor without transmission of PII, the PII hash can be used.
An alternative technique that allows the ad server to determine PII related to a mobile application is for the mobile application to send a text message to the ad server. The text message source address includes PII in the form of the originating mobile device phone number. After receiving the PII, the ad server translates it to a PII hash for use in subsequent interactions.
Identification of a users' carrier implies a certain demographic. Carrier identity is typically known at application download time. An instrumented application can also communicate its carrier identity by sending a text message to an email address monitored by the ad server; the text message will be sent as an email, and the source address domain will identify the carrier.
As noted previously, some mobile web browsers include cell ID and other contextual information in the header of HTTP or WAP requests; this information can not otherwise be generally accessible to applications. An instrumented application can communicate this information to the ad server by invoking platform APIs to launch the web browser and request a page from a web server monitored by the ad server.
In contrast to existing web advertising systems, the mobile advertising system of this invention can detect and make use of the differences in display and general capabilities of devices to which the system serves ads. The present invention is capable of distinguishing between ads and creatives, similar to online web ad systems, which can aid in the organization of creatives based on ad message or other criteria. However, this system of the present invention expands upon the traditional distinction between ad and creative and allows creatives within an ad collection to have different display characteristics (such as image size and color depth) as well as different associated actions. The ad system of the present invention can, in at least some embodiments, select ads based on ad targeting objectives as described above but selects creatives from within an ad collection based on the capabilities of the device environment to which the ad is to be served. These capabilities criteria can include any characteristic of the target device environment that is available to the application into which the ad is to be served; these capabilities can include but are not limited to: screen size and color depth; number and type of screens, including internal and external (with respect to clamshell devices); device model; available storage; location capabilities such as GPS; media input capabilities (audio, still image, and video); media playback capabilities (audio and video); web browsing capabilities; processor speed; network transport capabilities (such as TCP vs WAP) and speed (bandwidth and latency); character input mechanisms and modes (such as QWERTY vs multi-tap vs T9 vs sylus-based); touch screen input; contactless identification and payment mechanisms such as RFID; Bluetooth capabilities; light sensors;
This arrangement of ads and creatives is particularly significant in mobile ad systems in which client applications can cache multiple ads and creatives, but one creative is better optimized to the characteristics of a particular device. Consider the situation where clients cache multiple ads, where there is no relationship among creatives that takes into account creative image dimensions, and where there are two creatives that have exactly the same image except that the dimensions are different. If the ad server simply serves ads based on what the client is capable of rendering, then the server may serve both creatives to a single client, and the client may present those creatives in succession. This is not ideal, not only because presentation of the second creative is redundant and dilutes the advertising impact, but also because the change in dimensions may appear to the viewer as a defective ad, and thus create a negative impression. With the solution of this invention, the ad server chooses the creative within an ad collection that is best suited for presentation on the device to which the ad is to be served.
Note that the system of this invention supports but does not require the distinction between ads and creatives. In the absence of this distinction, an ad is effectively the same as a creative, and the selection process described above for creatives applies equally to ads.
In online ad serving, ad impressions are recorded at the time that they are served. Since online ad servers record impressions at the time of ad serving, those servers can target ads deterministically based on the known history of ad impressions. As described above, the mobile ad system of this invention can allow clients to cache ads and can receive ad impression reports at a later time. Because this mobile ad system can serve an ad without knowing the exact number of impressions for that ad to date, in some embodiments the ad system of the present invention can target ads statistically rather than deterministically. In other words, this system selects ads based on an estimate of how many impressions have occurred, rather than how many impressions are known to have occurred.
Such an approach can, in some embodiments, have significant benefits. Because this mobile ad system can target ads based on statistical projections, it can also operate in the absence of client impression reports. In other words, based on serving and impression statistics, the present system can accurately target ads even if a subset of clients does not report statistics. Non-reporting can occur in two cases: 1) impression statistics have been recorded on the client device, but the client application has not subsequently been executed again in order to cause those statistics to be sent to the server; 2) the server explicitly instructs a client not to report statistics (either for some duration of time or forever). The latter case is significant in that it reduces client processing as well as the amount of additional code that is added to the original client application.
In one embodiment, the code rewriting inserts code that communicates via IPC with a portal app on same device. The IPC is via one of persistent store or a loopback network. The portal application can communicates with the network. The portal application launches periodically based on timer to communicate with server. Alternately, an instrumented application can cause the portal application to launch and perform its work. The launch can be caused by a push registry based on loopback traffic. The portal application can write a healthy flag, optionally timestamped, to persistent store. Optionally, if an application is unable to launch the portal application, it shuts down or uses cached ads. Alternately, if an application detects that the portal application has not launched within a time requirement, it shuts down or uses cached ads.
The code rewriting can insert code that writes to commonly accessible persistent store its existence and its usage and ad presentation statistics. The code rewriting can insert code that writes ads fetched from an ad server to commonly accessible persistent store. The inserted code can detect the presence of other instrumented applications. The instrumented applications can coordinate such that only one application sends statistics for all applications to the ad server and fetches ads for all applications. Where instrumented applications coordinate by way of time, the first application to execute within a fixed time period is the only application within that time period to access the network. Alternately, where instrumented applications coordinate by way of application priority, the application with the highest priority contacts the server. The priority can be based on whether and application has code other than instrumented code that accesses network.
A PII hash can be inserted at the time of code rewriting. Alternately, a PII hash can be generated at runtime. The PII hash can be generated by a carrier (or distributor) (who has user and/or device IDs). Where mapping from PII hash to PII is not stored by the carrier for security purposes, but where the PII hash is mapped to demographic information, the mapping can be provided to an ad targeting/demographic tracking system. The UID could be not stored in the application, but rather the ad system can determine the PII via application communications. The application can contact an ad system via SMS and the ad system can extract a source address to use as PII, then use a PII hash to communicate with the targeting system. Demographic information can be extracted by monitoring the SMS system. By using an sms gateway; when we receive an sms, we know the user's carrier based on source sms gateway based on lookup of its ss7 address. We can assign to the user the average demographic information for that carrier (ie, some carriers have users that are older, younger, businesses, family, etc).
The UID can be made available to an advertising system. Demographic information can be made available, based on UID lookup, to the advertising system. The demographic information gathered by other means can be added to the demographic system. The demographic information can be based on one of location, application usage, survey response, purchase action via mobile, etc. The demographic information can be based on information extracted from application object code prior to instrumentation, where information extracted includes string information. The demographic information can be based on network data sent and received by an application (eg search terms, weather zip code, stock tickers). The ad targeting system and demographic collection system can be either the same system or are separate systems. The UID can be used for ad targeting.
Actions Associated with Advertising Content
In web-based advertising, there is a well established mechanism for interacting with basic advertising content: the advertising text or image is (or is enclosed in) a hyperlink, so that the user simply clicks on the link to view additional information related to the advertisement. This click-through is conventionally known as an advertising action. When advertising content is added to a mobile application, the same actions do not necessarily apply, since the advertisement is rendered in an arbitrary application and generally not in a web browser. This difference results in a need for a different action mechanism for advertising content in mobile applications.
One technique is to use the “command key” support built into most mobile application development platforms. For example, in Java J2ME, this refers to the class javax.microedition.lcdui.Command. The precise functionality of this command key mechanism varies depending on mobile device type, but a command key mechanism is typically mapped to one of the generic device buttons (also known as “function keys”). Multiple commands can be mapped to the same physical button, in which case the mobile device typically displays a menu containing the multiple commands when the button is selected.
Because the advertising action is associated with a function key which is independent of the advertising content, the function key command and associated advertising action (indicated by “Ad info”) can continue to be displayed in the original application screens even after the advertising content is no longer displayed. This is significantly different than web-based advertisements and is depicted in the middle set of screens in
The last screen depicted in
While the above sections describe use of function keys to initiate actions (or, more generally, interact with ads), other input mechanisms described earlier may also be used. These include, for example, monitoring of tilt sensors, accelerometers, GPS location, and RFID status.
A primary factor in advertising-supported businesses is audience reach, meaning the number of people that will experience the advertisement. Mobile applications have not traditionally been appropriate for monetization via advertisements, because most mobile applications have thousands rather than millions of users. Typically, even a single advertising campaign (let alone an advertising industry) requires reach of tens of thousands users. While few individual mobile applications have the user base required to support monetization via advertising, a large number of mobile applications in aggregate can attain the required reach. However, there is a “chicken-and-egg” issue in that it is difficult to gain a large number of users across a larger number of applications without having some approach to monetization before the reach is attained. Typically, creating a large number of mobile applications and acquiring a large user base both cost significant money, and that cost has traditionally been recouped via charging users for application usage.
The present invention solves the chicken-and-egg problem by providing a mechanism whereby a large number of pre-existing applications (for which the development costs may already have largely been recouped) can quickly be retrofitted to support delivery and tracking of advertisements. Specifically, the automation provided by this invention is critical in order to quickly grow the user reach required to support an advertising-supported ecosystem. One example of the financial details of this advertising-supported ecosystem is described below and illustrated in
In
The advertiser, which may act via intermediaries such as advertising agencies, injects money and advertisements into the system. The money may be paid in a number of possible arrangements, including any combination of: system usage fees (also known as “ad serving” fees), per ad impression fees (also referred to as “CPM” or cost per thousand impressions), and per action fees for actions associated with ads (also referred to as “CPC” or cost per click). The money may be paid in advance or after some number of impressions or actions have been realized (or any combination thereof). When money is paid in a CPM or CPC arrangement, impression and action statistics are typically provided by the system to the advertiser. These statistics may be directly measured by the application when impressions and actions are realized, or the statistics may be estimated based on a statistical approach such as sampling. When ads are injected into the system, they may be qualified by additional targeting information as described earlier, and the cost for servicing ads may vary based on this targeting.
The application developer, which may act via intermediaries such as licensors of their content, inject mobile applications and possibly money into the system. The money, if involved, may be paid for a combination of system usage fees (measured per-application or per end-user) and fees for statistics generated by the system. Money is also paid from the system to the application developer. This may be any combination of: one-time, per-user, or per-use fees for licensing the use of the application in the system; a revenue share percentage of advertising revenue generated by use of the application; or a prepay on advertising revenue. Money paid to the developer may vary based on usage of the application, for example based on how the application is distributed or based on demographic information associated with the application's end users. Statistics related to application usage and ads/actions delivered through the application may be provided by the system to the developer.
The distributor box in
End users download applications from distributors and execute the applications on their mobile devices. In some arrangements, the end user may pay for usage of the system or of downloaded applications, but this cost is typically less than the cost of downloading the applications without advertising support. When the applications are executed, the application displays advertisements that are either bundled with the application or obtained via communication with the system. Application usage, ad viewing, and ad action statistics may also be provided by the application during execution to the system. In some arrangements, application usage may be limited based on the amount of ads viewed or ad actions taken. In some arrangements, end users may be paid based on their ad and action statistics.
Many permutations of the above may be combined into viable business models. For example, in a “single sponsor” environment, a single advertiser may pre-pay a fixed amount for exclusive delivery of its ads into a limited set of games to be downloaded some maximum number of times from a single distribution point. As another example, a publisher may act as the distributor for its own games and rely on a peer-to-peer file sharing network to distribute its games to end users.
Additional Uses of the Invention
Although the preceding description focuses on use of the invention for the purpose of mobile advertising, the core invention is independent of the type of data that is distributed to and retrieved from a mobile application. The core invention is also independent of the specific logic that is added to a mobile application to coordinate the new data distribution and retrieval. Other example uses of the invention are described below.
Billing and subscription management for mobile applications are typically enabled via source code integration with code libraries that are provided by the carrier or distributor through which the application is to be sold. Different distribution channels can require integration with different billing and subscription management libraries. The integration effort required to use these libraries presents a hurdle that some developers are not willing or able to overcome. If the integration with these libraries could be accomplished automatically at some point after completion of application development, this could enable more developers to take advantage of billing and subscription services.
The present invention can be used to perform this automatic integration with billing and subscription libraries, as depicted in
The present invention can also be used to enable support for application trial periods, which are periods of time after application download that applications can be used without billing (i.e., for free). To enable this, the instrumentation process adds code at the application entry points to check the current date and/or time prior to invoking the billing and subscription APIs. The previously described methods can also be used to distribute advertisements into the applications for presentation during the trial periods, allowing the developer to begin monetizing an application prior to the start of billing.
The present invention can be used for both passive and active collection of market research data.
The preceding describes use of the invention to insert code into a pre-existing mobile application for the purpose of reporting advertising statistics to a server. Passively monitored statistics surrounding mobile application and device usage are also useful for general market research. Collection and correlation of information such as the following is of interest to mobile market researchers: cellular carrier, overall voice and data usage, time and duration of voice/data usage, volume and frequency of text and multimedia messaging usage, number and type of application downloads, time and duration of application usage. Existing mobile market research firms (such as M:Metrics, Telephia, and NPD) gather this market data using a combination of traditional user surveys and specially instrumented mobile devices. Similar to the current art in mobile advertising, the devices used for mobile market research are custom developed by the research firm for the purpose of usage monitoring. Because the devices are specially instrumented, they are only distributed to a small sample group (typically tens of thousands of people). A larger sample group can increase statistical confidence.
The present invention can be used to instrument applications after development for the purpose of passively collecting such statistics as described above. Some statistics can be monitored directly, such as time and duration of application usage for the instrumented application itself. The remaining information listed above (carrier, voice/data/messaging usage, other application downloads) can be collected via platform APIs on certain devices. For example, on certain Motorola devices the com.motorola.iden.recentcalls.RecentCalls class provides access to recent voice usage. Similarly, on certain RIM BlackBerry devices, the net.rim.blackberry.api.phone.phonelogs.PhoneLogs class provides access to recent voice usage. As described previously, the analysis phase of the instrumentation process is responsible for determining the target platform capabilities, which in turn determines how the various statistics are to be gathered. After collection, the statistics can be stored and periodically uploaded to a statistics collection server in a similar manner to which advertising statistics can be uploaded to an advertising server.
The prior description of advertising content included interactive content such as customer surveys. Surveys are also a useful tool for market researchers, and the same mechanisms of the present invention described previously can be used, as depicted in
Many products exist that allow a user to personalize a mobile device. These products include ring tones, wallpapers, and device face plates. The present invention can be used to allow a user to further personalize a mobile device by personalizing the applications that are downloaded to the device. For example, an end user can wish to download a sports game to his/her mobile device and might furthermore wish to personalize that game with graphics and audio content associated with, for example, his/her favorite sports team. In the simplest form, this personalization instrumentation can include allowing the user to select from a list of images (similar to wallpapers) prior to application download and then inserting code to display the selected image at application startup. In a more complex form, depicted in
There is a recent trend that publishers have developed mobile games that are network-enabled such that the games automatically post scores to a server or website that is accessible to other users. Such functionality encourages competition between users and can increase game play. However, the majority of applications were not developed with this functionality. The present invention can be used to allow publishers or distributors to easily add such functionality to pre-existing mobile applications, as depicted in
This application claims the benefit of, and incorporates by reference, each of the following United States Provisional Patent applications, each of which has the same inventive entity and is assigned to the same assignee: Ser. No. 60/762,445, filed Jan. 25, 2006, entitled “System and Methods for Managing Content in Pre-Existing Mobile Applications”; Ser. No. 60/800,101, filed May 11, 2006, entitled “System and Methods for Managing Content in Pre-Existing Mobile Applications”; and Ser. No. 60/859,327, filed Nov. 15, 2006, entitled “System and Methods for Managing Content in Pre-Existing Mobile Applications.”
