US20130019269A1 - Method, system and apparatus for delivering data to a mobile electronic device - Google Patents
Method, system and apparatus for delivering data to a mobile electronic device Download PDFInfo
- Publication number
- US20130019269A1 US20130019269A1 US13/183,799 US201113183799A US2013019269A1 US 20130019269 A1 US20130019269 A1 US 20130019269A1 US 201113183799 A US201113183799 A US 201113183799A US 2013019269 A1 US2013019269 A1 US 2013019269A1
- Authority
- US
- United States
- Prior art keywords
- data
- nrt
- multimedia file
- file
- network identifier
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/41—Structure of client; Structure of client peripherals
- H04N21/4104—Peripherals receiving signals from specially adapted client devices
- H04N21/4126—The peripheral being portable, e.g. PDAs or mobile phones
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
- H04N21/4363—Adapting the video or multiplex stream to a specific local network, e.g. a IEEE 1394 or Bluetooth® network
- H04N21/43637—Adapting the video or multiplex stream to a specific local network, e.g. a IEEE 1394 or Bluetooth® network involving a wireless protocol, e.g. Bluetooth, RF or wireless LAN [IEEE 802.11]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/47—End-user applications
- H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
- H04N21/4722—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting additional data associated with the content
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Databases & Information Systems (AREA)
- Human Computer Interaction (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Mobile Radio Communication Systems (AREA)
- Information Transfer Between Computers (AREA)
Abstract
Description
- The specification relates generally to the delivery of data, and specifically to a method, system and apparatus for delivering data to a mobile electronic device.
- Mobile electronic devices are increasingly capable of receiving broadcast data, such as television streams. However, the mobile nature of such devices requires compromises to be made with respect to the size and strength of their receiving equipment. The computational capabilities of such mobile electronic devices also remain limited in comparison with their mains-powered, fixed counterparts such as television sets or desktop computers. The handling of data delivery by broadcast can result in inefficient use of the limited resources of mobile electronic devices.
- Embodiments are described with reference to the following figures, in which:
-
FIG. 1 depicts a system for delivering data to a mobile electronic device, according to a non-limiting embodiment; -
FIG. 2 depicts certain components of the mobile electronic device ofFIG. 1 , according to a non-limiting embodiment; -
FIG. 3 depicts certain components of the server ofFIG. 1 , according to a non-limiting embodiment; -
FIG. 4 depicts an example broadcast of data in the system ofFIG. 1 , according to a non-limiting embodiment; -
FIG. 5 depicts an example broadcast of further data in the system ofFIG. 1 , according to a non-limiting embodiment; -
FIG. 6 depicts an example interface generated at the mobile electronic device ofFIG. 1 , according to a non-limiting embodiment; -
FIG. 7 depicts a method of delivering Non-Real-Time (NRT) data to a mobile electronic device, according to a non-limiting embodiment; -
FIG. 8 depicts an exemplary performance ofblock 710 of the method ofFIG. 7 , according to a non-limiting embodiment; -
FIG. 9 depicts a method of delivering Non-Real-Time (NRT) data to a mobile electronic device, according to another non-limiting embodiment; -
FIG. 10 depicts an exemplary performance ofblock 910 of the method ofFIG. 9 , according to a non-limiting embodiment; and -
FIG. 11 depicts a method of delivering Non-Real-Time (NRT) data to a mobile electronic device, according to an additional non-limiting embodiment. - According to an aspect of the specification, a method of delivering data to a mobile electronic device is provided, the method comprising: storing the NRT data in a memory of a server, the NRT data comprising a multimedia file; storing at least one network identifier in the memory, the at least one network identifier identifying at least a portion of the multimedia file and a storage location of the multimedia file; formatting the NRT data using a processor of the server, wherein the formatting comprises generating header data including the at least one network identifier, and appending the multimedia file to the header data; and providing the formatted NRT data to broadcast equipment for broadcasting.
- According to another aspect of the specification, a non-transitory computer readable medium is provided for storing a plurality of computer-readable instructions executable by a processor, the instructions for implementing the above method.
- According to yet another aspect of the specification, a server is provided, comprising: a memory for storing NRT data comprising a multimedia file, and for storing at least one network identifier in the memory, the at least one network identifier identifying at least a portion of the multimedia file and a storage location of the multimedia file; a network interface controller (NIC); and a processor interconnected with the memory and the NIC, the processor configured to format the NRT data, wherein the formatting comprises generating header data including the at least one network identifier, and appending the multimedia file to the header data; the processor further configured to provide the formatted NRT data to broadcast equipment for broadcasting.
- As will be discussed below in greater detail, methods, systems and apparatuses are provided for delivering Non-Real-Time (NRT) data to mobile electronic devices, such as smart phone handsets. The methods, systems and apparatuses discussed herein are directed to three broad aspects relating to NRT data delivery: data segmentation, NRT schedule, and NRT Universal Resource Locators (URLs). The NRT schedule is a web-based repository where all NRT data that is planned for the next 24 hours (for example) can be found by the handset via the Internet. The handset can then download all the NRT data ahead of time, or the handset can download the NRT data later, or the handset can download only pieces of the NRT data that the handset did not receive as part of a public broadcast.
- NRT URLs are another option such that each and every NRT element (also referred to herein as formatted NRT data such as a multimedia file that has been processed for broadcasting) is studded with URL information (e.g., in various locations in the NRT field) and with heavier than normal data protection (e.g., forward encryption) such that if the handset encounters severe signal fade while decoding the NRT data in broadcast mode, the handset may still decode the URL and can then fetch the data via the generally more reliable wireless Internet (e.g., making use of mobile phone networks). Data segmentation is such that any significant NRT file can be segmented along with its URL, mentioned above such that if a broadcast of one file segment is missed by the handset, the URL for that segment can be used to retrieve the segment via wireless Internet rather than the entire file.
- The above aspects will now be discussed in greater detail with reference to the Figures. It is contemplated that various combinations of the above aspects can also be implemented, as will become apparent below.
-
FIG. 1 depicts asystem 100 for delivering data to a mobile electronic device.System 100 includes a plurality of mobile electronic devices, such as mobileelectronic devices electronic device 104 alone will be discussed in detail below, it is contemplated thatsystem 100 can include any number of mobile electronic devices, and that the below discussion of mobileelectronic device 104 will inform the nature and operation of any further mobile electronic devices, including mobileelectronic devices electronic device 104, as will be described in further detail below, can be based on any suitable mobile computing environment. Thus, mobileelectronic device 104 can be a cell phone, a smart phone, a tablet computer, a laptop computer, and the like. In the present example, mobileelectronic device 104 is a smart phone (also referred to earlier herein as a handset). - Mobile
electronic device 104 is connected with anetwork 108 via alink 112. It is contemplated thatnetwork 108 can include any suitable combination of wired and/or wireless networks, including but not limited to a Wide Area Network (WAN) such as the Internet, a Local Area Network (LAN), cell phone networks, WiFi networks, WiMax networks and the like. In the present embodiment,network 108 includes the Internet. Link 112 can be a wireless link based on any of Global System for Mobile communications (GSM), General Packet Radio Service (GPRS), Enhanced Data rates for GSM Evolution (EDGE), the third and fourth-generation mobile communication system (3G and 4G), Institute of Electrical and Electronic Engineers (IEEE) 802.11 (WiFi) or other wireless protocols. It will be understood thatlink 112 can also include any base stations and backhaul links necessary to connect mobileelectronic device 104 tonetwork 108. -
System 100 also includes aserver 116.Server 116, an example of which will be discussed in greater detail below, can be based on the computing environment of any known server architecture.Server 116 is connected withnetwork 108 via alink 120. In the present example,link 120 is a wired link, although it is also contemplated thatlink 120 can also be a wireless link, or any suitable combination of wired and wireless links. -
System 100 additionally includesbroadcasting equipment 124 interconnected withserver 116. It is contemplated thatbroadcasting equipment 124 can be co-located with server 116 (for example, in the same physical facility), and that the link betweenserver 116 andbroadcasting equipment 124 can thus lie outsidenetwork 108. In other examples (not shown),broadcasting equipment 124, or portions thereof, can be connected withserver 116 vianetwork 108. For example, multiple deployments of broadcasting equipment, generically referred to asbroadcasting equipment 124, can exist in various physical locations, some connected toserver 116 vianetwork 108 and others connected toserver 116 locally, outsidenetwork 108.Broadcasting equipment 124 can include any suitable combination of multiplexers, transmitters and the like for broadcasting data as a modulated radio frequency (RF)signal 128. The data which comprisesbroadcast signal 128 is stored in a non-transitory storage medium withinbroadcast equipment 124. Further, following receipt ofsignal 128 at mobileelectronic device 104, the data which comprisesbroadcast signal 128 is stored in a non-transitory storage medium, as will be discussed in greater detail below. - As used herein, the term “broadcast” refers to “one-to-many” communications where the “one” is
broadcasting equipment 124 and the “many” includes any device within range that is capable of receiving the broadcast. In other words, broadcast communications as discussed herein do not include individual devices when reached using unique destination addresses. - In general,
server 116 is configured to controlbroadcasting equipment 124 to broadcast data to mobile electronic device 104 (though as noted above,broadcast 128 is not explicitly addressed to or directed at mobileelectronic device 104 or any other device). Mobileelectronic device 104 is configured to receive the broadcasted data, store the data as necessary, and consume the data. For example, mobileelectronic device 104 can be configured to receive broadcast data representing a television show (e.g., encoded video data) and to display the received data, thus enabling the television show to be viewed on mobileelectronic device 104. - Data suitable for broadcasting is not particularly limited, and can include, for example, multimedia such as television channels, movies, music and the like. Such broadcasting, in the present example embodiment, can be carried out under the Advanced Television Systems Committee Mobile/Handheld (ATSC-M/H) standard. It is contemplated, however, that any other suitable broadcasting standard can also be used. For example, the Advanced Television Systems Committee (ATSC) standard can be employed by
server 116 andbroadcasting equipment 124. - Under these standards, in order to prepare a file for broadcasting,
server 116 is configured to add header data comprising one or more fields to the file. The fields of the header data define attributes of the file to be broadcast. For example, if the file is an episode of a television show, one field can include metadata for the file, comprising attributes such as the name of the television show, the title of the episode and the number of the episode.Server 116 can be configured to controlbroadcasting equipment 124 to broadcast multiple files simultaneously, for example in the form of multiple television channels (the files being multiplexed together prior to broadcasting). Thus, another field can be included in the header data for defining which channel the file belongs to. Once the header data has been added to the file, the file can be multiplexed with other prepared files as necessary and broadcast. Further discussion of the preparation, or formatting, of data for broadcasting will be provided below. - Turning to
FIG. 2 , a schematic representation of certain components of mobileelectronic device 104 is shown. Mobileelectronic device 104 includes aprocessor 200 interconnected with a non-transitory computer readable storage medium such as amemory 204.Memory 204 can be any suitable combination of volatile (e.g. Random Access Memory (“RAM”)) and non-volatile (e.g. read only memory (“ROM”), Electrically Erasable Programmable Read Only Memory (“EEPROM”), flash memory, magnetic computer storage device, or optical disc) memory. Mobileelectronic device 104 also includes one or more input devices interconnected withprocessor 200. Such input devices are configured to receive input and provide input data representative of the received input toprocessor 200. Input devices can include, for example, akeypad 208 and amicrophone 212. It is contemplated that mobileelectronic device 104 can include additional input devices in the form of one or more touch screens, touch pads, buttons, light sensors and the like (not shown). In general, it is contemplated that any suitable combination of the above-mentioned input devices can be incorporated into mobileelectronic device 104. - Mobile
electronic device 104 further includes one or more output devices. The output devices of mobileelectronic device 104 include adisplay 216.Display 216 includesdisplay circuitry 220 controllable byprocessor 200 for generating interfaces which include representations of data and/or applications maintained inmemory 204.Display 216 includes a flat panel display comprising any one of, or suitable combination of, a Liquid Crystal Display (LCD), a plasma display, an Organic Light Emitting Diode (OLED) display, and the like.Circuitry 220 can thus include any suitable combination of display buffers, transistors, LCD cells, plasma cells, phosphors, Light Emitting Diodes (LEDs) and the like. In embodiments that include a touch screen input device, the touch screen can be integrated withdisplay 216. - The output devices of mobile
electronic device 104 can also include aspeaker 224 interconnected withprocessor 200. Additional output devices can also be included, such as a light-emitting indicator (not shown) in the form of an LED, and the like. - Mobile
electronic device 104 also includes a bi-directional communications interface such as network interface controller (NIC) 228 interconnected withprocessor 200.NIC 228 allows mobileelectronic device 104 to communicate with other computing devices vialink 112 andnetwork 108.NIC 228 is interconnected withprocessor 200. It will now be understood thatNIC 228 is selected for compatibility withlink 112 as well as withnetwork 108.NIC 228 is a bi-directional communications interface in that mobileelectronic device 104 can, viaNIC 228, both receive and transmit data. Mobileelectronic device 104 also includes a uni-directional communications interface such as a tuner, or receiver, 230.Tuner 230 is interconnected withprocessor 200 and includes hardware, such as one or more antennae and associated circuitry, which enables mobileelectronic device 104 to receivebroadcasts 128 from broadcastingequipment 124.Tuner 230 is referred to as a unidirectional communications interface because it is contemplated that mobileelectronic device 104 can receive data viatuner 230, but cannot transmitdata using tuner 230. - Mobile
electronic device 104 maintains, inmemory 204, abroadcasting client application 232.Application 232 comprises a plurality of computer-readable instructions executable byprocessor 200. When executing the instructions ofapplication 232,processor 200 is configured to carry out various functionality related to the processing of broadcast data, as will be discussed below. - Mobile
electronic device 104 also includes adata store 236 in which received broadcast data, including both NRT data and real-time data, are maintained. It is contemplated that the storage of real-time data can be transient, in that such data can be written todata store 236 shortly before or simultaneously with its rendering ondisplay 216 and removed fromdata store 236 shortly thereafter. In other embodiments, real-time data can be received shortly before or simultaneously with rendering, and maintained for a configurable time period after rendering (for example,application 232 may provide mobileelectronic device 104 with the function to record received broadcasts or buffer broadcasts while viewing, to enable functionality such as replaying previously viewed content). - The various components of mobile
electronic device 104 are interconnected, for example via a communication bus (not shown). Mobileelectronic device 104 can be powered by a battery (not shown), though it will be understood that mobileelectronic device 104 can also be supplied with electricity by a wired connection to a wall outlet or other power source, for example when docked. - Turning now to
FIG. 3 , a schematic representation of certain components ofserver 116 is shown.Server 116 thus includes one or more processors such as aprocessor 300.Processor 300 is interconnected with a non-transitory computer-readable storage medium, such as amemory 304.Memory 304 can be any suitable combination of volatile (e.g. Random Access Memory (“RAM”)) and non-volatile (e.g. read only memory (“ROM”), Electrically Erasable Programmable Read Only Memory (“EEPROM”), flash memory, magnetic computer storage device, or optical disc) memory.Server 116 also includes one or more network interface controllers (NICs), such asNIC 308, for connectingserver 116 withnetwork 108 vialink 120. In general,NIC 308 is selected for compatibility withlink 120 and withnetwork 108.NIC 308 is additionally selected to allow for communications withbroadcast equipment 124, when broadcast equipment is co-located withserver 116. -
Server 116 can be managed by way of input and output devices (not shown) such as a keyboard, a mouse and a display. Such input and output devices can be co-located withserver 116 and connected withprocessor 300 via local connections (e.g. Universal Serial Bus (USB)). In other embodiments, the input and output devices can be located at a terminal (not shown) remote fromserver 116 and connected toserver 116 vianetwork 108 and link 120. In some embodiments, both local input devices and a remote terminal can be present, andserver 116 can be managed via either the local input devices or the remote terminal, as desired. -
Server 116 maintains, inmemory 304, abroadcasting server application 312.Application 312 also comprises a plurality of computer-readable instructions executable byprocessor 300. When executing the instructions ofapplication 312,processor 300 is configured to carry out various functions related to the delivery of data to mobileelectronic device 104.Server 116 also stores in memory 304 adata repository 316, in which data suitable for broadcasting is stored. - The data maintained in
repository 316 can include both real-time and non-real-time (NRT) data. NRT data is data which is broadcast for use at a later time. That is, while a real-time broadcast of an episode of a television show is generally for immediate consumption and can therefore be displayed by mobileelectronic device 104 substantially simultaneously with its receipt at mobileelectronic device 104, the broadcast of NRT data enablesserver 116 to distribute content that will not necessarily be displayed by mobileelectronic device 104 simultaneously with its broadcast and receipt. It is contemplated, however, that in some embodiments, real-time data can be saved for later consumption, and that NRT data can be displayed substantially simultaneously upon receipt. - A wide variety of data can be broadcast as NRT data, and is identified as such in
broadcast 128 by the inclusion of an NRT field in the header data described earlier. The NRT field will be discussed in greater detail below, and can include data such as a flag indicating that the data is NRT data, or a future time at which the data is to be used, or both. NRT data can also be broadcast alongside “regular”, real-time data, or during periods when less or no real-time data is being broadcast (thus leaving available bandwidth), or a combination of both. NRT data can also be consumed (for example, displayed at mobile electronic device 104) simultaneously with real-time data, or alone, or a combination thereof. - Referring now to
FIGS. 4 to 6 , an example use of NRT data in conjunction with real-time data will be described. Turning toFIG. 4 , an example delivery of NRT data comprising amultimedia file 400 is shown. In particular, file 400 is broadcast bybroadcast equipment 124 under the control ofserver 116.File 400 includes animage 404 and a network identifier 408 (such as a Uniform Resource Locator (URL)). It is contemplated thatfile 400 as broadcast would also include header data (not shown) as discussed above. The header data can include, for example, an indication of a time and date, which comprises an instruction to mobileelectronic device 104 as to when file 400 is to be consumed. It is contemplated that such an indication can also define a range of times and dates. The header data can include additional data, which will be discussed in connection withFIG. 7 . It is contemplated that a wide variety of multimedia files are possible. For example, either or both ofimage 404 andURL 408 can be omitted and replaced with video data.File 400 is received at mobileelectronic device 104 and stored indata store 236. - Turning to
FIG. 5 , at a later time,multimedia file 400 can be seen at mobileelectronic device 104. Real-time data 500 is broadcast to mobile electronic device, for substantially simultaneous display ondisplay 216. Real-time data 500 can be, for example, a video stream of a news program.FIG. 6 shows anexample interface 600 generated in response to the receipt of real-time data 500 at mobileelectronic device 104. In particular,interface 600 includes arepresentation 604 of real-time data 500 (which is updated as more real-time data 500 is received) and arepresentation 608 ofmultimedia file 400.Representation 608 includesimage 404, and selection ofrepresentation 608 causes mobileelectronic device 104 to transmit a request to a server (not shown) identified byURL 408. The request can cause the server to return weather data to mobileelectronic device 104, for rendering ondisplay 216 alongside the display ofrepresentation 604. - Other types of multimedia files are also contemplated. For example, file 400 can include instructions for causing mobile
electronic device 104 to automatically request updated weather data at certain time intervals, without requiring a selection ofrepresentation 608. - Turning now to
FIG. 7 , amethod 700 of delivering NRT data, such asmultimedia file 400, to a mobile electronic device is shown. The performance ofmethod 700 will be discussed in connection with its performance onsystem 100, though it will be appreciated thatmethod 700, and variations thereof, can also be performed on other suitable systems. The blocks ofmethod 700 are indicated as being performed at eitherserver 116 or mobileelectronic device 104. It is contemplated that those blocks performed atserver 116 are performed byprocessor 300, as configured via execution ofapplication 312. It is further contemplated that those blocks performed at mobileelectronic device 104 are performed byprocessor 200, as configured via execution ofapplication 232. - Beginning at
block 705,processor 300 is configured to store NRT data comprisingmultimedia file 400, in memory 304 (more specifically, in repository 316). It is contemplated that in some examples, the NRT data can comprise a plurality of multimedia files. Additional data can be maintained inrepository 316 in association withmultimedia file 400. For example, for file 400 (and for each other multimedia file stored inrepository 316 when NRT data comprises multiple multimedia files), a time and date of broadcasting can also be stored, indicating when the file is to be broadcast. Additionally, a time and date of use or consumption can be stored inmemory 304, indicating whenmultimedia file 400 is to be used, for example by displayingmultimedia file 400 at mobileelectronic device 104. - At
block 707,server 116 is configured to store at least one network identifier inmemory 304 in association withmultimedia file 400. Identifying at least a portion of the multimedia file and a storage location of the multimedia file; The network identifier can include, for example, a URL, an IP address, or a MAC address. In the present example, the network identifier is a URL. The at least one URL, and more generally, any network identifier stored inmemory 304, identifies at least a portion ofmultimedia file 400, and also identifies the storage location of file 400 (e.g.,.repository 316 ofserver 116, though other storage locations can also be used) onnetwork 108. Thus, an example URL stored atblock 707 forfile 400 is, “www.server116.com/400”, where the string “www.server116.com” identifiesrepository 316 onnetwork 108, and the string “400” identifies file 400 withinrepository 316 onnetwork 108. - Proceeding to block 710,
processor 300 is configured to selectmultimedia file 400 for broadcasting and to formatfile 400. It is contemplated thatfile 400 can be selected based on the time and date of broadcasting stored in association withfile 400 inrepository 316. It is also contemplated that a plurality of multimedia files defining the NRT data may have the same indicated times and dates of broadcasting, and that block 710 (and indeed, any portion ofmethod 700, including the entirety of method 700) can therefore be performed repeatedly for each of the multimedia files to be broadcast. - Having selected
file 400 for broadcasting,processor 300 is configured to format file 400 atblock 710.Formatting file 400 for broadcasting includes generating header data and appendingmultimedia file 400 to the header data. Header data is generated byprocessor 300 based on the above-mentioned data stored inmemory 304 in association withmultimedia file 400. In the present example, header data includes the above-mentioned network identifier, and can also include the time and date of use mentioned above. - Turning to
FIG. 8 , a schematic depiction of formattedNRT data 800, an example of the output ofblock 710, is shown. FormattedNRT data 800 includesheader data 804 and payload data, or content, 808.Header data 804, as seen inFIG. 8 , includesfields field 804 b, also referred to as an “NRT field”, contains attributes including a flag—shown as a binary value in FIG. 8—which indicates whether or not the payload is NRT data. The attributes also include the URL, or other network identifier, discussed above. The attributes can also include the time and date of use mentioned above (date not shown inFIG. 8 ). In some embodiments, a plurality of attributes comprising the URL can be included. - Additional fields can be included in
header data 804. For example, fields 804 a and 804 b can include attributes which define channel characteristics or any other information relevant to a broadcast in ATSC-MH. The format and contents offields header data 804, and the attributes included within each field, can be delimited by tags or other recognizable formatting data. - The
content portion 808 of formattedNRT data 800 includesmultimedia file 400, as described earlier. Thus, formatted NRT data comprisesheader data 804 withmultimedia file 400 appended thereto. Thus, in general terms, the performance ofblock 710 involves generating formattedNRT data 800 with at least one network identifier embedded therein. - The performance of
method 700 continues atblock 715, at whichprocessor 300 is configured to broadcast the formattedNRT data 800 resulting from the performance ofblock 710. Broadcasting formattedNRT data 800 comprises providingdata 800 tobroadcasting equipment 124 and/or controllingbroadcasting equipment 124 to broadcast formattedNRT data 800 in a one-to-many manner, for example, using the ATSC-M/H standard as discussed above. - At
block 720,processor 200 of mobileelectronic device 104 is configured to receive at least a portion of formattedNRT data 800 viatuner 230 and store the received data in memory 204 (in particular, in data store 236). Atblock 725,processor 200 is configured to determine if the data received atblock 720 is complete (that is, if the entirety of formattedNRT data 800 was received from broadcasting equipment 124). The determination atblock 725 can be based on, for example, start and end tags contained with formattedNRT data 800. That is, ifprocessor 200 detects a start tag at the beginning ofheader data 804 but no end tag at the end of content 808 (i.e. multimedia file 400),processor 200 can determine that the entirety of formattedNRT data 800 was not received. In another example embodiment, formattedNRT data 800 can include an indication of the total size of formattedNRT data 800. Thus, if the total size of the data received atblock 720 does not match that indication, the determination atblock 725 is negative. - It will now be apparent that the data received at
block 720 can be incomplete for a variety of reasons. For example, mobileelectronic device 104 can be in motion during the broadcast of formattedNRT data 800, and thus can be physically obstructed (by a bridge, tunnel, building and the like) from receiving a portion of formattedNRT data 800. - Following a negative determination at block 725 (e.g., meaning that the data received at
block 720 was not the complete formatted NRT data 800), performance ofmethod 700 proceeds to block 730, at whichprocessor 200 is configured to extract the at least one URL from the data received atblock 720. Thus,processor 200 can be configured to recognizeheader data 804, as well as any tags used to delimit the one or more URL attributes withinfield 804 b as described above. Having extracted the URL from the received data,processor 200 is configured to transmit a request toserver 116, viaNIC 228 andnetwork 108. Thus, while the data received atblock 720 was broadcast in a first standard such as ATSC-M/H, the request transmitted atblock 730 is made based on a second standard. That is, as used herein the term “transmit” refers to a different type of communication than the term “broadcast”. In particular, the term “transmit” refers to an explicitly addressed communication. The second standard can be a wireless communications standard such as Global System for Mobile Communications (GSM) or CDMA2000. Other suitable standards will now occur to those skilled in the art. The request can be, for example, a Hypertext Transfer Protocol (HTTP) request. The request includes the URL (or other network identifier) extracted from the data received atblock 720, and thus identifiesserver 116 andmultimedia file 400. It is also contemplated that whenfield 804 b ofheader data 800 includes more than one URL attribute,processor 200 can be configured to extract each URL attribute and to select the longest extracted URL, on the assumption that shorter URLs may have been incompletely received. - At
block 735,processor 300 ofserver 116 receives the request viaNIC 308.Processor 300 retrievesmultimedia file 400, which is identified by the request, atblock 740 and transmits the retrievedfile 400 to mobileelectronic device 104 vianetwork 108, in a message based on the above-mentioned second standard (e.g. GSM). - At
block 745,processor 200 is configured to receivemultimedia file 400 fromserver 116 viaNIC 228. Proceeding to block 750,processor 200 is configured to storemultimedia file 400 indata store 236 for later use (for example, in generatinginterface 600, discussed earlier). It should be noted that when the determination atblock 725 is affirmative (that is, whenprocessor 200 determines that the complete formattedNRT data 800 was received at block 720), the performance ofmethod 700 proceeds directly to block 750, at whichmultimedia file 400 can be extracted from formattedNRT data 800 and stored indata store 236. - Numerous variations to
method 700 are contemplated. For example, in some embodiments, as mentioned earlier in connection with the “data segmentation” aspect, in addition to the generation of header data comprising network identifiers,server 116 can be configured to generate a plurality of segments from multimedia file. Turning toFIG. 9 , amethod 900 of delivering NRT data according to the data segmentation aspect is shown. Beginning atblock 905,processor 300 is configured to store NRT data, as described above in connection withblock 705. Atblock 905, however,processor 300 is also configured to generate a plurality of segments frommultimedia file 400, the sum of the segments representing the entirety offile 400. Each segment is stored inrepository 316. The generation of segments is not particularly limited. For example, in some embodiments,processor 300 can be configured to generate segments that are substantially equal in size. In other embodiments,processor 300 can be configured to generate segments based on the contents offile 400. For example, a segment can be generated containingimage 404, while a second segment can be generated containingnetwork identifier 408. More generally,processor 300 can be configured to generate segments based on any suitable combination of criteria, including but not limited to segment size and data type. - At
block 907,processor 300 is configured to store a plurality of network identifiers. As discussed above, each network identifier identifiesrepository 316 at server 116 (or any other suitable storage location for multimedia file 400) as well asmultimedia file 400. In addition, each network identifier identifies the particular segment with which it is associated. Thus, for example, a URL for the first segment offile 400 can be, “www.server116.com/NRT400/seg1”. - It will now be understood that
processor 300 can also be configured to store additional data, such as time and dates of broadcasting and use, in association with either multimedia file as a whole or in association with each segment. Continuing atblock 910,processor 300 can be configured to select the NRT data for delivery substantially as discussed above. Also atblock 910,processor 300 is configured to format the NRT data by generating a plurality ofheaders 800. Oneheader 800 can be generated for each segment generated atblock 905, and each header can thus include the network identifier corresponding to the relevant segment. - It is contemplated that in some embodiments, the generation of segments can be performed at
block 910 rather than block 905. That is, the performance ofblock 905 can comprise storingmultimedia file 400 in its original form, and the performance ofblock 910 can comprise the generation and storage of segments. - Turning to
FIG. 10 , an example output ofblock 910 is shown, in which formattedNRT data 1000 includes a plurality of segments, each including header data 1004 and content 1008 (comprising a segment of file 400) appended to header data 1004. The totality of content portions 1008-1 and 1008-2 thus representmultimedia file 400. - Following the performance of
block 910, the remainder ofmethod 900 is as described above in connection withmethod 700. Thus, returning toFIG. 7 , formattedNRT data 1000 comprising the segments is broadcast, andprocessor 200 of mobileelectronic device 104 is configured, atblock 725, to determine if each segment is complete, and if all segments have been received. Various methods are contemplated for performing this determination. For example, each broadcasted file segment (or only some file segments, in other embodiments) can include data identifying all segments, the total number of segments, the order of segments, and the like.Processor 200 can therefore be configured to determine, after a configurable time period has elapsed or after the final segment has been received, whether each file segment has been received completely. - When
processor 200 determines, atblock 725, that one or more file segments were not received completely atblock 720,processor 200 may extract network identifiers (e.g. URLs) from any incomplete segments, and to transmit a request for each incomplete segment. In other embodiments,processor 200 may extract the network identifiers, and to transmit a single request for all incomplete file segments. - In a further variation,
processor 200 of mobileelectronic device 104 may transmit a request atblock 730 comprising an identifier of each multimedia file or file segment which was successfully received atblock 720. That is, rather than requesting missing files or file segments,processor 200 can transmit a request that informsserver 116 of which files or file segments are already present at mobileelectronic device 104. Thus,processor 300 ofserver 116 may, atblock 740, to determine which files or file segments have not yet been received at mobileelectronic device 104 by determining which file identifiers or segment identifiers are not contained within the request received atblock 735. - Still further variations are contemplated, as mentioned earlier in connection with the “NRT schedule” aspect. Turning to
FIG. 11 , a method of delivering NRT data is shown according to an additional non-limiting embodiment. Atblock 1105,server 116 can be configured to maintain a schedule, or list, of NRT data scheduled to be broadcast within a configurable predetermined time period. For example,processor 300 may generate and update a list of all multimedia files (such as multimedia file 400) with time and dates of use that occur within the next twenty-four hours. The period of twenty-four hours is provided solely as an example and a variety of other time periods can also be used, including but not limited to one hour and one week. - Having stored the schedule,
server 116 may, atblock 1110, receive a request from mobileelectronic device 104, transmitted atblock 1115 via a wireless communications standard such as GSM, for the schedule. In response to the request,server 116 can transmit the schedule, atblock 1120, to mobileelectronic device 104. The schedule can include the network identifiers (e.g. URLs) mentioned above for any multimedia files or file segments identified by the schedule. Thus, having received the schedule containing the network identifiers atblock 1125, mobileelectronic device 104 can request the associated files or file segments fromserver 116 atblock 1130, which can then be configured to transmit such files or file segments, as described above in connection withblocks method 700. - It is contemplated that mobile
electronic device 104 can be configured to request the schedule either independently from, or dependent on, the performance ofmethods block 730 can be transmitted by mobileelectronic device 104 without having received any broadcasted data. That is, such a request can be transmitted, for example at configurable intervals, independently of the performance ofmethod 700 ormethod 900. Thus, a request can be transmitted toserver 116 vianetwork 108 based on the above-mentioned second standard, causingserver 116 to return all NRT data which are to be consumed (i.e. used) in the twenty-four hour period following the request. In some embodiments, the request from mobileelectronic device 104 can include identifiers of any files or file segments received during earlier broadcasts or as a result of earlier such requests.Server 116 can then be configured to transmit only those multimedia files or segments which mobileelectronic device 104 “needs” (that is, for which identifiers were not included in the request). - In other embodiments, mobile
electronic device 104 can be configured to transmit a request for the schedule dependent on the results of the performance ofmethod block 725,processor 200 of mobileelectronic device 104 may transmit a request for the schedule toserver 116 rather than, or in addition to, the request transmitted atblock 730. For example, mobileelectronic device 104 may transmit a request for the schedule when some data was received atblock 720, but the received data was insufficient to successfully extract a URL. - Mobile
electronic device 104 can obtain an identifier, such as a URL, for the schedule in a variety of ways. For example, mobileelectronic device 104 can be preloaded with a URL identifying the Internet address of the schedule on server 116 (for example, by receipt of input data at keypad 208). In other embodiments, the URL for the schedule can be included in formattedNRT data - Those skilled in the art will appreciate that in some embodiments, the functionality of
applications - Other aspects of the specification will also now be apparent. For example, according to a further aspect, a method is provided comprising receiving, via a tuner of a mobile electronic device, broadcast data comprising at least a portion of formatted NRT data comprising a multimedia file; determining, using a processor of the mobile electronic device, if the formatted NRT data is complete; when the determination is negative, extracting a network identifier identifying at least a portion of the multimedia file and a storage location of the multimedia file from the formatted NRT data and transmitting, via a NIC of the mobile electronic device, a request containing the network identifier to a server.
- The method can further comprise receiving, in response to the request, at least a portion of the multimedia file, and storing the at least a portion of the multimedia file in a memory of the mobile electronic device.
- The broadcast can be based on a first standard, and the request and the response can be based on a second standard.
- The first standard can be one of the Advanced Television Systems Committee—Mobile/Handheld (ATSC-M/H) standard and the Advanced Television Systems Committee (ATSC) standard, and the second standard can be a wireless communications standard.
- The method can further comprise transmitting a request for a schedule, the schedule comprising at least one network identifier.
- The method can further comprise receiving the schedule in response to the request, via the NIC; and transmitting a request comprising one or more of the at least one network identifier included in the schedule.
- The request can include at least one identifier identifying a file or file segment stored in the memory.
- According to a further aspect, a mobile electronic device is provided configured to perform the above method.
- According to a still further aspect, a non-transitory computer-readable medium is provided, comprising computer-readable instruction executable by a processor of a mobile electronic device for carrying out the above method.
- Persons skilled in the art will appreciate that there are yet more alternative implementations and modifications possible for implementing the embodiments, and that the above implementations and examples are only illustrations of one or more embodiments. The scope, therefore, is only to be limited by the claims appended hereto.
Claims (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/183,799 US8850492B2 (en) | 2011-07-15 | 2011-07-15 | Method, system and apparatus for delivering data to a mobile electronic device |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/183,799 US8850492B2 (en) | 2011-07-15 | 2011-07-15 | Method, system and apparatus for delivering data to a mobile electronic device |
Publications (2)
Publication Number | Publication Date |
---|---|
US20130019269A1 true US20130019269A1 (en) | 2013-01-17 |
US8850492B2 US8850492B2 (en) | 2014-09-30 |
Family
ID=47519721
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/183,799 Active 2031-09-03 US8850492B2 (en) | 2011-07-15 | 2011-07-15 | Method, system and apparatus for delivering data to a mobile electronic device |
Country Status (1)
Country | Link |
---|---|
US (1) | US8850492B2 (en) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130104175A1 (en) * | 2011-10-25 | 2013-04-25 | At&T Intellectual Property I.L.P. | Using Video Viewing Patterns to Determine Content Placement |
US20140208375A1 (en) * | 2013-01-24 | 2014-07-24 | Sony Corporation | Distributed non-real-time content |
US20150118962A1 (en) * | 2013-10-25 | 2015-04-30 | Htc Corporation | Method of Identifying Wireless Power Receiver in Wireless Power System |
JP2015180488A (en) * | 2014-03-04 | 2015-10-15 | 株式会社Screenホールディングス | Heat treatment method and heat treatment apparatus |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20090150487A1 (en) * | 1996-09-12 | 2009-06-11 | Howard Wolfish | Digital Information Library and Delivery System |
US20100313235A1 (en) * | 2009-06-05 | 2010-12-09 | Time Warner Cable Inc. | Providing syndication feed content on a television set-top box with limited decoder capability |
US20110202955A1 (en) * | 1999-10-29 | 2011-08-18 | Marler Jerilyn L | Identifying Ancillary Information Associated With An Audio/Video Program |
US8316401B2 (en) * | 2009-10-25 | 2012-11-20 | Lg Electronics Inc. | Method for processing broadcast program information and broadcast receiver |
US8549566B2 (en) * | 2008-12-09 | 2013-10-01 | Lg Electronics Inc. | Method of processing non-real time service and broadcast receiver |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050193408A1 (en) | 2000-07-24 | 2005-09-01 | Vivcom, Inc. | Generating, transporting, processing, storing and presenting segmentation information for audio-visual programs |
US7721337B2 (en) | 2001-10-26 | 2010-05-18 | Ibiquity Digital Corporation | System and method for providing a push of background data |
US8099752B2 (en) | 2008-12-03 | 2012-01-17 | Sony Corporation | Non-real time services |
US20100281108A1 (en) | 2009-05-01 | 2010-11-04 | Cohen Ronald H | Provision of Content Correlated with Events |
-
2011
- 2011-07-15 US US13/183,799 patent/US8850492B2/en active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20090150487A1 (en) * | 1996-09-12 | 2009-06-11 | Howard Wolfish | Digital Information Library and Delivery System |
US20110202955A1 (en) * | 1999-10-29 | 2011-08-18 | Marler Jerilyn L | Identifying Ancillary Information Associated With An Audio/Video Program |
US8549566B2 (en) * | 2008-12-09 | 2013-10-01 | Lg Electronics Inc. | Method of processing non-real time service and broadcast receiver |
US20100313235A1 (en) * | 2009-06-05 | 2010-12-09 | Time Warner Cable Inc. | Providing syndication feed content on a television set-top box with limited decoder capability |
US8316401B2 (en) * | 2009-10-25 | 2012-11-20 | Lg Electronics Inc. | Method for processing broadcast program information and broadcast receiver |
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130104175A1 (en) * | 2011-10-25 | 2013-04-25 | At&T Intellectual Property I.L.P. | Using Video Viewing Patterns to Determine Content Placement |
US8799967B2 (en) * | 2011-10-25 | 2014-08-05 | At&T Intellectual Property I, L.P. | Using video viewing patterns to determine content placement |
US20140208375A1 (en) * | 2013-01-24 | 2014-07-24 | Sony Corporation | Distributed non-real-time content |
WO2014116515A1 (en) * | 2013-01-24 | 2014-07-31 | Sony Corporation | Distributed non-real-time content |
KR20150100804A (en) * | 2013-01-24 | 2015-09-02 | 소니 주식회사 | Distributed non-real-time content |
CN104919807A (en) * | 2013-01-24 | 2015-09-16 | 索尼公司 | Distributed non-real-time content |
KR101719442B1 (en) * | 2013-01-24 | 2017-03-23 | 소니 주식회사 | Distributed non-real-time content |
US10257564B2 (en) * | 2013-01-24 | 2019-04-09 | Saturn Licensing Llc | Distributed non-real-time content |
US20150118962A1 (en) * | 2013-10-25 | 2015-04-30 | Htc Corporation | Method of Identifying Wireless Power Receiver in Wireless Power System |
US9548795B2 (en) * | 2013-10-25 | 2017-01-17 | Htc Corporation | Method of identifying wireless power receiver in wireless power system |
JP2015180488A (en) * | 2014-03-04 | 2015-10-15 | 株式会社Screenホールディングス | Heat treatment method and heat treatment apparatus |
Also Published As
Publication number | Publication date |
---|---|
US8850492B2 (en) | 2014-09-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9538260B2 (en) | Receiving device, receiving method, program, and broadcasting system | |
JPWO2013157440A1 (en) | Reception device, reception method, transmission device, transmission method, and program | |
CN101297535A (en) | Methods, systems and computer program products for accessing downloadable content associated with received broadcast content | |
US9219950B2 (en) | Reproduction apparatus, reproduction method, and program | |
CN108668143B (en) | Drainage method, device, server and storage medium | |
US20100088734A1 (en) | Reception apparatus, reception method, and server apparatus | |
US20110107367A1 (en) | System and method for broadcasting personal content to client devices in an electronic network | |
CN105324974A (en) | Multiple file delivery over unidirectional transport protocol sessions for a service | |
US9100727B2 (en) | Broadcasting links to enhanced content | |
EP2790383B1 (en) | Distribution control system, distribution system, distribution control method, and computer-readable storage medium | |
US9432737B2 (en) | Terminal device, server device, information processing method, program, and linked application supplying system | |
EP3534613A1 (en) | Information processing device and information processing method | |
US8850492B2 (en) | Method, system and apparatus for delivering data to a mobile electronic device | |
CN105491132A (en) | File server, terminal and file subpackage transmission method | |
US20080127290A1 (en) | Service guide fragmentation method, a server and a terminal for use in a radio communication network | |
KR20170136935A (en) | Apparatus and method for providing broadcasting service information in a broadcasting system | |
US20130148554A1 (en) | Electronic device and method for sharing contents via bluetooth network | |
CN109635131B (en) | Multimedia content list display method, pushing method, device and storage medium | |
KR20110062508A (en) | A method for sharing channel map of digital broadcast systems in a home network and a system thereof | |
US10194177B1 (en) | Interweaving media content | |
US20220014292A1 (en) | Display device and method for controlling same | |
CA2782922C (en) | Method, system and apparatus for delivering data to a mobile electronic device | |
US20070127472A1 (en) | Broadcast data communicating method, broadcast data receiving terminal, and broadcast data transmitting server | |
KR20160100048A (en) | Method for providing streaming data through node linking with base station, and node using the same | |
US20190200063A1 (en) | Method and device for providing content-related information of multimedia service |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: RESEARCH IN MOTION LIMITED, CANADA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HYMEL, JAMES ALLEN;REEL/FRAME:028564/0361 Effective date: 20110624 |
|
AS | Assignment |
Owner name: BLACKBERRY LIMITED, ONTARIO Free format text: CHANGE OF NAME;ASSIGNOR:RESEARCH IN MOTION LIMITED;REEL/FRAME:033283/0679 Effective date: 20130709 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551) Year of fee payment: 4 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 8 |
|
AS | Assignment |
Owner name: MALIKIE INNOVATIONS LIMITED, IRELAND Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:BLACKBERRY LIMITED;REEL/FRAME:064104/0103 Effective date: 20230511 |
|
AS | Assignment |
Owner name: MALIKIE INNOVATIONS LIMITED, IRELAND Free format text: NUNC PRO TUNC ASSIGNMENT;ASSIGNOR:BLACKBERRY LIMITED;REEL/FRAME:064270/0001 Effective date: 20230511 |