Abstract:
A mobile application development platform comprises a toolset configured to streamline the development process for mobile applications. The streamline development process can enable efficiencies for the development of applications such as video streaming and uploading as well as image delivery and uploading. The development platform provides multi-language support. The development platform also provides project management integration. The development platform also provides deployment technology for distributing content across multiple mobile device platforms.

Description:
RELATED APPLICATION INFORMATION  
       [0001]     This Application claims priority as a continuation in part under 35 U.S.C. §120 to U.S. patent application Ser. No. 11/265,982, entitled “Systems and Methods for Delivering and Using Video Applications for a Plurality of Mobile Platforms,” filed on Nov. 3, 2005 which is incorporated herein by reference as if set forth in full. 
     
    
     BACKGROUND  
       [0002]     1. Field of the Invention  
         [0003]     The invention generally relates to the development of applications for mobile platforms, and more particularly to systems and methods for developing applications that are compatible with a plurality of mobile platforms.  
         [0004]     2. Background of the Invention  
         [0005]     With recent advances in cellular telephone technology and the technology that goes into cellular telephones, cellular telephones are no longer used just for voice communication. Today&#39;s cellular telephones are used for text messaging, transmission of videos and images, and for maintaining the user&#39;s contacts and calendars in much the same way as conventional Personal Digital Assistants (PDA) used to. Cellular telephone technology has evolved in order to support these new uses. For example, today&#39;s cellular telephones include more powerful processors and higher memory densities in order to support increased functionality, such as the functionality traditionally supported by PDAs. Advances in LCD technology has led to larger screens, color screens, and the ability to display pictures and videos downloaded, or streamed to the cellular telephone. Additionally, many of today&#39;s cellular telephones also come equipped with a digital camera, or even a digital video camera that allow the user to take pictures or videos and display the pictures and videos on the cellular telephone display.  
         [0006]     These technological advances have led to increased sales of cellular telephones throughout North America and the world. It has been estimated that by the end of 2005, there will be two billion mobile service subscribers throughout the world and it is estimated that 735 million cellular telephones will be sold in 2005. Additionally, US wireless revenue for 2004 reached 145 billion. All of these numbers should continue to grow in coming years.  
         [0007]     To demonstrate the evolving use of cellular telephones, 47% of cellular telephone users will be able to receive video using their cellular phone by 2008. Currently, Americans send 2.5 billion text messages per month using their cellular telephones. And perhaps most telling with regard to the evolving use of cellular telephones, there were 1.5 million web logs, or (“blogs”) posted in the last two years using cellular phones. These “blogs” typically contain text, pictures, and/or video, uploaded by users to a web page using their cellular telephone.  
         [0008]     But these advances have also created problems. For example, there are a wide variety of diverse platforms for developing applications to be deployed on cellular telephones. There are also multiple carriers each with potentially their own protocols and specifications for how information and data is transferred using a cellular telephone. Additionally, there are wide variations in hardware among the cellular telephones being used today. These variations include different screen sizes, different memory capability, varying processor speeds, etc. In fact, in North America alone, there are 145 different cellular telephone types.  
         [0009]     All of the above variables make it difficult to design and deploy applications across multiple cellular telephone types. As a result, the market for new applications has become segmented with applications being developed on a platform-by-platform basis.  
         [0010]     For example, two applications that are becoming more and more popular for cell phone users can demonstrate the problem inherent in having so many different cellular telephone platforms and little standardization across these platforms. These two applications are uploading of digital photos from a cellular telephone and what has become known as “video blogging”, where videos are uploaded from the cell phone to a web page where they can be accessed at a later time. In order to upload photos from a cellular telephone to a web page hosted by a leading web service, the user must first verify the “camera phone&#39;s” system requirements. First, however, the user must have registered their phone with the web server. After verifying the camera phone system requirements, the registration information for the phone will be confirmed. The user can then take a picture with their camera phone. The user can then send an email to an email account hosted by the web server with the picture attached to the email. The email will then be received by the web server and the attached picture will automatically be uploaded into a mobile upload album account associated with the registered cellular telephone.  
         [0011]     The process of taking the picture, storing the picture, generating the email, and attaching the picture to the email in order to send the email to the web server can actually be quite time consuming. As a result, posting multiple pictures becomes burdensome. A lot of this burden could be eased if a single application for uploading pictures could be used by all cellular telephone types. But the difference in cellular telephones and the systems in which they operate prevent the use of a single application.  
         [0012]     “Video blogging” using the same web service requires a very similar process of verifying the camera phone system requirements, and verifying the cellular telephone&#39;s registration. Next, the user can compose a “blog entry” using the cellular telephone&#39;s use interface, e.g., keypad, etc. The “blog entry” can include a photo, text, or both. The blog entry can then be attached to an email generated by the user using the cellular telephone, and the email can then be sent to the web server. Again, generating the “blog entry”, generating the email, and attaching the blog entry to the email in order to send it to the web service can be prohibitively time consuming.  
         [0013]     A competing web service for “phone blogging” has a slightly different process, wherein the user can, for example, take a picture with the camera phone, and then send a message including the picture to a pre-determined number. The number is associated with the web service, which will then take the picture and post it on a website where it can be viewed at a later time. Other services allow the user to take a picture, create some text, and then send it to a web page or email address, from which it can be posted onto a website for later viewing. As with the above web service, these processes can still prove to be prohibitively time consuming.  
         [0014]     Still, such services are proving to be very popular. The popularity, and therefore use of such services, could be increased even further if the prohibitive time delays involved in using such services could be eliminated. Eliminating such time delays is in large part dependent upon developing a uniform application that could be used by all cellular telephone types and in all systems.  
       SUMMARY  
       [0015]     A content management system is configured to receive content for distribution to a plurality of mobile devices. The content management system can be configured to convert the content into a plurality of versions that are customized for various device platforms. The correct version can then be downloaded to each mobile device. The conversion process optimizes the content for each device so that the content can be viewed, or accessed in the most efficient manner.  
         [0016]     In one aspect, the content management system can be configured to convert the content in real time.  
         [0017]     In another aspect, the content management system can be configured to allow the correct version of the content to be accessed by a mobile device without previous knowledge of the mobile device type. This is achieved by interrogating the mobile device to determine information about the mobile device type.  
         [0018]     These and other features, aspects, and embodiments of the invention are described below in the section entitled “Detailed Description.” 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0019]     Features, aspects, and embodiments of the inventions are described in conjunction with the attached drawings, in which:  
         [0020]      FIG. 1  is a diagram illustrating an example development platform configured in accordance with one embodiment;  
         [0021]      FIG. 2  is a diagram illustrating an example process of converting an application developed in one language into an application of another language using the development platform of  FIG. 1 ;  
         [0022]      FIG. 3  is a flowchart illustrating an example process for developing applications using the development platform of  FIG. 1 ;  
         [0023]      FIG. 4  is a diagram illustrating an example content delivery system comprising a development platform, such as the platform illustrated in  FIG. 1 , in accordance with one embodiment;  
         [0024]      FIG. 5  is a diagram illustrating an example content delivery system comprising a development platform such as the platform illustrated in  FIG. 1 , in accordance with another embodiment;  
         [0025]      FIGS. 6-20  are screenshots illustrating example screens that can be displayed on a mobile communication device as well as on a website in relation to a vlogger application developed using the development platform of  FIG. 1 ;  
         [0026]      FIG. 21  is a diagram illustrating an example communication system that can be configured to provide blogging service in accordance with one embodiment;  
         [0027]      FIGS. 22-31  are screenshots illustrating example screens that can be displayed by a backend mobile ad management system included in the system of  FIG. 21 ;  
         [0028]      FIG. 32  is a screen shot illustrating the customizing of a generic ad campaign for users within a certain geographic area.  
         [0029]      FIG. 33  is a diagram illustrating an example content management system configured in accordance with one embodiment;  
         [0030]      FIG. 34  is a flow chart illustrating an example process for delivering content using the system of  FIG. 32  in accordance with one embodiment;  
         [0031]      FIG. 35  is a flow chart illustrating an example process for converting content to be delivered using the system of  FIG. 32  in accordance with one embodiment; and  
         [0032]      FIG. 36  is a diagram illustrating an example process for converting content to be delivered using the system of  FIG. 3  in real time in accordance with one embodiment. 
     
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS  
       [0033]      FIG. 1  is a diagram of a development platform  100  that can be configured to allow an application to be developed and “pushed out” to any of a plurality of mobile device platforms in accordance with one embodiment of the systems and methods described herein. The term “mobile device” as used in the following description and claims that follow is intended to refer to any type of mobile communication device, including traditional cellular telephones, PCS telephones, smart phones, PDA devices that include cellular or PCS communication capability, or any other portable device that can be used for voice communication. Thus, while the term “mobile device” is used in the description of the embodiments below, the use of this term should not be seen as limiting the embodiments to any particular type of device or communication platform.  
         [0034]     As can be seen, platform  100  comprises a plurality of modules that can be used in the development of device agnostic applications. In the embodiment illustrated in  FIG. 1 , these modules are organized into three categories. These categories are development modules  102 , production modules  116 , and service modules  118 . Development modules  102  can be used to enable the development of applications that are compatible with any of the various development platforms currently supported by the many mobile device types in existence. Production modules  116  can be used to allow delivery of the applications developed using development modules  102  across a wide variety of mobile device platforms. Service modules  118  can be used to enable the provisioning and tracking of services related to the applications developed using development modules  102  and delivered using production module  116 .  
         [0035]     Development modules  102  include a compiler module  104  which can be configured to compile an application developed in one of the plurality of standard languages and facilitate conversion of the application into other applications so that the application can be supported by a plurality of platforms.  
         [0036]     Development modules  102  also include a core engine module  106 , which can be configured to take the code compiled by compiler module  104  and generate code that is compatible for a platform that supports a language different from the language that the original application is written in.  
         [0037]     Development modules  102  also comprise optional module  108 , which can be configured to optimize the applications developed using core engines  106 . For example, optional modules  108  can be configured to optimize the application for multimedia applications, “blogging” applications, and various compression techniques.  
         [0038]     Development modules  102  also include a foundation module  110  which are configured to customize the application for a genre-specific application. For example, if the application is a game, foundation module  110  can customize the game for the various platforms.  
         [0039]     Development modules  102  can also include an asset management module  112 . Asset management module  112  can be configured to manage assets associated with specific applications. For example, in gaming applications, asset management module  112  can be configured to allow the application to manage information, such as map data, player data, and images associated with the game.  
         [0040]     Development modules  102  can also include a content networking component  114 , which can be configured to enable or optimize content networking between components of the application.  
         [0041]     Platform  100 , and the modules that comprise platform  100 , are configured to enable an application to be written in one standard language and then converted, in an economical fashion, to other languages so that the application can be “pushed out” to as many mobile device platforms as possible.  
         [0042]      FIG. 2  is a diagram illustrating the process of converting an application developed in one language into an application of another language. Thus, in  FIG. 2  an application that is written in a foundation or a specific app code  110  can be provided to compiler module  104 . For example, the foundation language can be java. The java language application  110  can then be provided to compiler  104  which is configured to convert java language application  110  files into valid files in a standard language such as C or C++. Thus, compiler  104  can convert the java language application  110  into valid .cpp and .h files.  
         [0043]     The files developed by compiler  104  can then be provided to engine modules  106 . Each engine module  106  can be configured to convert the files provided by compiler module  104  into the standard language associated with the specific engine module. In the example of  FIG. 2 , compiler  104  provides the files to two engine modules  106   a  and  106   b . Engine  106   a  can be configured to convert the files into a BREW platform-specific application. Engine  106   b  can be configured to convert the file to a J2ME language-specific application.  
         [0044]     The applications generated by engines  106   a  and  106   b  can, for example, then be delivered to BREW and J2ME mobile device platforms, e.g., using production modules  116 .  
         [0045]      FIG. 3  is a flowchart illustrating the process for developing applications using platform  100  that can be “pushed out” to a plurality of mobile device platforms. Thus, in step  302 , standard language development kits, such as BREW or J2ME development toolkits, can be used to develop applications. In step  304 , the applications can be converted to a code supported by one of the engine modules  106 .  
         [0046]     This code can then be tested on a mobile device in step  306 . If the testing is successful, then the code can be supplied to compiler module  102  in step  308 . Compiler module  102  will convert the code into a code supported by a second engine module  106 . This code can then be tested on a mobile device in step  310 . If the testing is successful in step  310 , then the code developed for the second engine  106  can be reviewed for bugs or inefficiencies, in step  312 .  
         [0047]     As illustrated in  FIG. 4 , platform  100  enables the integration and delivery of an unlimited amount of content  400  across a plurality of mobile platforms  406  via delivery system  402 . Delivery system  402  comprises a deliver authority  404  configured to communicate with mobile devices  406  over communication channel  408 . Applications developed using platform  100  can be “pushed out” to mobile devices  406 , e.g., using server  404 . The applications can be configured to enable devices  406  to receive content  400 , which can also be delivered via server  404 . Because the applications are developed using the standardized modules comprising platform  100 , content  400  can be pushed out in an economical and efficient manner. Moreover, the content is not segmented, e.g., all content can be received and used by all mobile devices  406 . In other words, the content is not segmented, where certain content is designed for certain devices  406  and not for other devices  406 .  
         [0048]     The process of  FIG. 3  ensures that the content can be received and used by applications residing on all mobile devices  406 . Accordingly, platform  100  can be incorporated into a mobile content deployment platform that can be used to take any kind of content and push it out to any type of mobile device.  
         [0049]      FIG. 5  is a diagram illustrating a content delivery system  500  comprising a mobile content deployment platform  504  that includes a development platform  100 . Thus, mobile content deployment platform  504  can take content  502  and push it out to mobile devices  508  regardless of the type of content  502  or the type of device  508 . Deployment platform  504  can accomplish this because development platform  100  can be used to develop applications that comply with any of a plurality of languages, protocols, or standards  508 .  
         [0050]     In other words, development platform  100  can be used to develop applications that comply with the requirements of the different platforms  508  and that can be configured to use or take advantage of content  502 . These applications can then be pushed out to devices  508 . Content  502  can then be provided to devices  508  via deployment platform  504  as well. In other embodiments, content  502  can be provided to devices  508  through an alternative platform or server or service.  
         [0051]     For example, one type of application that can be developed using development platform  100  and pushed out to a plurality of different types of mobile communication devices  508  via content delivery system  500  is a video blogging, or “vlogger,” application.  
         [0052]      FIGS. 6-20  are screenshots illustrating example screens that can be displayed on a mobile communication device as well as on a website in relation to a vlogger application developed using development platform  100 . The screenshots of  FIGS. 6-17  are by way of example only, these screenshots should not be seen as limiting the systems and methods described herein to any particular type of screen size, resolution, display type, etc.  
         [0053]     A problem with conventional blogging applications is that uploading any kind of blog content, such as a picture, video, or text, is extremely time consuming. This delay is in large part due to the fact that there are no conventional blogging applications that are resident on the mobile device. Thus, there really is no conventional blogging application for mobile communication devices. Rather, such services take advantage of a plurality of applications, such as picture capture, email, etc., resident on the device; however, because there is no resident blogging application, the devices cannot be directly interfaced with the communication network, i.e., the Internet, over which the blog content must be uploaded to a web server. As a result, the user must go through many steps to get the blog content uploaded to a web server. For example, as explained above, conventional applications require the user to store the content, create an email addressed to a web server, attach the content to the email, and then send the email. Other conventional applications can use a text message, or a call placed over the communication network. Regardless, the steps involved are time consuming especially when a lot of content is to be uploaded.  
         [0054]     One reason that there are no conventional blogging applications is that each device, and each different network, have different protocols and procedures for accessing the Internet. Further, each mobile device can have different capabilities with regard to Internet access and performance when accessing the Internet. As a result, designers cannot design a single application that can run on any mobile device and be capable of interfacing the device with the Internet when the application is launched; however, because applications developed using development platform  100  are compatible with any device type, development platform, and network protocol, applications developed using development platform  100  can be used to interface the mobile device on which they reside with the Internet upon launching the application. In other words, the application is able to take advantage of the device resources and directly interface the device with the Internet when the application is launched.  
         [0055]     As a result, the process for uploading content to a web server can be streamlined and the time involved greatly reduced. Essentially, when the blogging application is launched, it can cause the device to connect with the Internet and with the web server providing blogging service. The user can then simply select the content and send it quickly and efficiently, e.g., by activating a send input on the mobile device. Thus, the process for sending a picture or video can be to capture the picture or video, launch the blogging application, select the picture or video file and push send. Alternatively, the blogging application can be launched first, the picture or video captured, the captured picture or video then sent by simply pushing a send button.  
         [0056]     It will be understood that the mechanism for indicating that the content should be sent can vary from device to device. For example, in certain embodiments, a button or keypad input can be used to indicate that the content should be sent. In other embodiments, an active input on the display can be actuated, e.g., using a finger or a stylus. In other embodiments, a menu entry can be selected in order to indicate that the content should be sent. Regardless of how the send indication is input, however, the whole process can be faster and more efficient because the blogging application is resident on the device and can take advantage of all the devices&#39; resources.  
         [0057]     Similarly, a blogging application developed using development platform  100  can also take full advantage of all of the network resources. As a result, content can be uploaded and downloaded at higher data rates because the application can be developed for the specific network resources and protocols.  
         [0058]     The screenshots of  FIGS. 6-20  can be used to illustrate the capability provided by applications developed using development platform  100 . The screenshots of  FIGS. 6-20  are related to a vlogger application and illustrate how video or picture content can be uploaded quickly and easily to a web server providing the vlogging service. Thus, a user can launch their vlogger application on their mobile device, which will cause the device to create a connection  612  with the server hosting the vlogger service. In the example of  FIG. 6 , as can be seen, when the vlogger application is first launched, an application screen  610  can be displayed on device  608 . The screen can have a menu of options that the user can access using user interface of device  608 . For example, if the user attempts to select video blogging on the menu, a display  604  can appear with a submenu as illustrated. When the user selects one of the entries in the submenu, a screen  606  can be displayed. In the example of  FIG. 6 , the user has selected the gallery option in screen  604  and in screen  606  an advertisement is being displayed while the device accesses the gallery information.  
         [0059]     The vlogger application can be used to upload blog content, i.e., pictures and videos, to a web page hosted by a web server providing the vlogger service. Screenshot  602  is a screenshot illustrating a web page that can be displayed when the user accesses the user&#39;s vlogger account from, e.g., a computer.  
         [0060]     By using development platform  100 , custom downloadable applications can be provided to, e.g., mobile device  608 . Thus, an application developed using development platform  100 , such as the vlogger application illustrated using screenshots  6 - 17 , will reside locally on the mobile device. The custom downloaded application developed using development platform  100  also provides the opportunity to provide a branded experience to the user. The branded experience can comprise content displayed on device  608  that is unique to the individual user, unique to the web service, or to particular advertisers. In fact, a mobile ad management backend system can be integrated with the web service that can allow highly targeted and custom advertisement to be pushed out across a plurality of mobile devices.  
         [0061]     A mobile ad management system is described in more detail below; however, some of the unique branding enabled by the systems and methods described herein is illustrated in screenshots  6 - 17 . Thus, in the descriptions that follow related to screenshots  6 - 17  some of the mobile ad capability provided by the systems and methods described herein will be described.  
         [0062]      FIG. 7  is a screenshot of a display that can be displayed when a vlogger application designed using development platform  100  is first launched. As can be seen in screenshot  702 , the display can comprise an advertisement  704 . In this instance, advertisement  704  is an advertisement for the website hosting the vlogger web service.  
         [0063]      FIG. 8  is a screenshot  810  of a display that can be displayed following advertisement  704 . As can be seen in screenshot  810 , the display can comprise an advertisement  804 . Here, advertisement  804  is for a third party product or service. The display can also comprise a status bar  802  configured to indicate the status of the vlogger application. In this case, status bar  802  indicates that the vlogger application is still loading. The display can also comprise an advertisement bar  806  configured to store a second advertisement. In this case, advertisement bar  806  contains an advertisement for the website providing the vlogger application.  
         [0064]      FIG. 9  is a screenshot  910  of a display that can be displayed once the vlogger application is loaded. The display can comprise a menu  902 . As can be seen, menu  902  can be branded with a picture  610  or other content identifying the user. In this case, content  610  is a picture of the user.  
         [0065]      FIG. 10  is a screenshot  1010  of a display that can be displayed when one of the entries in menu  902  is selected. The display comprises a submenu  1002 . In this case, the user has selected my profile in menu  902  which is taken then to a my accounts submenu  1002 .  
         [0066]      FIG. 11  is a screenshot  1110  illustrating a display that can be displayed after one of the entries in submenu  1002  has been selected. Again, while the content or application associated with the selection made in menu  1002  is loading, an advertisement  1102  can be displayed. In this case, advertisement  1102  is for a third party product of service. Status bar  1104  illustrates the progress related to loading of the application or content associated with the selected entry and menu  1002 .  
         [0067]     As can be seen, advertisement  1102  can contain dynamic links to content associated with advertisement  1102 . Here, a “click here” link is shown in the bottom of advertisement  1102 . Additionally, an instruction  1106  informs the user that they can press “5” on their device keypad in order to get more info related to advertisement  1102 .  
         [0068]      FIG. 12  is a screenshot of a display  1210  that comprises a menu  1202  associated with the vlogger application. Thus, the user can use menu  1202  in order to acquire new content and upload it to the website associated with the vlogging service.  
         [0069]      FIG. 13  illustrates a screenshot  1310  of a display that can be displayed when the vlogger application is launched an image is being acquired. Thus, an image  1302  can be displayed when a new video or picture selection is selected in menu  1202 . Picture  1302  is being provided via a video camera or camera included in device  608 . The display can include an instruction bar  1304  that instructs the user as to what steps to take. Here, instruction bar  1304  instructs the user to press  5  on their keypad in order to capture picture  1302 .  
         [0070]      FIG. 14  is a screenshot  1410  illustrating a display that can be displayed once image  1302  is captured, e.g., by pressing 5 on the keypad. Once image  1302  is captured, it can be displayed in the upper part of the display. In addition, a menu  1402  can be displayed allowing the user to edit picture  1302 , save picture  1302 , or go back to another picture. In addition, the user can name picture  1302  in text input box  1404 .  
         [0071]     Once picture  1302  is named, the user can elect to save it by selecting the save entry in menu  1402 . This will cause the vlogger application to upload picture  1302  to the web server.  
         [0072]      FIG. 15  is a screenshot  1510  illustrating a display that can be displayed once the save option has been selected. Again, an advertisement  1502  can be displayed while the picture is being uploaded. Status bar  1504  can provide the status of the upload procedure.  
         [0073]      FIG. 16  is a screenshot  1610  illustrating a display that can be displayed after the user has uploaded image  1302 . Display  1610  allows the user to name the picture in field  1602 , describe the contents in field  1604 , and add a summary for the picture in filed  1606 , which will be stored on the web page.  
         [0074]      FIG. 17  is a screenshot  1710  illustrating a display that can be displayed after picture  1302  has been stored. The display includes a menu  1702  of pictures or files that have been stored on the web page. A menu  1704  allows the user to add, edit, delete, and navigate between the stored pictures or files.  
         [0075]     Once the user has uploaded blog content, the user can then access the web page using a computer, such as a desk top or laptop computer in order to view the blog content.  
         [0076]      FIG. 21  is a diagram illustrating an example communication system  2100  that can be configured to provide blogging service in accordance with one embodiment of the systems and methods described herein. System  2100  can comprise a plurality of mobile communication devices  2102  comprising resident blogging applications  2120 . For convenience, a single mobile communication device  2102  is shown.  
         [0077]     Mobile communication device  2102  can upload blog content to a web server  2106  over the Internet  2104  using resident blogging applications  2120 . The blog content can be associated with one of a plurality of web pages  2108  hosted by web server  2106 . Users can then access web pages  2108  using computers  2112  interfaced with web server  2106  via a communication network. It will be understood that the communication network interfacing web server  2106  and computers  2112  can comprise the Internet as well. The communication network can also comprise a wired or wireless Local Area Network (LAN), wired or wireless Personal Area Network (PAN), wired or wireless Wide Area Network (WAN), wired or wireless Metropolitan Area Network (MAN), etc., or some combination thereof.  
         [0078]     Depending on the service, only the user of mobile device  2102  can access the associated web page  2108 . In other embodiments, other users can access the associated web page. Thus, access can be open to the public, or restricted, e.g., using a password, etc.  
         [0079]      FIG. 18  is a diagram illustrating a web page  1800  that can be displayed by server  2106  when a user access web server using a computer  2112 . AS can be seen, web page  1800  can comprise a sign in field  1802 . A registered user can provide their user ID, e.g., an email address, and password in order to can access to one or more web pages  2108 . A new user can create an account by selecting sign up option  1804 .  
         [0080]      FIG. 19  is a display  1900  that can be displayed when a user has selected sign up option  1804 . A sign up field  1904  can be displayed in which the user can provide an email address  1906 , name  1908 , password  1910 , as well as the number  1912  and model  1914  of their mobile device. This information is used to download resident, custom applications developed using development platform  100  to the user&#39;s mobile device.  
         [0081]     As illustrated in  FIG. 21 , and as described above, system  2100  can include a mobile ad management back-end system  2110  interfaced with web server  2106 . Back-end ad management system  2110  can enable advertisers to create ad campaigns that can be pushed out to mobile devices  2102 ; however, because resident, custom applications have not pushed out to devices  2102  using development platform  100 , the ad campaigns created using back-end mobile ad management system  2110  can provide custom advertising based on a variety of criteria. The custom ad capabilities can ensure that advertisement optimized for each device  2102  is delivered to the user, which increases the value of the ad campaign and provides customized branding.  
         [0082]     As illustrated in  FIG. 20 , a user can access an advertisement database using an advertise selection  2002 . In certain embodiments, only authorized users can access the advertisement database. In other embodiments, anyone who wants to sign up as an advertiser can access the advertisement database. Generally, the content access via advertise selection  2002  is restricted to advertisement associated with the user.  
         [0083]      FIG. 22  is a screenshot  2200  illustrating a display that can be displayed on the users&#39; computer when the user select advertise selection  2002 . As can be seen, the display can include an advertiser login field  2202 , in which the advertiser can supply an ID, or username  2204 , such as an e-mail address, and a password  2206 .  
         [0084]      FIG. 23  is a screenshot  2300  illustrating a display that can be displayed once the advertiser is successfully logged in. As can be seen, the display can include a menu  2302  that provides the advertiser several options. These options can include the ability to create a new advertising campaign or review an existing campaign, change the password or user ID, and review the advertiser&#39;s account with the web service.  
         [0085]      FIG. 24  is a screenshot  2400  illustrating a display that can be displayed when the advertiser selects the campaign option in menu  2302 . As can be seen, the display includes a list  2402  of current campaigns. The advertiser can scroll through the list and select the campaign to review.  
         [0086]      FIG. 25  is a screenshot  2500  illustrating a display that can be displayed once the user has selected a particular campaign. The display includes an advertising information field  2502 .  
         [0087]      FIG. 26  illustrates this information field  2502  in more detail. As can be seen, information field  2502  can include a main information field  2602  that includes information, such as a name of the company  2604 , the budget for the advertising campaign  2606 , the number of impressions, e.g., viewings  2608  desired, and an image  2610  to be associated with the ad campaign. When the advertiser selects a particular image or video file for the campaign, a sub-window  2504  can pop up allowing the advertiser to select the image or video file.  
         [0088]     Information field  2502  can also include a field  2614  that includes information regarding the target audience for the ad campaign. As can be seen, field  2614  can include a tool that allows the advertiser to select certain addresses for the targeted campaign.  
         [0089]      FIG. 27  is a screenshot illustrating an address field  2702  that can pop up when the user selects address to a  2612  in field  2614 . Address field  2702  can include a map section  2704  as well as an address field  2706  in which the advertiser can input address information in fields  2708 . Alternatively, the advertiser can simply select coordinates  2710  on map  2704 . The address information input by the advertiser can be used to specify a central point  2712  on the map for an area that the advertiser wishes to designate for a targeted advertisement campaign. In other words, the user can select the center point  2712  and then specify a range around center point  2712  for the targeted advertising campaign. The range can, for example, be specified as a number of miles from the center point.  
         [0090]     In other embodiments, the advertiser can simply specify a zip code on the map. The advertisement campaign can then be customized for the area code. Other geographic designations can also be used. For example, depending on the embodiment, area codes, city boundaries, etc., can be used alone or in combination with other designations.  
         [0091]     As illustrated in  FIG. 28 , field  2614  can also include fields  2802  and  2804  allow the advertiser to select the time and days, respectively, during which the advertising campaign will be active. As illustrated in  FIG. 29 , field  2804  can expand in order to allow the advertiser to select days on the calendar in fields  2902 .  
         [0092]     Thus, using the tools provided via back-end mobile ad management system  2110 , an advertiser can generate targeted ad campaigns. The ad campaigns themselves, e.g., the advertisement content, can then be constructed for delivery using development platform  100 . As illustrated in  FIG. 5 , content  502  can be converted into any of a plurality of development platforms, protocols, etc., using development platform  100 . As a result, the content delivered to each user can be customized for viewing using a resident, custom application that resides on the user&#39;s mobile device  2102 . The content can be pushed out to users as part of a separate application, e.g., a vlogger application. Alternatively, the content can simply be downloaded using a resident, custom video streaming or content downloading application resident on the user&#39;s device  2102 . Video streaming and content downloading applications are described in more detail below.  
         [0093]      FIG. 30  is a screenshot illustrating how the advertiser can create custom content for a custom advertisement campaign using the edit selection  3002 .  
         [0094]      FIG. 31A  is a screenshot of  3100  illustrating a display that can be displayed when an advertiser has selected the edit selection  3002 . The display includes a campaign edit field  3102  in which the advertiser can change the name of the campaign  3104 , budget  3106 , desired impressions  3108 , and the image  3110  associated with the campaign.  
         [0095]     The advertiser can use toolbar  3112  in order to select the new image  3110 . Once image  3110  is selected, however, it can be automatically reformatted into formats associated with the various device types, and display types included therein. As a result, image  3110  can be replicated into a plurality of images of different sizes and resolutions as illustrated in  FIGS. 31A-31C . The image replications are possible because design platform  100  includes information associated with each device and display type. The user can be allowed, depending on the embodiment, to actually change images on a more granular scale. In other words, for smaller displays the advertiser could select a certain image  3110 , but use a different image for larger displays. Thus, a toolbar, such as toolbar  3112  can be associated with each of the images in  FIGS. 31A-31C .  
         [0096]     Development platform  100  can also be configured to customize an ad campaign based on location information for mobile device  2102 . In other words, a generic advertising campaign can be created, then depending on the address information provided, users within a specific area can be given a customized version of the ad campaign.  
         [0097]      FIG. 32  illustrates the customizing of a generic ad campaign for users within a certain geographic area. Obviously, users in another geographic area would see a slightly different ad  3200 .  
         [0098]     As mentioned above, development platform  100  can also be used to develop and deploy resident, custom video streaming and/or content downloading applications. Conventional streaming and downloading applications are either limited, because the developer has to develop a generic application that is then pushed out to a plurality of devices, or because the developers are forced to develop a custom application for a single device. As a result, it is difficult to develop applications that are customized for all device types; however, because platform  100  can effectively, and efficiently develop applications that are customized for each device type, e.g., using the development process of  FIGS. 2 and 3 , a video streaming and/or content downloading application can be customized and verified for each device platform. As a result, higher data rates, greater resolution, and superior viewing quality can be achieved using development platform  100  to develop and deploy resident, custom video streaming and/or content downloading applications.  
         [0099]     Thus, using the systems and methods described above, custom downloadable applications can be created and deployed to a plurality of different device types quickly and efficiently. Exemplary applications include video uploading and streaming applications and image uploading and downloading applications. Further, the ability to deploy customized applications using the systems and methods described above can allow for custom ad management.  
         [0100]     For example,  FIG. 33  is a diagram illustrating a content management system  3300  configured in accordance with one embodiment of the systems and methods describe herein. Content management system  3300  can be configured to receive content from client servers  3314  and  3316 , adapt the content for a plurality of different mobile platforms, and then deliver the adapted content to a plurality of mobile devices  3318 . Mobile devices  3318  can comprise applications developed, e.g., using a development platform  100 , for viewing or handling the adapted content. Accordingly, because the applications and the content have been adapted, or optimized for each mobile platform, mobile devices  3318  can receive and handle the content with greater efficiency, which can improve quality and performance.  
         [0101]     Accordingly, mobile devices  3318 , of which two such devices are shown by way of convenience only, can comprise custom applications developed using development platform  100 . Platform  100  can be included within system  3300 , or it can comprise part of a separate system depending on the embodiment. Further, system  3300  can comprise a content deployment platform, such as platform  504  described above. System  3300  can also comprise the ability to customize content for the various mobile platforms, e.g., described in relation to the advertising content in  FIGS. 20-31 .  
         [0102]     System  3300  can comprise a Live Encoding Server (LES)  3302 , a On-Demand Encoding Server (ODES)  3304 , a Distribution Server (DS)  3306 , a Device Profile Server (DPS)  3308 , a Content Management Server (CMS)  3310 , and a Broadcast Server (BS)  3312 . It will be understood that each of the above components of system  3300  can comprise the hardware and software necessary to perform the functions described herein. Thus, in some embodiments, some or all of the various components can reside on a single hardware server, or platform, while in other embodiments, some or all of the components can reside on separate hardware servers, or platforms. Moreover, system  3300  can comprise other components not illustrated in  FIG. 33 , such as web servers, file servers, database servers, etc.  
         [0103]     Both LES  3302  and ODES  3304  are configured to receive content from client servers  3314  and  3316  for conversion and distribution to mobile devices  3318 . LES  3302 , however, is configured to receive live, or real-time content for streaming to devices  3318  as described below. DS  3306  can be configured to control distribution of content to mobile devices  3318  via BS  3312 . DPS  3308  can be configured to maintain mobile device platform profiles for use in the customization of content. CMS  3310  can be configured to maintain distribution profiles for the content, e.g., on a client by client basis.  
         [0104]      FIG. 34  is a flow chart illustrating an example method for distributing content using content management system  3300  in accordance with one embodiment. First, in step  3402 , a client, e.g., an advertiser or game developer, can log onto system  3300  and provide content, in step  3404 , to CMS  3310  via client server  3314 . It will be understood, the client server  3314  represents the systems and resources used by a client to interface and communicate with system  3300  and to upload content as described herein.  
         [0105]     The client can also specify, either previously or while logged onto system  3300  criteria for the distribution of the content uploaded in step  3404 . For example, as described above, the client can specify parameters that define an ad campaign, such as who the content should be delivered to, when it should be delivered, what geographic regions should be covered, etc.  
         [0106]     In step  3406 , CMS  3310  can provide the content to ODES  3304  for conversion, or formatting for the available mobile device platforms. Thus, in step  3408 , ODES  3304  can accept the content and place it into conversion que  3320  for conversion. An example conversion process is described below with respect to  FIG. 35 .  
         [0107]     In certain embodiments, CMS  3310  can, in step  3410 , inform mobile devices  3318  that the content has been added to content management system  3300  in accordance with the parameters specified by the client. In other words, CMS  3310  can inform the users specified by the client that new content has been added. CMS  3310  can then provide links, e.g., URLs, to the content so that the users can pull the content off of system  3300  using their associated device  3318 . CMS  3310  can communicate with mobile devices  3318  via BS  3312 .  
         [0108]     In other embodiments, the client can specify that the content is to be pushed out to certain mobile devices  3318 . Thus, in step  3412 , the content can be pushed to mobile devices  3318  via BS  3312  after the content is converted by ODES  3304 .  
         [0109]      FIG. 35  is a flow chart illustrating an example process for converting content uploaded from a client server  3316 . As noted above, content will be loaded into conversion que  3320  (step  3408 ). ODES  3304  can be configured to then query DPS  3308  for all available device profiles. These profiles can then be used to convert the content, in step  3504 , into a plurality of versions customized for each device platform. Such a process was described above for add content in relation to  FIGS. 31A-31C .  
         [0110]     In other words, DPS  3308  can store information concerning the capabilities, display type, display size, etc., for various device platforms. This information can be used by ODES  3304  to convert the content into a customized version for each platform. Such a conversion can comprise scaling the size of the content, the resolution of the content, removing certain types of content or converting certain types of content into a type that can be handled by a certain device. Further, where the content comprises executable portions, e.g., the content is a game, then ODES  3304  can convert the content into a device agnostic executable, e.g., using the development modules  102 .  
         [0111]     ODES  3304  can be configured to then upload the converted content to BS  3312  in step  3506 . In step  3508 , ODES  3304  can inform DS  3306  that the new content is ready. DS  3306  can query CMS  3310 , in step  3510 , to determine if the client instructed that the content be pushed out to devices  3318 . If so, then DS  3306  can instruct BS  3312  to push the data out in step  3512 .  
         [0112]     In certain embodiments, the user must specify what device platform, e.g., mobile device  3318 , they are using in order to access the correct version of the content. Thus, if the content is simply pushed out, a generic version can be used since system  3300  may not know the device types for all users. Alternatively, system  3300  can be configured to require the user to respond with platform information before pushing the correct version out.  
         [0113]     It should also be noted, that DS  3306  and/or BS  3312  can be configured to use production modules  116  and service modules  118  to deliver the content to device  3318 .  
         [0114]     In other embodiments, content management system  3300  can be configured to convert content in real-time.  
         [0115]      FIG. 36  is a flow chart illustrating an example method for converting content in real time using system  3300  in accordance with one embodiment. First in step  3602 , client server  3314  can be configured to provide a live or pre-recorded content to system  3300 . The content can, e.g., comprise audio, video, images, or some combination thereof. The live or pre-recorded content can actually be provided via any of a variety of sources, such as cable, satellite, television, DVD, CD, video cassette, a personal computer, radio, MP3 player, camcorder, game console, etc., and therefore may or may not involve server  3314 .  
         [0116]     The content is provided to LES  3302 , which can be configured to query DPS  3308  for all device profiles in step  3604 . LES  3302  can be configured to then encode the content for each profile in real-time and upload the encoded content to BS  3312  in step  3606 . LES  3302 , or ODES  3304 , can then inform DS  3306  of the availability of the new content in step  3608 . In step  3610 , DS  3306  can query CMS  3310  to determine whether the client instructed that the content be pushed out to certain users. If so, then DS  3306  can cause the content to be pushed out in step  3612  via BS  3312 . Again, this can comprise pushing a generic version of the content, since system  3300  will not necessarily know the platform type for each user.  
         [0117]     In other embodiments, a link to the content can be provide to each user. When the user access the link, DS  3306  can be configured to interrogate the user&#39;s device  3318  to discern information about the device platform in step  3614 . In step  3616 , DS  3306  can then cause the correct version of the content. Accordingly, the user is not required to know, or provide information concerning their device platform/type.  
         [0118]     While certain embodiments of the inventions have been described above, it will be understood that the embodiments described are by way of example only. Accordingly, the inventions should not be limited based on the described embodiments. Rather, the scope of the inventions described herein should only be limited in light of the claims that follow when taken in conjunction with the above description and accompanying drawings.