Patent Application
20110295937
The following relates to creating a digital content bundle and more specifically to creating a digital content bundle for ingestion into a content server.
Many electronic devices, including smart phones, tablet computers, and laptop computers allow users to download and run applications. Examples of applications that can be downloaded include, for example, games, music, and news applications. Users can download these applications from an on-line store. These applications are popular with consumers in part because they allow a consumer to conveniently download applications of particular interest to each user. Content providers desire to display content targeted to the interest of the user (targeted content) within these applications. Displaying targeted content within a targeted application allows a content provider to send its targeted content to users of specific applications, which may have more interest in the specified content.
Content creators typically upload or digitally send their media to a content server to make them available for distribution as targeted content. This process can be complicated and time consuming inasmuch as there are many parameters and criteria that need to be met for proper ingestion of the media into the on-line stores.
Therefore, what is needed is a method and apparatus for generating targeted content configured to be ingested into a content server that can be operated in a simple manner.
Accordingly, a method and system for receiving a package of digital content at a server and processing the package into a format suitable for distribution by the server is disclosed.
Just as in any process, whether performed on a computer or an assembly line, a recognized input needs to be provided to result in a desired output. The present technology addresses receiving a specified input and processing the input for use by a server before distribution to client devices.
In particular, the present technology relates to creation of digital content, which in preferred embodiments comes in the form of a targeted application for execution on a computing device such as a personal computer, laptop, tablet, or personal media-playing device. The targeted application can also be accompanied by additional applications and/or sub-routines, or resources used by the targeted application.
A content developer can develop a targeted application, which can be an application having content that is desired to be distributed and ultimately viewed by targeted users, and then package the targeted application and its associated files for ingestion by the server. This digital content package can include a directory containing the targeted application and referenced files. It can also include a directory of creatives, which can refer to the targeted application. The digital content package can also include a properties file to instruct the server regarding various attributes about the targeted application or the creatives and suggested platforms in which to deploy each. Additionally, the digital content package can include a manifest file for use by the server in packaging the targeted application for distribution to client devices.
In some embodiments, the creatives are themselves applications or images or files, such as html files that link to or direct a user to the full application. The creatives can be displayed at the instruction of the server. The creatives can also be displayed within other programs. In some embodiments, the creatives can be an advertisement for the full application. The server can create a full or partial webarchive for each creative.
In some embodiments, the properties file can instruct the server as to the desired attributes of the creatives and the targeted application. For example, the properties file can provide a background color for a creative or direct the server to display a given creative in a particular situation, e.g., display the creative with a sports application. The properties file can also indicate that a particular creative was created with a particular device in mind. Accordingly, the server can learn of various intended features for display of the creatives or of the targeted application. In some embodiments of the properties file, the server might consider the attributes listed in the properties file as suggestions rather than rules that must be abided.
In some embodiments of the manifest file, the targeted application developer can designate which resources should be prepackaged for delivery to the user. In some examples, a manifest file is only found in the directory containing the targeted application. The server can use the manifest file, which can list resources within the same directory, to gather the designated resources and package those resources along into a targeted application webarchive.
Using the package structure example described above, a content server can prepare the various creatives and the targeted application for distribution to a client device. When a client device requests content from the content server, the server can send one or more creatives, selected by the server, to the client device. The server can optionally send each creative within a full or partial webarchive. The server can also send, either at the same time or immediately following the creatives, the targeted application webarchive file. In other words, the targeted application webarchive file can be sent optimistically.
From a client device perspective, the device can request content from the server and receive one or more creatives for display. The client device will also receive the targeted application webarchive. If or when a user interacts with the displayed creative, which links to the targeted application, the client device can immediately launch the targeted application because it had been optimistically downloaded.
The benefits of the manifest file to server can now be better understood. Since the webarchive file is optimistically sent to the device, it is possible that the targeted application will never be needed. Accordingly, the server can strike a balance between packaging and sending the primary resources of the targeted application, in case they are needed, and wasting resources by sending a targeted application that will never be launched on the client device. To strike this balance the server packages only resources selected by the targeted application developer and designated in the manifest file. All other application resources can be fetched on demand when needed.
Accordingly, the present technology provides a package structure which a targeted application developer can use to submit his/her application to a content server. Using the defined package structure, the server can process the content to be sent to client devices in an efficient manner and a manner that preserves the intended operation of the targeted application as conceived by the content developer.
The technology described herein relates to creating a digital content bundle for ingestion into a content server. A content provider desiring to publish his/her content to the content server must package the content into a recognizable format that the content server can ingest and process into a format suitable for distribution to client devices.
The “myApp” directory includes a properties file 104 that describes properties of the digital content bundle. For example, one property in the properties file 104 can include an “action” description. This “action” description defines what action will occur when a user input is received when a user clicks on a creative. Another property in the properties file 104 can include an “initial orientation” that describes the orientation in which a creative should be viewed in when it launches. A further property in the properties file 104 can include a “supported orientation” property that describes the orientations that a given creative or the targeted application will support. Exemplary values can include portrait, landscape, or all for both. Another property in the properties file 104 can include a “scrolling” property that describes if scrolling should be allowed for a creative or the targeted application. Yet another property in the properties file 104 can include a “background-color” property that describes a background color for a creative or the targeted application. In one example, the “background-color” property is defined as a HEX value such as “7BA9C4”.
The properties file is not limited to describing the properties described above. It should be appreciated that the properties file can be used to describe any other property that the content developer designates. For example, the properties file can describe supported devices, content that the creatives or application can be associated with, properties regarding the targeted applications operation, display, use, etc. In some embodiments the properties file can also be used to describe when a content developer envisions a creative might be distributed to a client device. For example, certain creatives might be designated for distribution to specified smartphones, or for use with specified applications or in specified contexts, etc.
The “myApp” directory also includes a folder for creatives 106 labeled “creatives” in
The “creatives” directory 106 illustrated in
Also, the second exemplary creative “bar” 110 also contains an “HTMLBanner” folder including a file named “index.html” and a folder named “ImageBanners”. As described above, in one example the “HTMLBanner” folder contains the HTML code for the creative, and the “ImageBanners” folder contains reveal images that are displayed during a transition from executing the creative to executing the targeted application. In other examples, a creative can have only an “HTMLBanner” folder or “ImageBanners” folder.
The digital content bundle also includes a targeted application “AppUnit” 112, which in most embodiments of the AppUnit application can be presented in full screen. The targeted application “AppUnit” includes an index.html file 114, which in this example, constitutes the targeted application and a manifest file 116, but can also include additional resources for use in association with the targeted application.
The manifest file 116 defines selected items that should be packaged with the targeted application for distribution to a client device, such as a smart phone. In some embodiments, the manifest file can also contain additional information, for example a command to compress the selected items to be packaged with the targeted application for distribution into a single file. The manifest file 116, in one embodiment, is a text file with paths for all resources to be included in the webarchive. If a resource is included in the manifest file, it also should be included in the “myApp” directory. Additional items that are not included in the manifest file can also be included in the “myApp” directory. A targeted application designer can choose which items are most important upon execution of the targeted application by listing these items in the manifest file; all other items can be downloaded after execution of the targeted application. This allows application developers to strike a balance between content immediately available upon execution of the targeted application and device performance characteristics such as speed and memory usage as will become more apparent from the description below.
In one example, the manifest file 116 can be formatted in the following manner: (1) The first line of the file must contain the manifest version such as “Manifest-Version X.X”; (2) Comments are allowed. Comments can be single line, start with a hash mark (#), and can appear on its own line; (3) Each file or path must appear on a line of its own; (4) All paths are relative to the manifest file; (5) If the path points to a directory, then the contents of that directory will be included in the webarchive file; and (6) If the path points to a file, then that file will be included in the webarchive file. This formatting is merely illustrative and other formatting techniques can be implemented.
The package including 102, 104, 106, 108, 110, 112, 114, and 116 can be compressed into a single file and then sent to a server for ingestion by the targeted application developer for distribution to client devices.
Upon ingesting, uncompressing, and analyzing the digital content package including the manifest file 116, the server, to which the targeted application bundle is uploaded, will create a webarchive 118 next to the manifest 116 file as shown. The webarchive 118 will contain the selected items as defined in the manifest file that will be sent with the application to a user device. In a further example, the server can create a webarchive file for each creative (not shown).
At step 212, once the server has ingested the compressed media package, the server can uncompress the media package and check the package for errors. This error checking process can include looking for proper acceptable structure of the file and ensuring there are no missing values for the media package. The server can analyze the manifest file. This analysis of the manifest file can include sanitizing paths to describe files listed in the manifest and other error detection techniques as needed. The server can also ignore paths that might cause security risks, such as paths that reference files that are not within the same folder or location as the manifest file.
Once the server completes any error detection, the method can include generating a webarchive file. In this example, the webarchive is created next to the manifest file 116. The webarchive contains the selected files or folders as defined in the paths in the manifest file that will be sent with the application to a user device. In one example, the folders and files in the webarchive can be compressed to a single file.
In some embodiments, the method can include generating a webarchive file for each creative in a content bundle. In this example, a webarchive file for a creative can include all files needed to run the creative, which in such embodiments, is itself a targeted application, hereinafter called “creative application.” In some embodiments, each creative application can have its own manifest file, to define selected items the server should place in each archive file. In this example, the server can create an archive file for a creative application in the same directory as its related manifest file.
In one example, the one or more creatives are in HTML and include a digital image. In another example, the one or more creatives can be a single image. In another example, the creative application is in HTML and includes a digital image.
The descriptive file with metadata can be in XML. The one or more creatives can be advertisements. Also, the targeted application can be an advertisement.
After generating the webarchive file, the server can select particular portions of the media bundle, in response to a device request, and send those selected portions to a client device to run within a user application.
The user application 304 can be any application that reserves a view 308 or a window or a frame to display the creative 306. In some embodiments, the view has a standard dimension that is consistent across all potential user applications. In some embodiments, the view 308 occupies about ten percent of the available screen area. Of course, the creative can occupy any desired portion of the user application. However, the area of the creative should not be so large as to obscure or detract from the user application, yet the creative should be large enough to view and interact with.
The creative 306 can be any image or application having content that is created with an audience in mind and can be targeted to that audience. For example, the creative can be a game for children; a web application targeted at sports fans; or an advertisement for home improvement products targeted at home owners. In some preferred embodiments, the creative 306 can have some relationship to the user application 304, such as a similarity in the target demographic for the audiences of both applications or in the nature of the content of the targeted applications, etc.
Multiple creative configurations can be downloaded if the device has multiple possible presentation formats, such as portrait and landscape. In such aspects, it is anticipated that a view in portrait will not be as desirable in landscape. In some embodiments, it is desired that the creative view and configuration occupy only about ten percent of the display. As illustrated in
When the device is in a first orientation, for example a portrait orientation, and then rotates to a second orientation, for example a landscape orientation, the creative view can resize along with the rest of the user application, and the creative view configuration for that orientation can be displayed. When the device is rotated into a different orientation, the user application will react to the change in orientation by rotating its view and resizing itself according to the new orientation. A user application that can be displayed in both landscape and portrait orientations can download a targeted application that can fit both orientations. When the device is rotated, the creative changes shape and animates to show content appropriate to the new aspect ratio. The content is still the same creative; it just has a slightly different representation for the new aspect ratio.
After a creative and a targeted application are sent to a client device, the creative, running in a user application (502), can be interactive and cause execution of the targeted application and closing of the creative in response to a user input. As illustrated in
Chipset 622 also can interface with one or more data network interfaces 625 that can have different physical interfaces 617. Such data network interfaces can include interfaces for wired and wireless local area networks, for broadband wireless networks, as well as personal area networks. Some applications of the methods disclosed herein can include receiving data over physical interface 617 or be generated by the machine itself by processor 620 analyzing data stored in memory 660 or 670. Further, the machine can receive inputs from a user via devices 636, 637, 638, 639 and execute appropriate functions, such as browsing functions, by interpreting these inputs using processor 620.
Methods according to the above-described examples can be implemented using computer-executable instructions that are stored or otherwise available from computer-readable media. Such instructions comprise, for example, instructions and data which cause or otherwise configure a general purpose computer, special purpose computer, or special-purpose processing device to perform a certain function or group of functions. Portions of computer resources used can be accessible over a network. The computer executable instructions may be, for example, binaries, intermediate-format instructions such as assembly language, firmware, or source code, including transitory signals carrying the instructions. Examples of computer-readable media that may be used to store instructions, information used, and/or information created during methods according to described examples include magnetic or optical disks, flash memory, USB devices provided with non-volatile memory, networked storage devices, and so on.
Devices implementing methods according to these disclosures can comprise hardware, firmware, and/or software, and can take any of a variety of form factors. Typical examples of such form factors include laptops, smart phones, small form factor personal computers, personal digital assistants, and so on. Functionality described herein also can be embodied in peripherals or add-in cards. Such functionality also can be implemented on a circuit board among different chips or different processes executing in a single device, by way of further example.
The instructions, media for conveying such instructions, computing resources for executing them, and other structures for supporting such computing resources are means for providing the functions described in these disclosures.
Although a variety of examples and other information was used to explain aspects within the scope of the appended claims, no limitation of the claims should be implied based on particular features or arrangements in such examples, as one of ordinary skill would be able to use these examples to derive a wide variety of implementations. Further, and although some subject matter may have been described in language specific to examples of structural features and/or method steps, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to these described features or acts. For example, such functionality can be distributed differently or performed in components other than those identified herein. Rather, the described features and steps are disclosed as examples of components of systems and methods within the scope of the appended claims.
