Abstract:
A method allows for content that exceeds the maximum size limit imposed by mobile infrastructures to be delivered to mobile devices. To accomplish this, the application splits large files into smaller chunks of data and sends the individual chunks to the mobile device, reassembling them on the device.

Description:
REFERENCE TO RELATED APPLICATIONS 
       [0001]    The present application claims the benefits, under 35 U.S.C. §119(e), of U.S. Provisional Application Ser. No. 61/008,819 filed Dec. 20, 2007 entitled “A Method and System for the Delivery of Large Content Assets to a Smartphone over a Mobile Network” and Ser. No. 61/66105 filed Feb. 15, 2008 entitled “Method and System for the Delivery of Large Content Assets to a Smartphone over a Mobile Network” which are incorporated herein by this reference. 
     
    
     TECHNICAL FIELD 
       [0002]    The application relates to the field of delivery of files to a mobile handheld device, such as delivery of files containing content such as graphics, audio and video to mobile devices. 
       BACKGROUND 
       [0003]    There are currently size restrictions imposed by carriers and/or mobile handheld device infrastructures that limit the transfer of large files to mobile handheld devices. Smartphones that utilize particular technology are therefore forced to adhere to this limitation. Content that exceeds the maximum allowable file size are considered undeliverable. For some systems this limit is set at 1 MB. 
         [0004]    Within some mobile handheld device infrastructures, administrators are permitted to set the maximum allowable size of a file transfer to the mobile handheld device. While such systems no longer had a maximum size limit, the reliability of carrier networks for large files is a problem. Failures were repeatedly seen when delivering files over a certain size due to carrier coverage issues and latencies inherent in the mobile handheld device infrastructure. This results in an imposed limited size on file delivery. 
         [0005]    In both of the above cases, timeouts occur while attempting to deliver content packages. The user can tether their device through a USB connection which may reduce the frequency of timeouts, however the size limit is still imposed. Previous methods of delivering large content assets or files to a Smartphone over a mobile network depended on a file chunk size being established before any content was published to any mobile device. If for some reason this file chunk size needed to be lowered (because, for example, the file transfer limits for the mobile handheld device infrastructure for receiving data was reduced thereby exceeding the established chunk size). then all content needed to be re-published. 
         [0006]    The foregoing examples of the related art and limitations related thereto are intended to be illustrative and not exclusive. Other limitations of the related art will become apparent to those of skill in the art upon a reading of the specification and a study of the drawings. 
     
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
         [0007]    Exemplary embodiments are illustrated in referenced figures of the drawings. It is intended that the embodiments and figures disclosed herein are to be considered illustrative rather than restrictive. 
           [0008]      FIG. 1  is a schematic drawing illustrating the method and system of the application for splitting of a large asset file. 
           [0009]      FIG. 2  is a schematic drawing illustrating the method and system of the application for delivery of large asset files. 
           [0010]      FIG. 3  is a flowchart illustrating a first embodiment of the method and system of the application for delivery of large asset files. 
           [0011]      FIG. 4  is a flowchart illustrating a second embodiment of the method and system of the application for delivery of large asset files. 
       
    
    
     DESCRIPTION 
       [0012]    Throughout the following description specific details are set forth in order to provide a more thorough understanding to persons skilled in the art. However, well known elements may not have been shown or described in detail to avoid unnecessarily obscuring the disclosure. Accordingly, the description and drawings are to be regarded in an illustrative, rather than a restrictive, sense. 
         [0013]    In referring herein to a “mobile device”, such mobile device is a two-way communication device with advanced data communication capabilities including the capability to communicate with other mobile devices or computer systems through a network of transceiver stations. The mobile device may also have the capability to allow voice communication. Depending on the functionality provided by the mobile device, it may be referred to as a data messaging device, a two-way pager, a cellular telephone with data messaging capabilities, a wireless Internet appliance, or a data communication device (with or without telephony capabilities). 
         [0014]    This application works in conjunction with the application described in pending international patent application no. PCT/CA2008/000851 published Nov. 13, 2008 entitled, “Method and System for Pushing Content to Mobile Devices” which is incorporated herein by reference. 
       Creating Content and Delivering to Users 
       [0015]    A first embodiment of the application is shown in  FIG. 3 . The author uses the Content Authoring and Publishing System— 100  to create, publish and centrally store new content formatted for mobile devices. Content can be described as one or more media types that when combined create a document or a content package. This package can have text, images, video and audio. When content requires the addition of a large asset file, such as a video, the user simply adds the file from the Digital Asset Library— 110 . 
         [0016]    Content created to be centrally stored in the central content storage can originate from any authoring platform that allows the insertion of media assets such as video or audio. Alternatively in another embodiment any large file could be added to the content package to be stored centrally. It is the central storage in the digital asset library that triggers the operations required to prepare the large file for delivery. 
         [0017]    When a user adds a file to the Digital Asset Library, the system compares the size of the file with the chunk size configuration setting. If the file size exceeds the chunk size configuration setting, the file is split into smaller chunks. The splitting of the file into smaller chunks or files can result in any number of files as long as any single file does not exceed the established maximum chunk size. The creation of these files can happen in any sequence. For example in the current embodiment, if the maximum chunk size is set at 256 KB and a 1000 KB file is saved, the system will create four files, as shown in  FIG. 1 . The first three files are 256 KB and the final one will contain the remaining 232 KB. This is all done internally by the application. To the user creating content, this will appear as one file. 
         [0018]    When the content has been created it can be assigned to users for consumption using the Content Assignment and Access Management— 200  functionality. This component makes a request to the Mobile Content Pushing System— 310  to send the content to the user&#39;s mobile device. This request is an XML document that contains all of the details of the content being pushed, including any assets, and target user information so the push can be directed to individual users. Large asset files are listed as a single file with an associated chunk count in this XML manifest. See  FIG. 2 . 
         [0019]    Alternatively embodiments could have the manifest implemented in other markup languages other than XML or in some other electronic file formats. The XML manifest is sent to the Delivery Queue— 400  where the Delivery Queue Web Service— 500  picks up the request. The Delivery Queue Web Service— 500  component listens for requests made by the Mobile Connector— 600 . These are requests to determine if there are items on the queue that the Mobile Connector is able to extract. If an item is found on the queue the Mobile Connector retrieves the queued item. 
       Delivering Content to the Mobile Device 
       [0020]    When the Mobile Connector— 600  retrieves an XML file from the Web service, it passes it to the Mobile Device— 700 . The Listener— 900  on the Mobile Device— 700  passes the XML file (manifest) to the Delivery Manager— 810 . The Delivery Manager— 810  extracts each content URL from the XML manifest and retrieves that piece of content from the Central Content Storage— 120  on the Mobile chalkboard Server. This content is delivered through the mobile handheld device infrastructure for sending and receiving data which then pushes it to the user&#39;s device. 
         [0021]    When a large asset file is part of the content package, it appears in the XML manifest as a single file with an associated chunk count. These chunks are received sequentially using HTTP Get Requests (“Pull”) and reassembled on the Mobile Content Player— 800 . Each of the chunks that comprise a large asset file is appended to the others as they are delivered to the mobile handheld device. Alternatively the chunks can be received in any order as long as they are assembled in the proper order on the mobile handheld device 
       Handling Failures 
       [0022]    For large asset files, if the delivery of any chunk fails, a retry process is initiated by the Delivery Manager— 810  built into the Mobile Content Player. Upon delivery failure, the delivery process stops and waits for a preset amount of time to elapse. This duration time is configurable. 
         [0023]    When the retry time has elapsed, the Delivery Manager initiates the pull mechanism again. The delivery process continues beginning with the failed asset chunk. The delivery of large asset files can be cancelled. If delivery fails again, the Delivery Manager again waits for the amount of time specified as the retry duration time. This retry process continues until either the content is delivered or the preset, configurable number of retries is reached and is considered a failure to deliver. If an asset could not be delivered, the Delivery Manager cleans up any chunks of that asset that were pulled to Mobile Content Player to minimize memory usage. All attempts to deliver content for large asset files are logged regardless of whether or not the delivery was a success or failure. Once the XML manifest has been received by the Mobile Device, the delivery of content is tracked. This status information is communicated back to the Mobile Content Delivery System from the Delivery Manager. The status of the content&#39;s consumption by the user is also tracked and reported (e.g. Content Received, Content Viewed, Content Completed). 
         [0024]    There are no latency issues with running the content because it is all stored locally on the mobile device. A user can view the content while going in and out of network coverage areas because the content is local to the device. 
         [0025]    A second embodiment of the Method and System for the Delivery of Large Content Assets to a Smartphone over a Mobile Network is shown in  FIG. 4 . 
       Creating Content and Delivering to Users 
       [0026]    As described above, an author first uses the Content Authoring and Publishing System— 100  to create, publish and centrally store new content formatted for mobile devices. When the content has been created it can be assigned to users for consumption using the Content Assignment and Access Management— 200  functionality. This component makes a request to the Mobile Content Pushing System— 310  to send the content to the user&#39;s mobile device. This request is an XML document that contains all of the details of the content being delivered, including any assets, and target user information so the delivery can be directed to individual users. The XML manifest is sent to the Delivery Queue— 400  where the Delivery Queue Web Service— 500  picks up the request. The Delivery Queue Web Service— 500  component listens for requests made by the Mobile Connector— 600 . These are requests to determine if there are items on the queue that the Mobile Connector— 600  is able to extract. If an item is found on the queue the Mobile Connector— 600  retrieves the queued item. 
       Delivering Content to the Mobile Device 
       [0027]    When the Mobile Connector— 600  retrieves an XML file from the Web service— 500 , it passes it to the Mobile Device— 700 . The Listener— 900  on the Mobile Device— 700  passes the XML file (manifest) to the Delivery Manager— 810 . The Delivery Manager— 810  extracts each content URL from the XML manifest and retrieves that piece of content from the Central Content Storage— 120  on the Mobile chalkboard Server. When a large asset file is part of the content package, the Delivery Manager— 810  first attempts to download the entire asset file. If it is larger than the mobile infrastructure allows then an error will occur and Delivery Manager— 810  will determine that it needs to bring down the file in smaller chunks. At this point the Delivery Manager— 810  creates an empty file on the mobile device  700  to store the large asset. 
         [0028]    Logic built into the Delivery Manager— 810  allows it to determine what asset size the mobile infrastructure will allow to be transferred. It does this by reducing the previously failed attempt to retrieve a large asset by some factor (in a preferred version this is ½) until it is successful. The resulting size (called chunk size) is then used to retrieve the rest of the large asset. The Delivery Manager— 810  writes the first successfully retrieved large asset chunk to the previously created empty file. It then requests the next chunk of the large asset by using the initial chunk size as an offset to the large asset file stored in the Central Content Storage— 120 . This is accomplished via an HTTP request to the large asset file with an offset as well as a file size specified. In this case the file size is always the chunk size and the offset keeps growing. 
         [0029]    These chunks of data are received sequentially using HTTP Get Requests (“Pull”) and are appended to the newly created file on the Mobile Device— 700  until all bytes are received. At this point, the file is closed and the Delivery Manager— 810  continues to extracts the remaining content listed in the XML manifest. When all of the content in a content package has been delivered to the Local Device Storage— 820  on the Mobile Device— 700 , it is available to be rendered to the user by the Mobile Content Player— 800 . 
         [0030]    Other implementations may utilize other protocols such as HTTPS or lower Level protocols such as TCP/IP to retrieve the file segments from the central storage. These protocols would need to support the retrieval of a specific file segment based on a starting position and a length. HTTP provides this capability as part of its standard implementation. It is possible that another protocol could be created/altered to accommodate this file segment retrieval requirement as well. Also the file segments can be retrieved out of sequence as long as they are all retrieved. This would be useful in a multi threaded mobile player where each thread is spawned to retrieve its own file segment. 
       Handling Failures 
       [0031]    For large asset files, if the delivery of any chunk of data fails, a retry process is initiated by the Delivery Manager— 810  built into the Mobile Content Player— 800 . Upon delivery failure, the delivery process stops and waits for a preset amount of time to elapse. This duration time is configurable. When the retry time has elapsed, the Delivery Manager— 810  initiates the pull mechanism again. The delivery process continues beginning with the failed asset data chunk. The delivery of large asset files can be cancelled. If delivery fails again, the Delivery Manager— 810  again waits for the amount of time specified as the retry duration time. This retry process continues until either the content is delivered or the preset, configurable number of retries is reached and is considered a failure to deliver. If an asset could not be delivered, the Delivery Manager— 810  cleans up any chunks of data of that asset that were pulled to Mobile Content Player— 800  to minimize memory usage. All attempts to deliver content for large asset files are logged regardless of whether or not the delivery was a success or failure. 
       Applications of the Technology 
       [0032]    This technology can be used to deliver any large asset files to a mobile device. These files can be media files, such as audio, video, animations or images. Practical applications of this application include:
       Training systems where courses are pushed to mobile users and groups   News readers through an RSS feed   Mapping applications and satellite imagery   Sending video and audio files   Sending applications and data files to the mobile device   Podcast subscriptions.       
 
         [0039]    While a number of exemplary aspects and embodiments have been discussed above, those of skill in the art will recognize certain modifications, permutations, additions and sub-combinations thereof. It is therefore intended that the application be interpreted to include all such modifications, permutations, additions and sub-combinations as are within its true spirit and scope.