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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
  • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
  • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
  • H04N21/23614—Multiplexing of additional data and video streams
• • 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/4302—Content synchronisation processes, e.g. decoder synchronisation
  • H04N21/4307—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen
  • H04N21/43072—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen of multiple content streams on the same device
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
  • H04L65/1066—Session management
  • H04L65/1083—In-session procedures
  • H04L65/1089—In-session procedures by adding media; by removing media
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
  • H04L65/60—Network streaming of media packets
  • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
  • H04L65/613—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
• • 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
  • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
  • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
  • H04N21/2365—Multiplexing of several video streams
• • 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
  • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
  • H04N21/242—Synchronization processes, e.g. processing of PCR [Program Clock References]
• • 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/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
  • H04N21/4347—Demultiplexing of several video streams
• • 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/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
  • H04N21/4348—Demultiplexing of additional data and video streams
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
  • H04W4/18—Information format or content conversion, e.g. adaptation by the network of the transmitted or received information for the purpose of wireless delivery to users or terminals
  • H04W4/185—Information format or content conversion, e.g. adaptation by the network of the transmitted or received information for the purpose of wireless delivery to users or terminals by embedding added-value information into content, e.g. geo-tagging

Definitions

• the present invention is related to synchronizing multiple data feeds for optimized transmission and presentation on a mobile device display.
• Multi-feed streaming such as picture in picture and for providing leaderboard information for display on a mobile device along with a video of a live event presents challenges to network bandwidth demand and responsiveness to user selection of the individual feeds.
• a mobile device user often is unable to select how he would like to receive such multiple data feeds when such feeds may be delayed with respect to one another.
• coherent display of multiple related feeds that are not synchronized generally cause poor user experience.
• the methods and systems described herein may include time synchronized distinct video feeds (aka channels) in a single mobile device compatible stream that may include a device specific stream, a video player-specific stream, a Dynamic Adaptive Streaming over HTTP (DASH)-based stream, and the like.
• the methods and systems described herein may alternatively include time synchronization of a portion of a set of distinct video feeds in a single mobile device compatible stream so that real-time or "live" feeds may be synchronized.
• the methods and systems described herein may include time synchronized video feeds in a single mobile device compatible audio/video stream.
• the methods and systems described herein may include time synchronizing distinct video feeds for delivery to a mobile device via a single audio/video stream.
• the methods and systems described herein may include time synchronizing distinct video feeds that are received at a mobile device as a single audio/video stream for presentation to the user.
• synchronization may occur on the mobile device based on time-related data provided in a side channel and/or metadata associated with the single stream.
• the methods and systems described herein may include unified display of distinct video feeds transmitted via a single audio/video stream over a mobile device data network.
• the single audio/video stream may comprise any number of distinct video feeds and a single audio feed of one of the distinct video feeds.
• the methods and systems described herein may include selectively displaying on a mobile device one or more time synchronized distinct video feeds transmitted in a single audio/video stream.
• the selection may be automatic and may be based on location of the mobile device, content subscription associated with the mobile device, identification of a network carrier providing service to the mobile device, and the like.
• the mobile device may receive all of the distinct feeds as one stream and may select a subset of feeds to be presented to the user as described above.
• the methods and systems described herein may include time synchronizing select video feeds from a plurality of available video feeds and encoding the select video feeds into a single mobile device compatible stream. Selection may be based on location of a mobile device that requests streaming of at least one of the select video feeds
• the methods and systems described herein may include receiving distinct video/audio feeds including meta data for time synchronizing the distinct feeds into a single mobile-device compatible stream.
• Methods and systems described herein may include presenting a multi-view display in a portion of a device screen of a plurality of feeds that have been delivered to a mobile device as a single mobile IP data network compatible stream; and in response to a user action associated with the multi-view display, presenting a new view of content from at least one of the plurality of feeds.
• the user action may be a selection via a user interface of the mobile device of a portion of the multi-view display that includes content from a single feed.
• the new view may include a single feed that covers substantially the entire multi-view portion of the device screen.
• the methods and systems described herein for streaming a plurality of video feeds as a single mobile IP data network compatible stream and facilitating user interaction with the plurality of feeds via a coherent display of at least a portion of the video feeds may utilize the features and functionality described in co-pending applications incorporated herein by reference.
• Features and functions described the co-pending applications incorporated herein by reference, such as ingestion, encoding/transcoding, mediation, pause and resume, seamless switching among unicast/multicast/broadcast, preparation and use of a consumption profile, automated content tagging, and the like may be used to identify, ingest, aggregate, stream, and facilitate user interaction with a plurality of feeds that may include video, audio, content, and the like.
• the methods and systems described herein may include accessing with a server a plurality of distinct video feeds.
• the method further includes accessing time stamp information for at least a portion of the plurality of distinct video feeds.
• the method further includes comparing each time stamp information to a reference clock to determine a relative order of, and a relative time difference among, the portion of the plurality of distinct video feeds.
• the method further includes determining a synchronizing point in each of the plurality of distinct video feeds at which each feed may be synchronized relative to the reference clock.
• the method further includes combining the plurality of distinct video feeds to form a single video stream comprising a plurality of synchronized distinct video feeds based on the synchronizing point.
• the method may further include encoding the single video stream to form a composite mobile device compatible stream.
• the method may further include combining comprises at least one of interleaving, multiplexing, and concatenating.
• the combining may include delaying at least one of the plurality of distinct video feeds so that the delayed at least one of the plurality of distinct video feeds may be time synchronized with at least one other of the plurality of distinct video feeds.
• the step of combining the plurality of distinct video feeds may include sub-sampling each of the distinct video feeds so that the composite mobile device compatible stream takes no more bandwidth than one of the distinct video feeds.
• the stream may be one of a device specific stream, a video player- specific stream, and a
• the at least one of the distinct video feeds may include a live event feed.
• the time stamp information for the live event feed may be the reference clock, and wherein the plurality of distinct video feeds may be synchronized to the reference clock.
• the single video stream may include a plurality of synchronized distinct video feeds may be an internet protocol stream that may include metadata for each of the distinct video feeds.
• the metadata may facilitate converting the single video stream into the distinct video feeds for presentation on a mobile device screen.
• the metadata may facilitate identifying each of the distinct video feeds to a user interface application of a mobile device on which the distinct video feeds are being presented.
• the single video stream may include a plurality of synchronized distinct video feeds that may include a mosaic of the plurality of the distinct video feeds.
• the single video stream may include a mosaic that includes position information within the mosaic of each distinct video feeds.
• the single video stream may include a plurality of synchronized distinct video feeds that may include a single audio feed associated with one of the plurality of synchronized distinct video feeds.
• the methods and systems described herein may include accessing with a server a plurality of distinct feeds.
• the method may include accessing a feed clock associated with a source of at least one of the plurality of distinct feeds.
• the method may include accessing a reference clock.
• the method may include comparing the feed clock to the reference clock to determine latency between the at least one of the portion of the plurality of distinct feeds and the reference clock.
• the method may include determining a synchronizing point in each of the plurality of distinct feeds based on the determined latency at which each may be synchronized relative to the reference clock.
• the method may include aligning the synchronizing poit in each of the plurality of distinct feeds to facilitate delivery of synchronized feeds.
• the method may include combining the plurality of distinct feeds to form a single stream including a plurality of synchronized distinct feeds, based on the determined synchronizing point.
• a synchronization point may be a video frame.
• the method further includes encoding the single stream to form a composite mobile device compatible stream.
• the step of combining comprises at least one of interleaving, multiplexing, and concatenating.
• the step of combining comprises delaying at least one of the plurality of distinct feeds so that the delayed at least one of the plurality of distinct feeds may be time synchronized with at least one other of the plurality of distinct feeds.
• the step of combining the plurality of distinct feeds includes sub-sampling each of the distinct feeds so that the composite mobile device compatible stream takes no more bandwidth than one of the distinct feeds.
• the stream may be one of a device specific stream, a player-specific stream, and a DASH- based stream.
• the at least one of the distinct feeds comprises a live event feed.
• the time stamp information for the live event feed may be the reference clock, and wherein the plurality of distinct feeds may be synchronized to the reference clock.
• the single stream comprising a plurality of synchronized distinct feeds may be an internet protocol stream that comprises metadata for each of the distinct feeds.
• the single stream comprising a plurality of synchronized distinct feeds comprises a mosaic of the plurality of the distinct video feeds.
• the single stream comprising a mosaic further comprises position information within the mosaic of each distinct feed.
• the single stream comprising a plurality of distinct feeds further comprises a plurality of video feeds and a single audio feed associated with one
• the methods and systems described herein may include a method including receiving a single stream comprising a plurality of distinct feeds.
• the method may include receiving distinct feed data time information in a side channel associated with the stream.
• the method may include comparing the time information for each of the distinct feeds to determine a relative order of, and a relative time difference among, the plurality of distinct feeds.
• the method further includes determining a synchronizing point in each of the plurality of distinct feeds at which each may be synchronized.
• the method further includes presenting the plurality of distinct feeds synchronized in time based on the synchronizing point.
• the synchronizing point in each of the plurality of distinct feeds may be associated with a single time value.
• the step of presenting includes delaying at least one of the plurality of distinct feeds so that the delayed at least one of the plurality of distinct feeds may be time synchronized with at least one other of the plurality of distinct feeds.
• the single stream may be presented as a mosaic of the plurality of the distinct video feeds.
• the single stream further includes mosaic position information for each distinct video feed.
• the single stream includes a plurality of distinct feeds further comprises a plurality of video feeds and a single audio feed associated with one of the plurality of video feeds.
• the methods and systems described herein may include presenting a multi- view display, in a portion of a device screen, of a plurality of feeds that may have been delivered to a mobile device as a single mobile internet protocol data network compatible stream.
• the method includes presenting in response to a user action associated with the multi-view display, a new view of content from at least one of the plurality of feeds.
• the plurality of feeds may include a plurality of time synchronized distinct video feeds.
• the plurality of feeds may include a plurality of distinct video feeds and time information for synchronizing the plurality of feeds. The time information may be carried in a side channel of the single mobile internet protocol data network compatible stream.
• the user action may include a selection via a user interface of the mobile device of a portion of the multi-view display that may include content from the at least one of the plurality of feeds.
• the new view may include a single feed of the plurality of feeds that may cover substantially the entire multi-view display on the device screen.
• the methods and systems described herein may include receiving a plurality of feeds from a live event, wherein each feed may be associated with a feed-specific time stamp.
• the method includes providing in a user interface of a mobile device that may be receiving the feeds at least one interface feature that facilitates selecting between holding presentation of a portion of the plurality of feeds until an equivalent time stamp from all of the plurality of feeds may be received and presenting at least one of the plurality of feeds when it may be received.
• the plurality of feeds from a live event includes at least one video feed of the live event and a data feed derived from events at the live event.
• the data feed may include event real-time properties data.
• the at least one of the plurality of feeds to be presented when it may be received may be the data feed derived from events at the live event.
• the method further includes providing in the user interface at least one interface feature that may facilitate selecting between holding presentation of at least one of the plurality of feeds until an equivalent time stamp from at least one other of the plurality of feeds may be received and presenting at least one of the plurality of feeds when it may be received.
• the methods and systems described herein may include receiving a plurality of distinct video feeds and video feed time information that may facilitate determining a relative order of the distinct video feeds.
• the method further includes combining the plurality of distinct video feeds in the relative order.
• the method further includes generating a mobile device compatible stream from the ordered, combined plurality of distinct video feeds by processing the ordered, combined plurality of distinct video feeds with a mobile device compatible encoder.
• the step of combining may include at least one of interleaving, multiplexing, and concatenating.
• the step of combining may include delaying at least one of the plurality of distinct video feeds so that the delayed at least one of the plurality of distinct video feeds may be time synchronized with at least one other of the plurality of distinct video feeds.
• the methods and systems described herein may include accessing with a server a plurality of distinct video feeds comprising a sequence of video frames.
• the method further includes accessing time stamp information for at least a portion of the plurality of distinct video feeds.
• the method further includes comparing each of the time stamp information to a reference clock to determine a relative order of, and a relative time difference among, the portion of the plurality of distinct video feeds.
• the method further includes determining a synchronizing frame in each of the plurality of distinct video feeds at which each may be synchronized relative to the reference clock.
• the method further includes combining the video frames of the plurality of distinct video feeds to form a single video stream comprising a plurality of synchronized distinct video feeds based on the determined synchronizing frame.
• the method further includes encoding the video frames of the single video stream to form a composite mobile device compatible stream.
• the step of combining may include at least one of interleaving, multiplexing, and concatenating.
• the step of combining may include delaying at least one of the plurality of distinct video feeds so that the delayed at least one of the plurality of distinct video feeds may be time synchronized with at least one other of the plurality of distinct video feeds.
• the step of combining the video frames of the plurality of distinct video feeds includes sub-sampling each of the distinct video feeds so that the composite mobile device compatible stream takes no more bandwidth than one of the distinct video feeds.
• the stream may be one of a device specific stream, a video player-specific stream, and a DASH-based stream.
• the at least one of the distinct video feeds comprises a live event feed.
• the time stamp information for the live event feed may be the reference clock.
• the plurality of distinct video feeds may be synchronized to the reference clock.
• the single video stream may include a plurality of synchronized distinct video feeds may be an internet protocol stream that comprises metadata for each of the distinct video feeds.
• the metadata facilitates converting the single video stream into the distinct video feeds for presentation on a mobile device screen.
• the metadata facilitates identifying each of the distinct video feeds to a user interface application of a mobile device on which the distinct video feeds may have been presented.
• the single video stream may include a plurality of synchronized distinct video feeds includes a mosaic of the plurality of the distinct video feeds.
• the single video stream may include a mosaic further including position information within the mosaic of each distinct video feed.
• the single video stream may include a plurality of synchronized distinct video feeds further including a single audio feed associated with one of the plurality of synchronized distinct video feeds.
• the methods and systems described herein may include receiving a plurality of distinct feeds comprising at least one of audio and video and feed time information that may facilitate determining a relative order of the distinct feeds.
• the method further includes combining the plurality of distinct feeds in the relative order.
• the method further includes generating a mobile device compatible stream from the ordered, combined plurality of distinct feeds by processing the ordered, combined plurality of distinct feeds with a mobile device compatible encoder.
• the step of combining may include at least one of interleaving, multiplexing, and concatenating.
• the methods and systems described herein may include accessing with a server a plurality of distinct feeds comprising at least one of audio and video.
• the method includes accessing time stamp information for at least a portion of the plurality of distinct feeds.
• the method further includes comparing each of the time stamp information to a reference clock to determine a relative order of, and a relative time difference among, the portion of the plurality of distinct feeds.
• the method further includes determining a synchronizing point in each of the plurality of distinct feeds at which each may be synchronized relative to the reference clock.
• the method further includes combining the plurality of distinct feeds to form a single stream comprising a plurality of synchronized distinct feeds based on the determined synchronizing point.
• the method further includes encoding the single stream to form a composite mobile device compatible stream.
• the step of combining includes at least one of interleaving, multiplexing, and concatenating.
• the step of combining includes comprises delaying at least one of the plurality of distinct feeds so that the delayed at least one of the plurality of distinct feeds may be time synchronized with at least one other of the plurality of distinct feeds.
• the step of combining the plurality of distinct feeds includes sub-sampling at least one of the distinct feeds so that the composite mobile device compatible stream takes no more bandwidth than one of the distinct feeds.
• the stream may be one of a device specific stream, an audio/video player-specific stream, and a DASH-based stream.
• the at least one of the distinct feeds comprises a live event feed.
• the time stamp information for the live event feed may be the reference clock.
• the plurality of distinct feeds may be synchronized to the reference clock.
• the single stream may include a plurality of synchronized distinct feeds may be an internet protocol stream that comprises metadata for each of the distinct feeds.
• the metadata facilitates converting the single stream into the distinct feeds for presentation on a mobile device screen.
• the metadata facilitates identifying each of the distinct feeds to a user interface application of a mobile device on which the distinct feeds are being presented.
• the single stream may include a plurality of synchronized distinct feeds including a mosaic of the plurality of the distinct feeds.
• the single stream includes a mosaic further comprises position information within the mosaic of each distinct feed.
• the single stream includes a plurality of distinct feeds further including a plurality of video feeds and a single audio feed associated with one of the plurality of video feeds.
• the methods and systems described herein may include accessing with a server a plurality of distinct feeds comprising at least one of audio and video and further comprising a sequence of frames.
• the method includes accessing time stamp information for at least a portion of the plurality of distinct feeds.
• the method includes comparing each of the time stamp information to a reference clock to determine a relative order of, and a relative time difference among, the portion of the plurality of distinct feeds.
• the method includes determining a synchronizing frame in each of the plurality of distinct feeds at which each may be synchronized relative to the reference clock.
• the method includes combining the frames of the plurality of distinct feeds to form a single stream comprising a plurality of synchronized distinct feeds based on the determined synchronizing frame.
• the method further includes encoding the frames of the single stream to form a composite mobile device compatible stream.
• the step of combining comprises at least one of interleaving, multiplexing, and concatenating.
• the combining includes delaying at least one of the plurality of distinct feeds so that the delayed at least one of the plurality of distinct feeds may be time synchronized with at least one other of the plurality of distinct feeds.
• the step of combining the frames of the plurality of distinct feeds includes sub-sampling each of the distinct feeds so that the composite mobile device compatible stream may take no more bandwidth than one of the distinct feeds.
• the stream may be one of a device specific stream, a player-specific stream, and a DASH- based stream.
• the at least one of the distinct feeds includes a live event feed.
• the time stamp information for the live event feed may be the reference clock.
• the plurality of distinct feeds may be synchronized to the reference clock.
• the single stream may includes a plurality of synchronized distinct feeds may be an internet protocol stream that comprises metadata for each of the distinct feeds.
• the single stream includes a plurality of synchronized distinct feeds including a mosaic of the plurality of the distinct feeds.
• the single stream includes a mosaic further including position information within the mosaic of each distinct feed.
• the single stream may include a plurality of distinct feeds further including a plurality of video feeds and a single audio feed associated with one of the plurality of video feeds.
• the methods and systems described herein may include receiving in a mobile device a single video stream comprising a plurality of time synchronized distinct video feeds.
• the method includes accessing, in a memory of the mobile device, a distinct video feed selection criteria that may indicate one or more of the plurality of time synchronized distinct video feeds for presenting to the user.
• the method includes selecting a portion of the plurality of time synchronized distinct video feeds received in the single video stream based on the accessed distinct video feed selection criteria.
• the method includes presenting the selected portion to a user of the mobile.
• the distinct video feed criteria may be one of location of the mobile device, content subscription associated with the mobile device, identification of a network carrier providing service to the mobile phone, and user selection of one of the distinct video feeds.
• the method further includes presenting the selected portion comprises arranging the selected portion into a unified mosaic display.
• the unified mosaic display includes alternate content for any distinct video feed not included in the selected portion.
• the methods and systems described herein may include receiving a plurality of distinct video feeds and video feed time information that facilitates determining a relative order of the distinct video feeds.
• the method includes accessing a distinct video feed selection criteria that indicates one or more of the plurality of time synchronized distinct video feeds.
• the method includes selecting a portion of the plurality of distinct video feeds based on the accessed distinct video feed selection criteria.
• the method includes combining the selected portion of the plurality of distinct video feeds in the relative order.
• the method includes generating a mobile device compatible stream from the ordered, combined plurality of distinct video feeds by processing the ordered, combined plurality of distinct video feeds with an mobile device compatible encoder.
• the distinct video feed criteria may be one of location for viewing a distinct video feed, content subscription, identification of a network carrier providing service over which the mobile device compatible stream may have to be transmitted, and user selection of one of the distinct video feeds.
• the step of combining may include at least one of interleaving, multiplexing, and concatenating.
• the step of may include delaying at least one of the plurality of distinct video feeds so that the delayed at least one of the plurality of distinct video feeds may be time synchronized with at least one other of the plurality of distinct video feeds.
• the step of combining the plurality of distinct video feeds includes sub-sampling each of the distinct video feeds so that the composite mobile device compatible stream takes no more bandwidth than one of the distinct video feeds.
• the stream may be one of a device specific stream, a video player-specific stream, and a DASH-based stream.
• the at least one of the distinct video feeds may include a live event feed.
• the single video stream may include a plurality of synchronized distinct video feeds may be an internet protocol stream that may include metadata for each of the distinct video feeds.
• the single video stream may include a plurality of synchronized distinct video feeds including a mosaic of the plurality of the distinct video feeds.
• the single video stream includes a mosaic further including position information within the mosaic of each distinct video feed.
• the single video stream may include a plurality of synchronized distinct video feeds further including a single audio feed associated with one of the plurality of synchronized distinct video feeds.
• the methods and systems described herein may include receiving a selection of a live video feed comprising a plurality of video frames, wherein the live video feed includes time information associated with each frame.
• the method includes accessing the time information associated with a current frame of the selected live video feed.
• the method further includes querying a server that generates a feed of event real-time properties data frames to determine an event real-time properties data frame that may correspond to the time information associated with the current frame of the selected live video feed.
• the method includes retrieving the determined event real-time properties data frame.
• the method includes presenting the determined event real-time properties data frame with the current frame of selected live video feed on an audio/video user interface of a mobile device.
• the step of presenting the determined event real-time properties data frame includes displaying a leaderboard display comprising the event real-time properties data in a predefined format.
• the method further includes presenting subsequent frames of the selected live video feed and the event real-time properties data until at least one of a new live video feed may be selected or an error conditions occurs.
• the methods and systems described herein may include receiving a user selection through a user interface of a mobile device of a live video feed.
• the method further includes receiving the live video feed over a mobile device radio network in response to the user selection.
• the method further includes retrieving with the mobile device a latest leaderboard frame that may be periodically generated with a server based on event real-time properties data received by the server.
• the method further includes presenting the live video feed as it may be received along with each latest leaderboard frame as it may be retrieved, wherein the presented latest leaderboard frame lags the presented live video feed by less than three seconds.
• Fig. 1 depicts a user interface for displaying multiple distinct video feeds on a mobile device that were streamed to the device in a single stream.
• Fig. 2 depicts an embodiment of time synchronizing multiple distinct video fees into a single mobile device compatible stream.
• Fig. 3 depicts an alternate embodiment of time synchronizing multiple distinct video fees into a single mobile device compatible stream.
• Fig. 4 depicts an embodiment of time synchronizing video and event realtime properties frames.
• FIGs. 5A and 5B depict a live race event application of streaming a plurality of video feeds in a single stream over a mobile device network.
• Fig. 6 depicts a block diagram of select components of a system that implements the methods of multi-feed mobile-network single streaming described herein.
• Fig. 7 depicts a diagram of an exemplary embodiment of receiving and providing distinct feeds as individual streams and as a single stream over a mobile device network.
• a server ingests all relevant feeds and creates mobile-device compatible stream (e.g. a time synchronized stream) of a select subset of the ingested feeds for delivery over the mobile IP network.
• a device receives the single stream and a single player decodes and presents the stream as a single video and audio presentation. This reduces network bandwidth demand by a factor roughly equivalent to the number of feeds that are combined into one stream and reduces device processing load by a similar amount (decoding one stream instead of decoding and arranging all of the separate streams in one display).
• unlocking enhanced functionality may result in significant improvements in user interfaces, such as: replacing a conventional simple scrolling text program guide with a dynamic scrolling guide that depicts video of the programs; view all news services on one screen rather than having to switch among news feeds; view a range of sports or all games for one sport on a single screen; display a user's favorite programs on one screen, and the like.
• improvements in mobile device user interface capabilities are merely exemplary improvements in mobile device user interface capabilities. It will be apparent that other improvements are also enabled through single streaming of a plurality of feeds as described herein.
• Benefits of the methods and systems described herein may extend well beyond the reduction in bandwidth demand and processing overhead to accomplish displaying multiple feeds in a single region of a display.
• a plurality of feeds are streamed to a device as a single stream, each feed is presented in a portion of a display so that user actions (e.g. through a touchscreen, mouse and the like) within a feed-specific portions of the display screen may result in the user interacting with the specific feed as if the feed were being streamed directly to the device.
• a user action taken on any section of the multi-feed portion of the device display may result in a new view related to the section. Examples described herein include audio control, video control, and the like.
• FIG. 1 An exemplary user interface screen is depicted in in Fig. 1, which is described here.
• the user interface for this advanced functionality is surprisingly simple.
• the screen can be filled with multiple feeds.
• Figure 1 shows an exemplary five-feed screen display 102.
• the multi-feed single stream user interface facilitates interactivity and cross combinations of audio associated with the feeds.
• the user can enable that feed to take over the screen portion of the other feeds to form a single feed video 108.
• the user can return to the multi-feed view to select another feed or the user can toggle through the feeds in single feed mode.
• Examples include streaming live broadcast coverage of an event such as auto racing with multiple views: facing the driver, driver's view, aerial view, realtime statistics, and the like.
• Another example includes fantasy football in which a fantasy football player's team may be presented in some of the feeds and video of the games in which the team members are playing may be presented in other of the feeds. The user may be able to select among audio of the game feeds.
• Multi-feed streaming may be associated with digital rights management of the streamed content.
• Each feed may be separately managed for digital rights so that only users with specific rights (e.g. a service plan that provides for a real-time statistics view) may view a rights-protected feed.
• Such protection can be accomplished in the mobile device player so that any unauthorized feed can be discarded or replaced with other content during playback.
• DRM protection can be accomplished in a unicast environment by sending fewer feeds or by sending alternate content (e.g. an ad for the unauthorized feed/channel with plan pricing) when the target user is not authorized for the feed.
• Other methods of providing DRM protection and authentication per feed are possible including, geo- location based authentication, network-based authentication, and the like.
• certain feeds may be available to a mobile user who is located within a predefined radius of the playing field.
• mobile users within the predefined radius may be prohibited from viewing certain replays similar to what replays are shown on the venue projection screens.
• Network providers may participate in authentication and permissions to receive a particular feed in a multi-feed stream.
• a carrier may provide high definition content but may limit access to this content to 4G users. Therefore, if a user is not a 4G user, his device may not be authorized to receive this content as one of the multi-feeds.
• the feed may be disabled by the device playback software or it may be replaced when the stream is prepared with content that the non-4G user is authorized to receive.
• Synchronizing the distinct feeds and/or content from other sources that may be combined in the single stream or as metadata delivered with the stream may enable coherent display of the images and related information (e.g. real-time statistics, etc.).
• Synchronizing feeds may be done through a variety of techniques including capturing time information from the individual feeds and adjusting the relative timing of the feeds relative to the stream being delivered to the mobile device as depicted in Fig. 2.
• time references e.g. RF satellite timing
• feed metadata may be used along with feed metadata to determine an appropriate time shift for each feed to properly synchronize the feeds into a single data stream to a mobile device as depicted in Fig. 3.
• Synchronization in real-time may require satellite based references because reference timing from the video production trucks generally are not based on highly accurate clocks.
• One consideration is that latency is introduced in the feeds when the feeds are transmitted from the truck/base station to a satellite and then back to a receiving station for delivery to a mobile media platform that provides the multi- feed single-streaming described herein. Therefore other time sources may need to be employed for accurate locking of synchronized streams, such as GPS time, Network Time Protocol time, Internet time, venue local time, time replicated from other content from the same venue or location, time taken from another video stream, and the like.
• One technique of using a reference clock may be to determine the clock that the feed itself is set to; make sure that the network time is in synch with the video time- video; and then insert the time synchronization data in a way that may be similar to inserting close captioning information.
• the video sources are preferably synchronized in time before encoding of the mosaic is performed. This may be important to ensure that common events occurring in both video feeds appear to occur at the same time to the viewer. Therefore, time stamping video as it is captured at the event or at least when it is transmitted from the event to a video server may be required. This source- based time stamping also eliminates any need to compensate for latency of one camera feed relative to the other because both feeds can be locked so that they are fed into encoding synchronized.
• the principles of source-based time synching of video feeds are now described in greater detail.
• the encoder may stamp every video frame with a date/time stamp.
• Local venue time e.g. GPS time
• This date/time stamp may be received by an appropriate application running on a mobile device or the like in the header portion of the stream.
• the header is not viewable by the user, but is discoverable by the application.
• a listener process may be continuously scanning the header of the video stream being received to find the date/time stamp.
• the corresponding time stamp will be captured.
• the application queries a separate event real-time properties (ERP) feed as described herein to find a corresponding date/time frame that is close in time to the captured time stamp.
• ERP event real-time properties
• the selected video plays normally. Once a date/time frame that corresponds to the video time stamp is received, a leaderboard with the pertinent ERP update is displayed to the user as a fully synced viewing experience of the ERP data showing in the leaderboard and the video stream that is playing. Once the two feeds are synchronized, there may be no additional latency between the video and the ERP data to deal with. Once the user selects a new video, this process repeats. Note that generally, it will take approximately one second for the synced event real-time properties data to load into the application.
• This date/time ERP and video frame synching may be active whenever video (e.g. live video from an event such as a sports event) is being presented in the video feed. However, when there is no live video in the feed or the user has selected a feed that does not include video or has selected no feed, the application may default to use the most current (low latency / latest frame) event real-time properties data. This is described further with respect to Fig. 4. A similar action may be taken by the application when the user pauses the video, exits the video, starts a new video or if the video fails for some reason. Therefore, when a selected video is playing, the video time stamp is the master clock to which the other date/time frame data is synchronized.
• video e.g. live video from an event such as a sports event
• the application defaults to using the most current event real-time properties data available (e.g. sub-5 second low latency feed). If the user stops/pauses the video, the application will switch to display the most current event real-time properties data to the user.
• the most current event real-time properties data available e.g. sub-5 second low latency feed.
• the application performs the time sync operation described above so that the user is shown delayed event real-time properties data that is time synchronized with the video playing.
• a message may be sent to the user when this condition exists (e.g. resumed playback).
• a composite single multi-video feed may also have a time stamp to facilitate syncing the event real-time properties data.
• the videos within single multi-video feed are first synced to each other and then encoded and wrapped with a video timing header based on the date/time stamp of a reference or master clock, such as one generated by or received from the production truck.
• This date/time stamp is then passed in the composite video feed header to a client application as noted above and used to synch the event real-time properties data similarly to that described above.
• a master clock for time stamping video feeds and for synchronizing video and ERP data may be derived from a clock source at a local venue.
• Sources of master clock include GPS referenced time, network time protocol time (NTP), and the like.
• NTP network time protocol time
• video feeds and ERP data generated from a single event are time stamped based on the same master clock.
• video feeds and ERP data may be sourced from two different processing sub systems at an event (e.g. a production truck and a ERP server), clocks in these two sub systems are themselves synchronized so that each frame from each source can be matched in time.
• a master clock for ERP frame data synchronization may be the clock time stamp in the video feed header.
• a video feed may stop unexpectedly.
• the ERP data source will be changed to the most current (low latency) frame data.
• a video feed header may not include a time stamp.
• the ERP data source becomes the most current (low latency) frame data.
• the video and the ERP leaderboard data may not be synchronized and there may be no way to determine the latency between the video feed and the ERP data feed.
• an ERP data feed may go down or not be detectable. For this condition, the most recently received ERP data frame is continuously displayed until the ERP feed is restored.
• a single stream may include feeds and/or content that does not necessarily need to be synchronized.
• a video program guide may receive feeds from a plurality of channels and may present a portion of these feeds in a display of a mobile device as a video program guide. Other than combining each feed as it is ingested into a single stream, synchronization among the feeds may not be required.
• An alternate video program guide embodiment may include presenting a program guide along with a larger display of a currently selected feed/program. In such an embodiment, the individual video feeds in the program guide may not be synchronized to each other but the currently selected feed/program in the larger display may be synchronized to its smaller version in the video program guide.
• a live event such as an auto race may include feeds from several vantage points in the race arena (e.g. views from several cars).
• a single stream of such an event may include these live feeds as well as content related to leader board details, information about a driver who's view is being presented in one of the other feeds, and the like.
• the driver views may be synchronized so as to ensure that these display are coherent in time.
• the non-real-time content of a leader board or of driver details may not be synchronized to ensure fine grain coherency.
• a user may be presented with three driver views and a fourth view of driver details. When a user selects a driver view, the details of the driver may be presented in the fourth view.
• time stamps are being inserted in both the video feed and the event data feeds so these time stamps can be used to synchronize presentation if that is the preferred user experience. Further details regarding low latency viewing are presented below. Although the following embodiments reference a live track event, the methods and systems related to low latency viewing can be applied to any live event.
• a first embodiment of low latency viewing may include a sequence of events as follows. Note for this embodiment the client app may proactively ask the server to identify the latest frame of leaderboard information.
• event real-time property messages may be continuously posted to a video-processing server.
• These messages may be processed by accumulating and modifying a full model of a leaderboard for the event by the server. On a one-second interval, the state of this model may be written out to a "frame" and that "frame” may be time-stamped and stored for later retrieval. Thus a "frame” may represent the state of the leaderboard data at a given point in time. The frame may be created as a file and made available to all client applications to "pull" data from it.
• the client application When the client application starts up its leaderboard view, it may query the server to determine the latest frame of leaderboard data identifier. The client application may then use this identifier to retrieve the latest frame, and display it as its leaderboard. The client application may refresh its data on a one-second rate as well.
• latency includes delays of as much as five seconds associated with network time, processing time and content delivery network interfacing.
• a live event data feed is delivered from the event to a server in less than one second. Therefore, latency may range up to approximately six seconds, but is preferably in the range of two-three seconds.
• FIG. 4 depicts the low latency embodiment described above, latencies associated with each aspect of feed generation, ingestion, processing, and delivery are depicted.
• a sporting event 402 such as an auto race is captured for broadcast and live timing and scoring data 404 is provided to an event real-time properties (ERP) generator 408 that streams ERP data 410 to a media processor 412.
• ERP event real-time properties
• the media processor 412 generates a series of frames and designates the most recently generated as the "latest" frame 414.
• a mobile device 418 requests this latest frame 414 from the media processor 412, which responds with information that the mobile device 418 can use to retrieve the latest from 414 from the content delivery network (CDN) 420.
• the mobile device 418 retrieves this latest frame 414 from the CDN 420 and updates it's display of a leader board 422.
• the displayed latest time e.g. 12:30:45
• the media processor 412 is updating its frame data by generating a next frame 424.
• frames are generated on one-second intervals, although other intervals are contemplated and included herein.
• CDN 420 Depicted along with the CDN 420 is a timeline showing the relative positioning of each latest and next frame with respect to the current time to facilitate depicting a potential latency of two-three seconds from event capture to device updating.
• a second embodiment of low latency may be no different from the user experience point of view; however a different implementation can lower the latency even further. From a design perspective this feature pushes data at a regular interval.
• a sequence of events for this embodiment is as follows:
• event real-time properties messages are received by the media processor 412. This data is processed by accumulating and modifying a full model of the leaderboard. On a configured interval (e.g. multiple times per second), the state of this model is written out to a frame (e.g. as a latest frame 414) in the CDN 420. This frame is time-stamped and stored for later retrieval (e.g. for time synchronization purposes, or any possible future race replay features). This frame is also pushed out to all listening client devices 418. [0072] When the client application on the mobile device 418 starts up its leaderboard 422 view it may continuously listen for leaderboard frames that are pushed to it. When the client application receives a frame it directly displays that frame as its leaderboard.
• telemetry data points may be built into the leaderboard data frames along with all of the other leaderboard data points.
• the refresh rate for telemetry fields may be 1 second, or the same as a frame generation interval.
• the latency of the telemetry fields could be up to approximately six seconds (taking into account video provider latency as well).
• the latency of the telemetry fields could be up to approximately two seconds (again, taking into account video provider latency).
• feeds in a first stream are synchronized with feed(s) in a second stream so that screens on multiple devices may be synchronized.
• One such embodiment may include a live auto race event being broadcast on a first stream and presented on a large screen that many viewers can view. Individual mobile devices that are in proximity to this screen may receive a multi-feed stream that includes the large screen feed. The feed that is streamed to the large screen and to the mobile devices may be synchronized by the methods and systems described herein. In this way mobile device users that are in proximity to the large screen do not experience any delay in the presentation of the common feed.
• Processing multiple feeds to generate a single stream thereof may include accessing and/or processing metadata and/or source information (e.g. URL) about the feeds.
• This information may be useful in controlling display of the feeds, such as when switching between multiple feeds being presented on the device display (e.g. in a Mosaic) to just a single feed being presented or some other combination of feeds being presented (e.g. changing from two to three feeds).
• Other uses of metadata may relate to positioning of the feeds in the mosaic, and the like.
• Source data, particularly URL data may be presented or selectable by a user to enable access to the URL content separately from the mosaic interface functionality.
• Multi-feed single-stream video and audio may be compatible with existing IP protocols such as HLS, and future standards such as DASH, and the like.
• DASH and the like may facilitate enhanced live video adaptive streaming such as providing streams in chunks of time (e.g. 10 seconds). These chunks may be further processed by the methods and systems herein, including enhancements to mobile device stream players to split these chunks into the individual feeds and some contextual information that the player recognizes.
• the mobile device player may be configured to detect contextual information at the three-second point in each chunk.
• information such as an advertisement, leader board information, and other content may be included in the stream at this three-second time and the mobile device player may extract this information and present it appropriately to the user (e.g. an updated leader board display, and the like.
• Synchronization considerations may include startup related effects when a user opens up a screen and starts selecting feeds. Due to network latency, there may be noticeable delays between when a user selects a feed and it is presented to the user.
• delays may extend further when the feed(s) need to be synchronized. This may be further complicated by the inclusion of alternately sourced content (e.g. a leader board from a website or other such content) that may be separately updated.
• alternately sourced content e.g. a leader board from a website or other such content
• Metadata being provided with the stream may be perceived by the user to be "out of sync" with the feeds.
• metadata being provided with the stream e.g. to update a leader board
• One option is to delay streaming of data until all of the required data is ready to be streamed. Using the longest detected latency of the feeds may do this.
• the mobile device player may participate in this non-real-time synchronization and may receive metadata that may facilitate the device player providing the proper coordination of live feeds and non-live content updates.
• video and other content may be delivered as one or more sets of files that the mobile device player could process and present in a coherent manner.
• Video feeds may be provided via a satellite and distributed through an L-band RF distribution facility (IRD 1 through 4). Other feeds may be provided from the Internet (STRM DECODER 3 through 5). A fifth IRD feed may be an emergency backup feed (IRD 5). All of these feeds may be presented to a Video Router. A portion of these feeds may be streamed as a single stream to a user's device to be presented in a coherent display as described herein.
• the video router may be configured to provide exemplary video routes including:
• FIG. 6 high-level features of a system for providing multiple feeds on a single mobile IP network stream are depicted.
• the system of Fig. 6 may receive 602 a plurality of feeds from sources including: satellite, fiber, IP, file, tape, and the like. These feeds may be ingested and delivered to a feed combining engine
• the feed combining engine 604 may provide a single stream of the combined feeds that may be provided to an encoder 610 for delivery to a device over a mobile IP network.
• a plurality of feeds 702 may be received and processed by an ingestion engine 704.
• the ingestion engine 704 may also combine the feeds 702 into a single stream 708 that may be presented to the user as a mosaic 710.
• the ingestion engine 704 may provide this combined stream 708 and individual streams 712 of each of the feeds to encoders 714 for delivery to mobile device(s) over a mobile IP network.
• Combining the streams may be accomplished by, for example, creating a single stream that consists of packets from a plurality of other streams, such as by interleaving, multiplexing, or concatenating such packets and retaining information for managing or tracking the combined streams, by multiplexing or otherwise combining signals from different streams, or other techniques for combining data streams.
• One method of combining includes scaling each feed to a smaller representative image that can be displayed in a mosaic as depicted in at least Fig. 1 herein before combining the scaled feeds into a single video while retaining individual identifiers of each feed and its location in the mosaic by way of meta-data that is used by the device to manage a particular feed (e.g. allowing a user to select a feed).
• Another exemplary method of combining includes multiplexing multiple feds into one video to produce a new video source that can be sent to an encoder to create a single channel (stream) with multiple pieces of content.
• each individual feed may be delivered to an encoder so that when a user selects one of the feeds from the single stream, a larger (e.g. full screen) video of the selected feed can be streamed to the user's device without undue delay.
• references herein include scaling and/or combining feeds prior to encoding
• an encoding engine may be adapted to receive multiple source feeds, scale each as needed for the desired mosaic display, and create a single encoded stream to be delivered to a mobile device.
• combining could be performed post encoding by each feed being sent to an encoder where the feed would be scaled to accommodate a mosaic display and a content delivery engine would combine the scaled encoded outputs into a single stream for delivery to a user device.
• a video player / application on the device could receive the stream and generate the mosaic from the distinct feeds in the stream.
• the methods and systems described herein may be deployed in part or in whole through a machine that executes computer software, program codes, and/or instructions on a processor.
• the processor may be part of a server, cloud server, client, network infrastructure, mobile computing platform, stationary computing platform, or other computing platform.
• a processor may be any kind of computational or processing device capable of executing program instructions, codes, binary instructions and the like.
• the processor may be or include a signal processor, digital processor, embedded processor, microprocessor or any variant such as a coprocessor (math co-processor, graphic co-processor, communication co-processor and the like) and the like that may directly or indirectly facilitate execution of program code or program instructions stored thereon.
• the processor may enable execution of multiple programs, threads, and codes.
• the threads may be executed simultaneously to enhance the performance of the processor and to facilitate simultaneous operations of the application.
• methods, program codes, program instructions and the like described herein may be implemented in one or more thread.
• the thread may spawn other threads that may have assigned priorities associated with them; the processor may execute these threads based on priority or any other order based on instructions provided in the program code.
• the processor may include memory that stores methods, codes, instructions and programs as described herein and elsewhere.
• the processor may access a storage medium through an interface that may store methods, codes, and instructions as described herein and elsewhere.
• the storage medium associated with the processor for storing methods, programs, codes, program instructions or other type of instructions capable of being executed by the computing or processing device may include but may not be limited to one or more of a CD-ROM, DVD, memory, hard disk, flash drive, RAM, ROM, cache and the like.
• a processor may include one or more cores that may enhance speed and performance of a multiprocessor.
• the process may be a dual core processor, quad core processors, other chip-level multiprocessor and the like that combine two or more independent cores (called a die).
• the methods and systems described herein may be deployed in part or in whole through a machine that executes computer software on a server, client, firewall, gateway, hub, router, or other such computer and/or networking hardware.
• the software program may be associated with a server that may include a file server, print server, domain server, internet server, intranet server, cloud server, and other variants such as secondary server, host server, distributed server and the like.
• the server may include one or more of memories, processors, computer readable media, storage media, ports (physical and virtual), communication devices, and interfaces capable of accessing other servers, clients, machines, and devices through a wired or a wireless medium, and the like.
• the methods, programs or codes as described herein and elsewhere may be executed by the server.
• other devices required for execution of methods as described in this application may be considered as a part of the infrastructure associated with the server.
• the server may provide an interface to other devices including, without limitation, clients, other servers, printers, database servers, print servers, file servers, communication servers, distributed servers, social networks, and the like. Additionally, this coupling and/or connection may facilitate remote execution of program across the network. The networking of some or all of these devices may facilitate parallel processing of a program or method at one or more location without deviating from the scope of the invention.
• any of the devices attached to the server through an interface may include at least one storage medium capable of storing methods, programs, code and/or instructions.
• a central repository may provide program instructions to be executed on different devices.
• the remote repository may act as a storage medium for program code, instructions, and programs.
• the software program may be associated with a client that may include a file client, print client, domain client, internet client, intranet client and other variants such as secondary client, host client, distributed client and the like.
• the client may include one or more of memories, processors, computer readable media, storage media, ports (physical and virtual), communication devices, and interfaces capable of accessing other clients, servers, machines, and devices through a wired or a wireless medium, and the like.
• the methods, programs or codes as described herein and elsewhere may be executed by the client.
• other devices required for execution of methods as described in this application may be considered as a part of the infrastructure associated with the client.
• the client may provide an interface to other devices including, without limitation, servers, other clients, printers, database servers, print servers, file servers, communication servers, distributed servers and the like. Additionally, this coupling and/or connection may facilitate remote execution of program across the network. The networking of some or all of these devices may facilitate parallel processing of a program or method at one or more location without deviating from the scope of the invention.
• any of the devices attached to the client through an interface may include at least one storage medium capable of storing methods, programs, applications, code and/or instructions.
• a central repository may provide program instructions to be executed on different devices.
• the remote repository may act as a storage medium for program code, instructions, and programs.
• the methods and systems described herein may be deployed in part or in whole through network infrastructures.
• the network infrastructure may include elements such as computing devices, servers, routers, hubs, firewalls, clients, personal computers, communication devices, routing devices and other active and passive devices, modules and/or components as known in the art.
• the computing and/or non- computing device(s) associated with the network infrastructure may include, apart from other components, a storage medium such as flash memory, buffer, stack, RAM, ROM and the like.
• the processes, methods, program codes, instructions described herein and elsewhere may be executed by one or more of the network infrastructural elements.
• the methods, program codes, and instructions described herein and elsewhere may be implemented on a cellular network having multiple cells.
• the cellular network may either be frequency division multiple access (FDMA) network or code division multiple access (CDMA) network.
• FDMA frequency division multiple access
• CDMA code division multiple access
• the cellular network may include mobile devices, cell sites, base stations, repeaters, antennas, towers, and the like.
• the cell network may be a GSM, GPRS, 3G, EVDO, mesh, or other networks types.
• the methods, programs codes, and instructions described herein and elsewhere may be implemented on or through mobile devices.
• the mobile devices may include navigation devices, cell phones, mobile phones, mobile personal digital assistants, laptops, palmtops, netbooks, pagers, electronic books readers, music players and the like. These devices may include, apart from other components, a storage medium such as a flash memory, buffer, RAM, ROM and one or more computing devices.
• the computing devices associated with mobile devices may be enabled to execute program codes, methods, and instructions stored thereon.
• the mobile devices may be configured to execute instructions in collaboration with other devices.
• the mobile devices may communicate with base stations interfaced with servers and configured to execute program codes.
• the mobile devices may communicate on a peer to peer network, mesh network, or other communications network.
• the program code may be stored on the storage medium associated with the server and executed by a computing device embedded within the server.
• the base station may include a computing device and a storage medium.
• the storage device may store program codes and instructions executed by the computing devices associated with the base station.
• the computer software, program codes, and/or instructions may be stored and/or accessed on machine readable media that may include: computer components, devices, and recording media that retain digital data used for computing for some interval of time; semiconductor storage known as random access memory (RAM); mass storage typically for more permanent storage, such as optical discs, forms of magnetic storage like hard disks, tapes, drums, cards and other types; processor registers, cache memory, volatile memory, non-volatile memory; optical storage such as CD, DVD; removable media such as flash memory (e.g.
• RAM random access memory
• mass storage typically for more permanent storage, such as optical discs, forms of magnetic storage like hard disks, tapes, drums, cards and other types
• processor registers cache memory, volatile memory, non-volatile memory
• optical storage such as CD, DVD
• removable media such as flash memory (e.g.
• USB sticks or keys floppy disks, magnetic tape, paper tape, punch cards, standalone RAM disks, Zip drives, removable mass storage, off-line, and the like; other computer memory such as dynamic memory, static memory, read/write storage, mutable storage, read only, random access, sequential access, location addressable, file addressable, content addressable, network attached storage, storage area network, bar codes, magnetic ink, and the like.
• the methods and systems described herein may transform physical and/or or intangible items from one state to another.
• the methods and systems described herein may also transform data representing physical and/or intangible items from one state to another.
• machines may include, but may not be limited to, personal digital assistants, laptops, personal computers, mobile phones, other handheld computing devices, medical equipment, wired or wireless communication devices, transducers, chips, calculators, satellites, tablet PCs, electronic books, gadgets, electronic devices, devices having artificial intelligence, computing devices, networking equipments, servers, routers and the like.
• the elements depicted in the flow chart and block diagrams or any other logical component may be implemented on a machine capable of executing program instructions.
• the methods and/or processes described above, and steps thereof, may be realized in hardware, software or any combination of hardware and software suitable for a particular application.
• the hardware may include a general purpose computer and/or dedicated computing device or specific computing device or particular aspect or component of a specific computing device.
• the processes may be realized in one or more microprocessors, microcontrollers, embedded microcontrollers, programmable digital signal processors or other programmable device, along with internal and/or external memory.
• the processes may also, or instead, be embodied in an application specific integrated circuit, a programmable gate array, programmable array logic, or any other device or combination of devices that may be configured to process electronic signals. It will further be appreciated that one or more of the processes may be realized as a computer executable code capable of being executed on a machine readable medium.
• the computer executable code may be created using a structured programming language such as C, an object oriented programming language such as C++, or any other high-level or low-level programming language (including assembly languages, hardware description languages, and database programming languages and technologies) that may be stored, compiled or interpreted to run on one of the above devices, as well as heterogeneous combinations of processors, processor architectures, or combinations of different hardware and software, or any other machine capable of executing program instructions.
• a structured programming language such as C
• an object oriented programming language such as C++
• any other high-level or low-level programming language including assembly languages, hardware description languages, and database programming languages and technologies
• each method described above and combinations thereof may be embodied in computer executable code that, when executing on one or more computing devices, performs the steps thereof.
• the methods may be embodied in systems that perform the steps thereof, and may be distributed across devices in a number of ways, or all of the functionality may be integrated into a dedicated, standalone device or other hardware.
• the means for performing the steps associated with the processes described above may include any of the hardware and/or software described above. All such permutations and combinations are intended to fall within the scope of the present disclosure.

Landscapes

• Engineering & Computer Science (AREA)
• Multimedia (AREA)
• Signal Processing (AREA)
• Computer Networks & Wireless Communication (AREA)
• Business, Economics & Management (AREA)
• General Business, Economics & Management (AREA)
• Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
• Controls And Circuits For Display Device (AREA)

Applications Claiming Priority (4)

Publications (2)

Family

ID=49757377

Family Applications (1)

Country Status (5)

Families Citing this family (9)

Family Cites Families (11)

• 2013
  • 2013-06-14 IN IN158DEN2015 patent/IN2015DN00158A/en unknown
  • 2013-06-14 EP EP13804225.4A patent/EP2862359A4/de not_active Withdrawn
  • 2013-06-14 CA CA2876752A patent/CA2876752A1/en not_active Abandoned
  • 2013-06-14 WO PCT/CA2013/050456 patent/WO2013185238A1/en active Application Filing
  • 2013-06-14 SG SG11201408273TA patent/SG11201408273TA/en unknown

Also Published As

Similar Documents

Legal Events