Patent Application
20100036854
Certain segments of television programmes are often the centre of discussions between friends and acquaintances despite the fact that it is not easy to watch these segments from television programmes again when these discussions take place. Broadcasters may make a limited selection of clips available for viewing from their websites. These clips may be segments from programmes already broadcast or alternatively they may be trailers for future programmes. However, it is only possible to view these clips if the user has access to an internet enabled PC at that moment in time.
The following presents a simplified summary of the disclosure in order to provide a basic understanding to the reader. This summary is not an extensive overview of the disclosure and it does not identify key/critical elements of the invention or delineate the scope of the invention. Its sole purpose is to present some concepts disclosed herein in a simplified form as a prelude to the more detailed description that is presented later.
Methods, software and apparatus are described which enable users to share and exchange clips from broadcast media using their mobile devices. Whilst watching broadcast media, a user can cause their mobile device to capture a clip, for example by pressing a button. The capture of the clip enables the user to show and share the clip with friends as part of a system of exchange.
The present example provides a method of capturing media clips on a mobile device comprising: in response to a user input received by the mobile device, identifying a media clip for capture; accessing clip data for the identified media clip; and storing the clip data on the mobile device.
The method may further comprise: providing an interface for navigation to and selection of a clip stored on the mobile device.
Identifying a media clip for capture may comprise: determining a time of the user input; and identifying the media clip based on the time of the user input.
Identifying a media clip for capture may further comprise: determining a broadcast channel being watched by the user, wherein the media clip is identified based on the time of the user input and the broadcast channel.
The clip data may comprise a media file for the identified media clip and wherein accessing clip data for the identified media clip may comprise: accessing the media file for the identified media clip.
Accessing the media file for the identified media clip may comprise: receiving the media file over a broadcast channel.
Accessing the media file for the identified media clip may comprise: downloading the media file from a server.
The method may further comprise: in response to a user input received by the mobile device selecting the identified clip, playing the media file.
The clip data may further comprise a representative still image for the clip.
The method may further comprise: in response to a user input received by the mobile device selecting a stored clip, transmitting the stored clip to another mobile device over a wireless link.
The method may further comprise: accessing a licence for the identified clip.
A second aspect provides a computer program comprising computer program code means adapted to perform some or all the steps of any of the methods described herein when said program is run on a computer.
The computer program may be embodied on a computer readable medium.
A third aspect provides a mobile device comprising: a processor; a wireless transmitter and receiver; a user input means; a display; and a memory arranged to store executable instructions arranged to cause the processor to: identify a media clip for capture in response to receipt of an input via the user input means; access clip data for the identified media clip; and store the clip data in the memory.
The memory may be further arranged to store executable instructions arranged to cause the processor to: access a licence for the identified media clip.
The memory may be further arranged to store executable instructions arranged to cause the processor to: provide an interface for navigation to and selection of a clip stored on the mobile device.
The memory may be further arranged to store executable instructions arranged to cause the processor to: transmit a stored clip to a second mobile device via the wireless transmitter in response to a user input received via the user input means, the input identifying the stored clip.
A fourth aspect provides a method of enabling capture of media clips on a mobile device comprising: generating a plurality of clips from broadcast media; and distributing the plurality of clips to mobile devices.
Distributing the plurality of clips to mobile devices may comprise: storing the plurality of clips on a server; and in response to a request from a mobile device, downloading one of the plurality of clips from the server to the mobile device.
Distributing the plurality of clips to mobile devices may comprise: selecting at least two of the plurality of clips; dividing each of the selected clips into a plurality of blocks; and sequentially broadcasting one of the plurality of blocks from each of the selected clips.
Further aspects provide one or more device-readable media with device-executable instructions for performing methods described herein, a system for distribution of clips and methods for generating clips.
The methods described herein may be performed by software in machine readable form on a storage medium. The software can be suitable for execution on a parallel processor or a serial processor such that the method steps may be carried out in any suitable order, or simultaneously.
This acknowledges that software can be a valuable, separately tradable commodity. It is intended to encompass software, which runs on or controls “dumb” or standard hardware, to carry out the desired functions. It is also intended to encompass software which “describes” or defines the configuration of hardware, such as HDL (hardware description language) software, as is used for designing silicon chips, or for configuring universal programmable chips, to carry out desired functions.
Many of the attendant features will be more readily appreciated as the same becomes better understood by reference to the following detailed description considered in connection with the accompanying drawings.
The present description will be better understood from the following detailed description read in light of the accompanying drawings, wherein:
Like reference numerals are used to designate like parts in the accompanying drawings.
The detailed description provided below in connection with the appended drawings is intended as a description of the present examples and is not intended to represent the only forms in which the present example may be constructed or utilized. The description sets forth the functions of the example and the sequence of steps for constructing and operating the example. However, the same or equivalent functions and sequences may be accomplished by different examples.
This method provides an easy means by which clips from broadcast material can be shared and exchanged which does not require use of a PC. The clip data may be grabbed substantially in real time (whilst the user is watching the broadcast) and subsequently shared with other people.
In some examples, it may be beneficial to control the access to clips (e.g. the watching of clips). Digital rights management methods which may be implemented with the methods described herein are also described below.
There are a number of different ways in which clips may be generated such that they can be grabbed by a mobile device and shared between people and mobile devices, as shown in
In a first example, the clips may be produced by dividing the broadcast into a number of regular overlapping clips, which may all be the same length or may be of different lengths. In an example the clips may all be two minutes long and may start at one minute intervals. In another example the clips may all be one minute long and start at 30 second intervals. In some examples, the length of the clips that are used may be selected based on the method by which the clips are transmitted to the mobile device, such that a user may receive the clip in a reasonable period of time, whilst not obviating the selection and capture of the desired segment. For example, if a high bandwidth connection is used to transmit clips to a mobile device, longer clips may be acceptable, however if the transmission is via a low bandwidth connection (e.g. GPRS, General Packet Radio Service) it may be necessary to use shorter clips such that they can be received within a reasonable time period and therefore without degrading the overall user experience. Whilst this method may be easily implemented, users' expectations of the duration of a clip may not be met by the process.
In a second example, the clips may be created based on annotations to the content. These annotations may be made by the programme makers or editors of the content. These annotations may comprise metadata associated with the content which contains the start times and durations of any clips which are to be made available for downloading to mobile devices. Whilst this method offers a high fidelity of the artistic intention of the programme makers, it requires considerable investment of time and effort to create the annotations.
In a third example, the clips may be created using machine intelligence techniques by which the broadcast media may be processed and divided into clips intelligently. The intelligence may look at elements of the video (e.g. to detect scene changes), the audio or any metadata which is available (e.g. subtitles) to decide where clips may start and end. This processing of the broadcast media may take place prior to the actual broadcast, in parallel with the broadcast or subsequent to the broadcast of the content. Whilst use of machine intelligence may provide an automatic method of generating clips that coincide with users' expectations of where a scene of interest starts and ends, it may be very processor intensive and therefore the processing may take a long time. Where the processing is done in advance of the broadcast, the time taken to process the content and generate the clips may not impact user experience.
The capture of the clip data by a mobile device may be performed substantially in real time whilst the user is watching the broadcast media. Whilst the user may be watching the broadcast at the time of broadcast, the user may alternatively be watching a time shifted version of the broadcast media (e.g. delayed by a few minutes using a personal video recorder).
The identification of the clip (in step 101a) may be automatic or may require some user input. In order to identify the appropriate clip, the channel being watched by the user is identified. This channel may be determined in any manner including:
Having identified the channel, as described above, the clip to be captured can be identified. This clip may be selected from the generated clips (as described above) based on the identified channel and the time that the user initiated the grabbing of the clip (referred to herein as the ‘grab time’). In a first example, the clip may be selected such that the grab time is close to the mid-point of the clip, e.g. where clips are regularly generated starting every 30 seconds and lasting one minute, a clip may be selected which most closely matches the situation where the start time is 30 seconds before the grab time. In a second example, the clip may be selected such that the start time is a close as possible to the grab time whilst being before the grab time. Although a clip may be selected such that the start time is after the grab time, a clip having a start time before the grab time is more likely to meet the user's expectation as the grab is likely to be initiated in response to seeing an item of interest (e.g. a football goal) rather in advance of the item of interest. In a further example, the clip may be selected to be “the current clip” based on the grab time.
The capturing of the identified clip data (in step 101b) may be done in many different ways and this may be done locally on the mobile device or by the mobile device in communication with a server (or other network element) or the media device. Different methods may be used dependent on whether the clip data comprises the clip itself (e.g. the video data) or an identifier for the clip (such as an address where the clip can be accessed). Where the clip data comprises an identifier, the clip itself may be subsequently downloaded by the mobile device before the clip is shared or exchanged (e.g. prior to the share step 102 or the watch step 103).
In a first example, the clip data may be captured locally on the mobile device by storing an address (e.g. a URL) of the identified clip (e.g. based on the channel and the grab time). For example, the address may be of the form:
www.microsoft.com/tvclips/[channel]/[grab time]
The address may be determined using an Electronic Programme Guide (EPG) running on the mobile device, such as a TV Anytime EPG. The EPG may store addresses for each programme, for each channel or for each clip. The address may be determined by communicating with a remote server (e.g. via the mobile network).
In a second example, the clip data may be downloaded by the mobile device from the media device, as shown in
In a third example, the clip data may be downloaded onto the mobile device over a point to point network, as can be described with reference to
In a fourth example, the clip data may be received by the mobile device from a broadcast transmission, as can be described with reference to
Instead of using the carousel technique described above with reference to
In the above broadcast techniques (described with reference to
Having downloaded the clips using any method described above, the clips may be stored in a clip library within the mobile device.
Having captured and stored the clip data on the mobile device, as described above, the clip may then be watched (step 103) and/or shared (step 102). As described above, the clip data may comprise the clip itself or an identifier for the clip (e.g. an address such as a URL). As described above, where the clip data comprises an identifier rather than the clip itself, the clip itself may be downloaded (e.g. as described above) and stored locally on the mobile device. The locally stored clip may then be shared or exchanged between mobile devices.
In a first example, the clip (e.g. the media file stored locally on the mobile device) may be shared by transferring it to another mobile device via a wireless link such as Bluetooth or IrDA. The transfer may occur as a pushed message, via SMS (Short Message Service) or MMS (Multimedia Message Service) or using any other technique (e.g. email, instant messenger, WAP (Wireless Application Protocol) push etc).
In a second example, the object that is shared by transferring it to another device may be the identifier (such as a URL) for the clip rather than the clip itself. Upon receiving the identifier, the receiving device may automatically access the clip itself, download it and store it locally on the receiving device. Accordingly, the user experience is substantially the same as if the clip itself had been transferred between devices. This method may, for example, be used where it is not possible to use the first example method for any reason (e.g. available bandwidth, device capabilities etc).
In the first example above, the clip captured by the mobile device and the clip transferred to another mobile device (in step 102) are substantially the same. However, in other examples this may not be the case. For example, whilst the mobile device may have downloaded the clip via a point to point link or broadcast transmission (as shown in
In the examples described above, the sharing of the clip does not affect the clip itself, such that the clip watched on the second mobile device is substantially the same as the clip watched on the mobile device which shared the clip with the second mobile device (although some format/coding changes may be required where the devices have different screen sizes etc). However, in some examples, the clip itself may be altered when it is shared (i.e. the clip captured in step 101 is altered on sharing in step 102). Possible changes to the clip include the addition of a logo or other mark to indicate that the clip has been shared (e.g. the logo of the manufacturer of the client application, the logo of the broadcaster etc) and/or a reduction in the length of the clip and/or the quality of the clip such that the number of times a clip can be shared is effectively limited. In another example, the clip may be encrypted (as described below).
It will also be appreciated that the clip captured by the mobile device (in step 101) may itself not be identical to the excerpt from the broadcast programme. For example, a logo or other mark may be added to indicate the source of the clip and/or that the clip has been legitimately obtained.
The clip may be watched (in step 103) on the mobile device which initially captured the clip (e.g. mobile device 301, 401, 601) and it may be watched on any mobile device to which the clip data has been transferred (in the sharing step 102 described above). In order to watch the clip, the clip may be played using a media player application on the mobile device. This media player may be a custom media player which is integrated within an application which also enables browsing of all the clips which have been captured or received (e.g. shared by another mobile device) by the mobile device. The application is described in more detail below.
Where the clip data comprises the address or other identification information for a clip and not the clip itself, the clip must be downloaded prior to being watched. This download process may use any of the methods described above, for example those described with reference to
In addition to comprising either the clip itself or an identifier for the clip, the clip data may also comprise a representative still for the clip. This representative still may be generated at the same time as the clip is generated or may be generated separately (e.g. by the organisation that provides the clips for download/broadcast or by an intermediary). The representative still image may be selected based on position within the clip (e.g. first, last, middle) or may be selected using image selection/comparison techniques. In other examples, the representative image may be selected manually. In a further example, the representative image may not comprise a still image selected from the clip, but may instead comprise data about the clip (e.g. title, date, time, programme name, logo etc).
In other examples, the representative image may not be downloaded along with (or separately to) the clip itself but may instead be generated on the mobile device, for example using any of the methods described above. Once generated on a first mobile device, the representative still image may be transferred as part of (or along with) the clip upon sharing or alternatively the representative still image may be separately generated on the receiving mobile device.
The representative still image may be used in an application which runs on the mobile device and presents a library of clips to the user such that the user can select a clip to share or to watch.
In some applications it may be important to control who has permission to capture, share and/or watch clips of broadcast television. In such an example, it may be necessary for a user to obtain a licence before they are able to watch a captured clip and the media player application may prevent playing of the clip without such a licence (or other form of certificate). In other applications, the use of licences may enable the popularity of clips to be monitored and provide feedback to the system. The system may then respond to this feedback by enabling faster download/reception of the clips by mobile devices or by increasing the period of time over which a clip is available.
Where the clip is downloaded to a mobile device from a media device (as described above with reference to
When a clip is transferred from one mobile device to another mobile device, the licence may be transferred with the clip, or alternatively the recipient of the clip may need to obtain a new licence (e.g. by downloading it across a network as described above). Where the licence is transferred on sharing the clip, the number of times that the clip can be shared before a new licence is required may be limited (e.g. sharing once is permitted only).
In an example, the clip may be downloaded and/or transferred in encoded format such that without the licence (and associated decryption key), the clip cannot be watched.
Given the finite memory of a server (such as server 403 in
Whilst this limit of clip availability will not impact the ability to share clips where the clip data transferred between mobile devices comprises the clip itself, where the clip data comprises an address or other identifier for the clip such that the receiving mobile device needs to download the clip in order to be able to display it, sharing may be limited after a period of time because this download may no longer be possible. As a result of this, the length of time that a clip is available for download may be varied based on the popularity of the clip (e.g. the number of times it is downloaded or shared or the number of times a licence is requested) such that more popular clips remain available for longer than less popular clips. In an example, a clip may remain available for a fixed period after it has last been downloaded (e.g. one week), such that a clip which remains popular over a long period of time will remain available whereas a clip which, although it might be initially popular, is not of long term interest, will be removed once it is no longer being downloaded. It will be appreciated that these feedback mechanisms are provided by way of example only and other mechanisms may be used instead and it will be further appreciated that such a threshold for removal of a clip from memory/broadcast may be set at any level dependent upon the available storage space/broadcast capacity and/or on any other aspect of the service.
The mobile device may run a client application which provides a means for the user to initiate the grabbing of a clip (e.g. by means of a soft key). The client application may include an EPG and the means for initiating the grabbing of a clip may, in some examples, be integrated with the EPG such that the user indicates the required channel as part of the trigger to capture a clip. The application may also comprise a means of viewing the user's library of clips (i.e. those clips stored on the device or those clips for which clip data is stored on the device). This application may use the representative still image of each clip to provide a visual representation of the clips in the library and to enable the user to easily select the clip of interest to be watched/shared. The application may also be integrated with a wireless transfer means (e.g. Bluetooth) such that a soft key may be provided to initiate the transfer of clip data to another mobile device (e.g. a first button to play a clip, a second button to share a clip).
In addition to presenting a visual representation of clips for which data is stored on the device, the application may also display to the user one or more links or representative still images for clips which have not been downloaded but which are similar to one or more of the clips which are stored on the device or clips which have otherwise been made available to the mobile device (e.g. selected randomly or selected for the user of the mobile device based on preferences). For example, if the user downloads two clips showing goals scored by a particular football team, the application may identify other clips of goals for the same football team which are available and present these to the user. The clip data may be downloaded upon selection of the new clip by the user. The identification of suitable other clips may be performed by the application itself, which may then automatically access the representative images (and other clip data) for those unrequested clips, or alternatively, the identification of suitable other clips may be performed in the network (e.g. by web server 403) which may then push data relating to those clips (e.g. address, representative image etc) to the mobile device.
In addition to controlling the transmission of clip data from a mobile device to another mobile device, the application may also control the reception of clip data from other mobile devices, such that the representative images of clips received are also shown to the user and that clips received from other devices can be watched/shared in the same way as clips downloaded/received by the device via a network.
As described above, the clip may be downloaded using a progressive download method. This method may be used for download via broadcast or via any other content distribution network. As described above, the clip to be distributed is divided into a number of segments, each segment containing a number of blocks, as shown schematically in
A receiving mobile device receives blocks which are broadcast (in step 903) and determines whether all blocks from the clip have been received (step 904) and if so the device stops receiving and storing further broadcast blocks (step 905). In parallel to receiving blocks that are being broadcast (in step 903), the mobile device may determine when playback of the clip can commence (step 906) e.g. the amount of time between the start of receiving of blocks and the start of playback, also referred to as the buffer time. This determination may be made after the first block has been received or at any other point and this determination may be made such that playback should preferably not be permitted to start unless the mobile device will be able to play the clip uninterrupted from start to finish, otherwise it will result in a poor user experience. The determination may be made once or may be checked several times. After the required delay (e.g. the buffer time), then the user may be able to watch the clip (step 103 of
The selection of the segment and/or the block (step 901 and/or step 902) may be made from all the segments/blocks in the clip. In an example, the segments are selected sequentially (in step 901) such that all the blocks from the first segment are broadcast before any blocks from the second segment are broadcast, as can be described with reference to
Once all blocks from all segments of the clip have been broadcast, the broadcast of the clip may stop or alternatively, the process may be repeated (e.g. n set back to 1 and the selection process of
It will be appreciated that
In an example implementation, clips may be generated using Windows Media Encoder running on a PC with an Osprey Capture card. The card may be fed by a consumer level Set-Top Box or a production quality Integrated Receiver Decoder. In this example, the content may be encoded at a constant bit-rate for a QVGA (Quarter Video Graphics Array) screen (i.e. 320×240 pixels) to suit a particular type of mobile device (e.g. SmartPhones). Such encoding provides a resulting bit rate of about 260 kb/s with 64 kb/s of that made up of audio, such that a two minute clip takes less that 4 MB of storage space. The thumbnail images used to represent the clips in the UI (user interface) may be derived from the clips using a Video Thumbnail algorithm.
The encoded clip and any thumbnail may then be uploaded to a web server and/or to a broadcast carousel (as shown in
In this example, the application on the mobile device may comprise an Online Media Guide (OMG) from which clips can be downloaded and a Mobile Clip Manager (MCM) that enables the organization and sharing of clips on the mobile device. The OMG may be designed to be device agnostic supporting a scalable rendering interface that can accommodate access by older mobile devices with low resolution displays of 100×100 pixels and devices with 320×240 pixel displays. Interface scaling may be achieved using a combination of smart downsizing and up-scaling of all user interface elements to increase accessibility across many devices.
The MCM may comprise an in built technique for sharing clips among friends in close proximity (˜10 metres) using Bluetooth's OBEX (Object Exchange) communication protocols to enable clip transfers to nearby Bluetooth enabled devices (such as mobile phones, laptops or other mobile devices) regardless of operating system or device manufacturer.
Although the present examples are described and illustrated herein as being implemented in a broadcast or point to point system (as shown in
Whilst the description above refers to audio-visual material and television programs, it will be appreciated that the methods described may be applicable to any audio, visual, audio-visual or other multimedia broadcast content including advertisements, radio broadcasts, broadcast gaming media etc.
The term ‘broadcast’ is used herein to refer to the substantially simultaneous transmission of data to more than one destination, irrespective of whether the data is being transmitted for the first time or is being re-broadcast for any reason. This includes multicast transmissions which involve transmission of data to multiple recipients but not to everyone. The term ‘broadcast’ is also intended to encompass services such as time shifting and near Video on Demand in which a programme is broadcast multiple times with varying start times (e.g. every 10 minutes).
The term ‘computer’ is used herein to refer to any device with processing capability such that it can execute instructions. Those skilled in the art will realise that such processing capabilities are incorporated into many different devices and therefore the term ‘computer’ includes PCs, servers, mobile telephones, personal digital assistants and many other devices.
Those skilled in the art will realize that storage devices utilized to store program instructions can be distributed across a network. For example, a remote computer may store an example of the process described as software. A local or terminal computer may access the remote computer and download a part or all of the software to run the program. Alternatively, the local computer may download pieces of the software as needed, or execute some software instructions at the local terminal and some at the remote computer (or computer network). Those skilled in the art will also realize that by utilizing conventional techniques known to those skilled in the art that all, or a portion of the software instructions may be carried out by a dedicated circuit, such as a DSP, programmable logic array, or the like.
Any range or device value given herein may be extended or altered without losing the effect sought, as will be apparent to the skilled person.
It will be understood that the benefits and advantages described above may relate to one embodiment or may relate to several embodiments. It will further be understood that reference to ‘an’ item refer to one or more of those items.
The steps of the methods described herein may be carried out in any suitable order, or simultaneously where appropriate.
It will be understood that the above description of a preferred embodiment is given by way of example only and that various modifications may be made by those skilled in the art. The above specification, examples and data provide a complete description of the structure and use of exemplary embodiments of the invention. Although various embodiments of the invention have been described above with a certain degree of particularity, or with reference to one or more individual embodiments, those skilled in the art could make numerous alterations to the disclosed embodiments without departing from the spirit or scope of this invention.
| Number | Date | Country | Kind |
|---|---|---|---|
| 06123641.0 | Nov 2006 | EP | regional |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/US2007/082169 | 10/23/2007 | WO | 00 | 5/6/2009 |
