text:
|Publication number
|Publication type
|Application number
|Publication date
|Jul 24, 2007
|Filing date
|Jun 25, 2002
|Priority date
|Jun 25, 2002
|Fee status
|Also published as
|Publication number
|Stephen B. Boston, David Earl Blaschke, Michael Wayne Brown, Andrew Douglas Hately, Michael A. Paolini
|Original Assignee
|International Business Machines Corporation
|Export Citation
|BiBTeX, EndNote, RefMan
|Patent Citations (1), Non-Patent Citations (3), Referenced by (30), Classifications (16), Legal Events (5)
|External Links: USPTO, USPTO Assignment, Espacenet
The present application is related to the following co-pending U.S. Patent Applications, filed on the same day as the present application, having the same inventors and assignee, and which are hereby incorporated by reference:
1. Field of the Invention
The field of the invention is data processing, or, more specifically, methods, systems, and products for automated personal video recording.
2. Description Of Related Art
In the current art of the personal video recorder ("PVR"), the storage space available upon which to record television shows or other video content ("shows") is a limited resource. PVRs are relatively expensive and therefore are typically shared by more than one user. The Tivo™ system is an example of such a PVR, and today the Tivo™ system is marketed by the number of hours of video content it can record, typically 20, 30, or 50 hours. In a setting with more than one user, the recording time available on typical PVRs is not configured or controlled by user allocation, which causes problems. One user may use a disproportional share of the storage space available for recording video content, leaving little or none for other users of the recorder. It would be advantageous if there were ways to configure or control storage space to facilitate use by multiple users, allowing for multiple users to share the storage resources collision-free, with little risk of erasing or overwriting someone else's recorded shows. In addition, it is useful to note that estimates of storage space required for recording a particular show are made in dependence upon an estimated compression level. It would advantageous, therefore, to have means and methods of administering the risk that an estimate of compression level and therefore an estimate of storage space requirement will be too small. Moreover, although such provisions are substantially lacking in the prior art, it would be advantageous also to provide various ways for users to aggregate their abilities to lend, borrow, and record shows.
Multi-user PVRs according to embodiments of the present invention typically implement methods for automated personal video recording that include recording a first show, and displaying at least a portion of the first show, creating displayed space. Such PVRs typically include freeing displayed space, making available free space, and recording at least part of a second show in free space made available by freeing displayed space. When a the second show's storage space requirement exceeds an amount of free space available for recording the show by a deficit amount, a PVR according to the present invention typically include borrows a loan amount, the loan amount being less than the deficit amount. In some embodiments, the first show and the second show can be the same show.
Exemplary embodiments of the invention typically include identifying displayed space for a show. In such embodiments, identifying displayed space for a show typically includes storing a display start time and a display stop time for a display period for a show, subtracting the start time from the stop time, establishing a duration for a display period for the show, and multiplying the duration of the display period by a frame rate for the show. Such embodiments typically include identifying the frame rate in dependence upon the compression level of a show.
In exemplary embodiments, freeing displayed space typically includes discarding displayed frames. In such embodiments, discarding displayed frames typically includes calling software routines in a video editing API. In some embodiments, the show typically includes video frames, including displayed frames, in a video file, and discarding displayed frames typically include deleting displayed frames from the video file. In other embodiments, the show typically includes video frames, including displayed frames, in an original video file and discarding displayed frames typically includes streaming the show from the original video file to a new video file, excluding displayed frames, and deleting the original video file.
The foregoing and other objects, features and advantages of the invention will be apparent from the following more particular descriptions of exemplary embodiments of the invention as illustrated in the accompanying drawings wherein like reference numbers generally represent like parts of exemplary embodiments of the invention.
The present invention is described to a large extent in this specification in terms of methods for automated personal video recording. Persons skilled in the art, however, will recognize that any computer system that includes suitable programming means for operating in accordance with the disclosed methods also falls well within the scope of the present invention.
Suitable programming means include any means for directing a computer system to execute the steps of the method of the invention, including for example, systems comprised of processing units and arithmetic-logic circuits coupled to computer memory, which systems have the capability of storing in computer memory, which computer memory includes electronic circuits configured to store data and program instructions, programmed steps of the method of the invention for execution by a processing unit. The invention also may be embodied in a computer program product, such as a diskette or other recording medium, for use with any suitable data processing system.
Embodiments of a computer program product may be implemented by use of any recording medium for machine-readable information, including magnetic media, optical media, or other suitable media. Persons skilled in the art will immediately recognize that any computer system having suitable programming means will be capable of executing the steps of the method of the invention as embodied in a program product. Persons skilled in the art will recognize immediately that, although most of the exemplary embodiments described in this specification are oriented to software installed and executing on computer hardware, nevertheless, alternative embodiments implemented as firmware or as hardware are well within the scope of the present invention.
In this specification, the terms "field" and "data element," unless the context indicates otherwise, generally are used as synonyms, referring to individual elements of digital data. Aggregates of data elements are referred to as "records" or "data structures." Aggregates of records are referred to as "tables" or "files." Aggregates of files or tables are referred to as "databases."
The terms "borrow," "lend," and "loan," subject to context, generally imply a relatively shorter term rearrangement of storage space effected under automated control of a PVR. The term "allocate," subject to context, generally implies a relatively longer term rearrangement of storage space effected by users' manual inputs through user interfaces. An example of borrowing is a PVR's determination at record time that a deficit of storage space exists that needs to be cured before recording proceeds. If the cure is a rearrangement of storage space to be reversed after users view a show, then the cure is said to be a 'borrowing' or a 'loan.' An example of an allocation is a user's manual instruction through a keyboard or a remote control device, in response to prompt screens, and by use of data input screens on a display device, to assign a portion of unallocated storage space to a user or to a pool.
"Cinepak" is a popular codec originally developed by SuperMac, Inc.
"Codec" is an industry-standard term referring to "encoder/decoder," or perhaps more legibly, "coder/decoder". Codecs are means and methods for encoding and decoding video with audio. Codecs are implemented in hardware or in software. The codec illustrated at reference 176 in
Codec functions include compression and decompression. When show is encoded, it is converted to a compressed format suitable for storage or transmission; when it is decoded it is converted to a non-compressed (raw) format suitable for presentation. Each codec has certain input formats that it can handle and certain output formats that it can generate. In some situations, a series of codecs are used to convert from one format or compression level to another.
"DVD" stands for 'Digital Versatile Disc' or 'Digital Video Disc,' an improved storage standard that holds at least of 4.7 gigabytes, enough for a full-length movie. DVD storage, like CD-ROM storage, is typically eventually optical, although the format does not strictly required optical storage and is often implemented in other kinds of storage, magnetic or electronic, at least as interim measures. The DVD specification supports disks with capacities of from 4.7 gigabytes to 17 gigabytes and access rates of 600 KBps to 1.3 MBps. DVD drives are backward-compatible with CD-ROMs. That is, DVD players can play old CD-ROMs, CD-I disks, and video CDs, as well as DVD-ROMs. DVD players can also read CD-R disks. DVD may be pertinent to PVRs according to embodiments of the present invention because DVD, like HDTC, uses MPEG-2 to compress video data.
"Compression" as the term is used in this disclosure refers to the overall effect of all applicable techniques for video file size reduction, including, for example, reduction of color space, reduction of frame rate, reduction of resolution, reduction of audio quality, and changes in compression algorithms or compression algorithm parameters as such. There are many ways, as will occur to those of skill in the art, to reduce file size by manipulation of compression algorithms and the parameters of compression algorithms. The use of the term "compression" in this disclosure, however, subject to context, of course, is generally broader than mere manipulation of compression algorithms.
"Compression level" refers to an estimated compression level calculated on the basis of a show's duration and an estimated compression level for the recorded content of the show. Unless the context requires otherwise, the term "compression level" means "estimated compression level."
"Compression algorithm" refers to a particular type of compression technique, including lossy as well as lossless compression, including for example, Lempel-Zif-Welch compression, which is the compression technique used in the popular graphics file format known as "GIF"; various flavors of Lempe-Zif compression such as LS-77 and LZ-78, LZ-78 being a 'dictionary' compression technique used in many popular applications such as the well-known 'zip' utilities; run-length encoding; and Huffman encoding.
"ID" abbreviates "identification," meaning 'identification code' or identification field. It is a style of reference in this disclosure to refer to user identification codes as "user IDs." By convention in this disclosure, the field name "UserID" is used to store a user ID. That is, for example, the UserID field 190 in the example user profile 202 in
"JPEG" stands for Joint Photographic Experts Group, the original name of the committee that developed the standard. JPEG is a data compression standard for graphic images. JPEG can reduce files sizes to about 5% of their uncompressed size, although some detail is lost in the compression.
"Motion JPEG" or "MJPEG" extends the JPEG standard by supporting video. In Motion JPEG, each video frame is stored using the JPEG format. In this regard, note that the 5% compression estimate for JPEG is the effect of the compression algorithm alone, without regard to frame rate, resolution, and so on.
"MPEG" stands for 'Moving Picture Expert Group,' a working group under "ISO," the International Organization for Standardization and "IEC," the International Electrotechnical Commission. What is commonly referred to as "MPEG video" actually includes three standards, MPEG-1, MPEG-2, and MPEG-4. MPEG-1 and MPEG-2 are similar. They both work on motion compensated block-based transform coding techniques. MPEG-4 differs in its use of software image construct descriptors for target bit-rates in the very low range, less than 64 Kb/sec.
"MPEG-1" was originally optimized to work at video resolutions of 352�240 pixels at 30 frames/sec (NTSC based) or 352�288 pixels at 25 frames/sec (PAL based), commonly referred to as Source Input Format (SIF) video. The MPEG-1 resolution is not limited to the above sizes and in fact may go as high as 4095�4095 at 60 frames per second. MPEG-1's bit-rate is optimized for applications of around 1.5 megabits per second, although MPEG-1 can be used at higher rates if required. MPEG-1 is defined for progressive frames only, and has no direct provision for interlaced video applications, such as are used in broadcast television applications.
"MPEG-2" addresses issues directly related to digital television broadcasting, such as the efficient coding of field-interlaced video and scalability. MPEG-2's target bit-rate is higher than MPEG-1's, between 4 and 9 Mb/sec, resulting in potentially very high video quality. MPEG-2 is based upon 'profiles' and 'levels.' The profile defines bitstream scalability and colorspace resolution, while the level defines image resolution and maximum bit-rate per profile. Probably the most common descriptor in use currently is 'Main Profile, Main Level' (MP@ML), which refers to 720�480 resolution video at 30 frames/sec, at bit-rates up to 15 Mb/sec for NTSC video. Another example of an MPEG-2 descriptor in common use is the HDTV resolution of 1920�1080 pixels at 30 frame per second, at bit-rates up to 80 megabits per second. This HDTV example is a 'Main Profile, High Level' (MP@HL) descriptor. A complete table of the various legal combinations can be found in reference2.
"NTSC" stands for a video standard promulgated by the National Television Standards Committee. The Committee is responsible for setting television and video standards in the United States. In Europe and the rest of the world, the dominant television standards are PAL and SECAM. The NTSC video standard defines a composite video signal with a frame rate of 30 frames/second implemented as 60 interlaced half-frames per second. Each frame contains 525 lines and can contain 16 million different colors. A newer digital television standard is called "HDTV" for High Definition Television, supporting higher resolutions than NTSC.
"Show" means any recordable or distributable electronic or digital content including television broadcasts, movies, CD contents, DVD recordings, cable transmission, satellite transmissions, commercial video clips, audio, multi-media programming, and the like. Shows include any image or series of images delivered to users through any mechanism or means, including associated audio or other multi-media content.
Unless the context requires otherwise, "user" means 'registered user,' that is, a user having within a PVR a representative user profile such as those illustrated by the record structure at reference 202 on
"Video" as the term is used in this disclosure, and according to context, generally includes audio.
With reference now to the figures, and in particular with reference to
The PVR 106 is connected to the television 102 by cable 104. The cable connection 104 can be for video and audio through a standard video cable, or for television broadcast frequencies through a standard coaxial cable. A remote control unit 110 allows users to interact with and control the PVR 106. Remote control unit 110 emits infrared ("IR") signals, although other kinds of remote control emissions are within the scope of the invention, including for example radio control. The example PVR 106 includes an IR window 109 for receipt of information and instructions from remote control unit 110. Functions provided by use of the remote control unit 110 include the ability to move a cursor on a display and select items shown on a display.
The remote control unit includes conventional numeric keys 131 as well as buttons associated with television and recorded playback control including a "Volume" control 132, a "Channel" selector 120, a "Mute" button 118, and buttons for "Play" 124, a rewind button called "Back" 134, a fast forward button labeled "Fwd" 130, and a pause button 126. The "Record" button 122 is used to instruct the PVR to record a show typically when the show has been selected, for example, through navigation through a series of display screens depicting television broadcast schedules for televisions shows.
In the previous few paragraphs, we described an embodiment of the present invention as an information handling system with automated computing machinery configured as a PVR, a set top box coupled to a television for display and user interaction and controlled by a remote control unit. It is useful to understand that the set top box configuration is not at all the only configuration of a PVR within the scope of the present invention, and to clarify this point, we ask the reader to consider PVRs implemented as software installed upon general purpose computers. In the case of a PVR embodied upon a general purpose computer, the PVR is implemented as software installed in computer memory in a conventional fashion to embody the inventive steps of the present invention.
Although a PVR implemented as a set top box will include by special design within the set top box all the hardware resources needed to implement the steps of the invention and store content in accordance with the invention, not all computers will possess such hardware. To the extent that any general purpose computer, however, and today many of them do, possesses sufficient resources to download, read from a compact disc, receive cable television, or otherwise access recordable content, and sufficient resources to store such recordable content on hard disk, writable optical drives, or other storage media, then any general purpose computer can be configured as a PVR according to an embodiment of the present invention.
For PVRs embodied in general purpose computers according to the present invention, PVR controls are implemented through the usual user interface as provided in connection with any particular computer terminal, computer screen, computer keyboard, computer mouse, and so on. In this sense, general purpose computers include personal computers, portable computers, minicomputers, mainframes, laptop computers, handheld computers, personal digital assistants, wireless Internet-enabled cell phones, and so on.
Also stored in RAM 168 is an operating system 154. Embodiments of the present invention are directed towards personal video recording for multiple users. It will occur to readers skilled in the art that much of the work of administering user accounts for many users may be downshifted to a multi-user operating system such as Unix, Linux, or Microsoft NT™. The multi-user features of typical embodiments of the present invention, however, tend to be features of application software. PVRs according to embodiments of the present invention, therefore, may use single-user operating systems, such as Microsoft's Disk Operating System or "DOS," as well as multi-user operating systems, or even operating systems developed as special purpose systems just for use in PVR according to this invention. In this disclosure, we speak of administration of multiple users in terms of "user profiles," to distinguish our application-level user administration from any operating system's administration of 'user accounts.'
The PVR 106 of
The example PVR 106 of
The example PVR of
The example PVR of
The PIN 192 is assigned to the user at registration time and is unique to the user. In PVRs implemented as set top boxes, it is common to utilize numeric PINs because they are easily entered through numeric keys on remote control units (reference 131 on
Clearly PVRs implemented upon general purpose computers or any device having a keyboard, for example, would experience no particular benefit from numeric-only PINs or passwords.
The user privilege level 194 provides the capability of distinguishing privileges according to class of user. That is, the user privilege level 194 supports the establishment of classes of users having various levels of privilege. A common example is a class of administrative users or 'super users' who are privileged to edit the profiles of other users. In a home setting, therefore, parents would often be super users privileged to set content restrictions on children's profiles. In a business setting, system administrators in the Information Technology Services organization would often be privileged to create and administer profiles for users with normal usage privileges.
The example user profile 202 of
The allocated space field 198 records the amount of storage space presently allocated to the user. It is usual, although not a requirement of the invention, that the allocated space is altered only by super users, so that normal users avoid conflict risked by normal users changing their own storage space allocations. An initial quantity of allocated space is assigned to each user at registration time, when the user's user profile is created.
As the user records shows in the user's allocated space, when a show is recorded in a user's allocated storage space, some of the storage space, the space upon which the show is recorded, is said to be 'used.' Each show has a storage space requirement that uses some of a user's allocated storage. The current total of the used space of all the shows recorded for a user can be stored in the UsedSpace field 204. The free space field 206 is provided for storing the difference between allocated space 198 and used space 204. When a PVR records a show for a user, the PVR increments UsedSpace 204 by the amount of the show's storage requirement and decrements FreeSpace 206 by the same amount.
When the PVR records a show for a user whose FreeSpace is less than the show's storage space requirement, it is an aspect of PVRs according to embodiments of the present invention that the user, acting as a borrower, can borrow space from another user, a lender. The amount of storage space that the user represented by the user profile 202 has borrowed can be recorded in the BorrowedSpace field 208. Similarly, the amount of storage space that the user has loaned to other users can be recorded in LoanedSpace 210. Just as the PVR decrements FreeSpace 206 when the PVR records a show for the user, the PVR also can decrement FreeSpace 206 when the PVR loans a portion of the user's allocated space 198. In this example, therefore, the FreeSpace amount 206, that is, the amount of storage space available to a user for recording shows would be the user's allocated space 198 minus the user's used space 204 minus the user's loaned space 210. It will be discussed in more detail below, but it should be clear that when a user's free space is less than the storage space requirement for a show to be recorded for the user, an alternative process available to a PVR, in addition to borrowing space from a lender, is to repossess space that the user previously loaned to borrowers. In the present example, such repossession would reduce LoanedSpace 210 and increment FreeSpace 206 by the amount of space repossessed.
The example user profile 202 of
An example of a more finely-grained lending authorization is depicted in the lending authorization records 220 in
Of course other granularities are possible within the scope of the present invention, including, for example, lending authorizations having validity periods with beginning dates and ending dates, or lending authorization for identified user groups or for users having certain lending priority levels. The possible settings are many, and any data structure, encoding method, or granularity of lending authorization as will occur to those of skill in the art is well within the scope of the present invention.
The example user profile 202 of
The example data structures of
"User scheduling" is a user's entering through a user interface a title and recording schedule for the show. The user interface will vary from PVR to PVR. The user interface, in PVRs implemented as set top boxes, is typically a remote control unit maneuvering a pointer over a scrolling list of television shows on a television screen. The user interface, in PVRs implemented as personal computers, is typically a keyboard, a mouse, and a computer screen upon which is displayed a mouse pointer used to highlight and select from scrolling lists of television programs or web sites hosting video clips of interest.
"Preference recording" is a PVR's being programmed to select and record shows based upon previous indications of user preference. Previous indications of user preference are implemented, for example, as a genre preference 260 in a user profile 202, causing a PVR so programmed, when a user has sufficient free space to support such recording, reading the user's previously indicated preference for Comedy, Drama, Science Fiction, or Sports, for example, scanning presently available sources, selecting the first show that matches the user's genre preference for which the user has sufficient free space, and recording that show. In accordance with the present invention, the PVR can be programmed to borrow space from another user if the user has insufficient free space to store the show.
Alternatively, to achieve even greater power to express particular preferences, PVRs can support separate user preference records 320 linked to user profile 202 through a userID 322 as a foreign key. Such separate preference records 320 can support any indication of user preference including, for example, preferences for particular actors 326, preferences for particular title 324, and indications of a user's intensity of preference, encoded as preference Level 328. With respect to preference levels 328 in particular, the PVR can be programmed to record a range of preference levels, for example, 1 through 10, in which a preference level of '10' indicates that the user likes a particular show title very much, '5' indicates neutrality, and a '1' indicates dislike. The Boolean field 'Preference' 278 on the show record 240 indicates whether a recording is a preference recording. So that a user can know what has been recorded on the user's behalf without the user's prior knowledge, PVR screens showing a user's recorded shows typically indicate visually the recorded shows that are instances of preference recording.
The example show record of
Shows in the present example, however, are identified by identification codes 241, identification codes having no relationship to storage locations in storage space. There would be, for example, one identification code for a show titled 241 a "Dukes of Hazzard," another identification code for the show titled 241 a "Star Trek," and another for the show titled 241 a "Buffy The Vampire Slayer." Operating systems (154 on
PVRs according to some embodiments of the present invention are programmed to utilize the ShowID field 241 as a completely unique key identifying a particular instance of a show to be recorded at a particular date and time, encoded in the Schedule field 272 in
The storage space requirement 246 and the duration 247 are related. The storage space requirement generally is expressed as some number of bytes, kilobytes, or megabytes of storage space. The duration 247 is generally expressed in minutes or hours, a half-hour show, a two-hour movie, and so on. Shows can be recorded in storage space using various kinds of compression ranging from no compression to lossless compression to quite lossy compression. For a show of a given duration, applying higher levels of compression reduces the storage space requirement for the show.
The source 270 can be encoded to indicate a channel number for capturing recorded content from broadcast television, cable television, or satellite television. The source 270 can be encoded with an Internet address identifying a source for downloading recordable content. Internet addresses can be encoded by use of dotted decimal addresses, Universal Resource Locators ("URLs"), or Universal Resource Identifiers ("URIs").
The schedule 272 is a data element for storing the broadcast schedule of the show represented by the show record 240. For example, the schedule field 272 can be encoded with a date and time when a television show is broadcast and therefore to be recorded. The record period 274 provides an indication of a period over which a show may be recorded many times. For example, schedule 272 can be encoded with a schedule indication of Wednesday, 7:00 p.m., and record period 274 can be encoded with 'January through June,' resulting in recording the indicated show weekly for six months.
The retention period 276 is a field indicating how long to retain the show before deleting it. The retention period 276 and indications of viewing 248 can work together in various PVR according to embodiments of the present invention. In
The Viewed field 248 in the show records 240 indicates whether the owner of the show has viewed the show. In a multi-user environment, however, it may be useful to retain the show in storage until more than one user has viewed it. The viewing records 250 in
In lending and borrowing storage space among users, some method is needed to keep track of who has lent what to whom. The example data structures of
The method according to
A 'lender' in this sense is a user registered on the PVR having free storage space or "free space," that is, for example, a free storage space field in the lender's user profile having as its value an amount larger than zero and, reflected in the lender's user profile, free space larger than zero. All lenders may have MaximumLoan authorizations (226 on
The PVR can fail to select one or more lenders having authorized and available storage space for lending. In such an eventuality, the PVR can be programmed to stop 412 the recording of the show.
The example method of
In other examples, the loan amount, the amount actually borrowed is not equal to the deficit amount. The PVR may be programmed to borrow for the borrower more than the deficit amount, to give a little headroom for recording. In addition, several loans may be required to amount to the deficit amount, if, for example, no single lender has an authorized maximum larger than the deficit amount or if no single lender has free space larger than the deficit amount. In such cases, there would be more than one loan amount, none of which would be equal to the deficit amount, but the sum of which would be at least equal to the deficit amount. In these examples, although the loan amount may not be equal to the deficit amount, the borrowing is carried out in dependence upon the deficit amount in the sense that the deficit amount is a guide to the total amount to borrow, that is, a guide to borrowing the loan amount.
In the example method of
With reference to
All lenders may have MaximumLoan authorizations (226 on
In the example method of
More particularly, with regard to
The method of
In operation of the example method of
Processing of borrowed storage space according to embodiments of the present invention includes returning borrowed space to lenders. As described earlier, return of borrowed space can occur when the borrower has viewed the show for which the space was borrowed. It can also occur, however, within the scope of the present invention, that borrowed space needs to be "repossessed" by a lender. More particularly, when recording a show for a lender, the show can have a storage space requirement exceeding the lender's free space. The difference between the storage space requirement of the show and the lender's free space is called a 'deficit amount.'
The lender in this example is a user who has already loaned some storage space to one or more other users, that is, borrowers. In this example, a PVR according to an embodiment of the present invention is programmed to determine whether other free space is available for lending from other users to the lender, and, if no other free space is available for lending to the lender, returning from at least one borrower to the lender at least part of the loan amount previously loaned to the borrower from the lender.
The PVR in this example is programmed to scan lending authorization records to determine whether there exists storage space available for the lender to borrow 804. If storage space is available for the lender to borrow, then the PVR arranges a loan to the lender 816, and recording continues 822. In this example, if there is no space available for borrowing, then the PVR repossesses at least some of the storage space previously borrowed by other users ("borrowers") from the lender. More particularly, the PVR proceeds by finding 806 a loan record 230 representing a loan of storage space from the lender to a borrower, adding 808 the LoanAmount 236 from the loan record to the lender's FreeSpace field 206, subtracting 810 the LoanAmount 236 from the lender's LoanedSpace field, and subtracting 811 the LoanAmount 236 from the borrower's BorrowedSpace field.
In the example of
If the LoanAmount in the loan record is less than the deficit amount, the PVR may be programmed to repeat 824 the steps of finding a loan record 806, repossessing loaned storage space (808, 810, 811), deleting a borrower's show 820 or subtracting a loan amount from borrower's FreeSpace 818, and deleting a loan record 812, until sufficient storage space has been repossessed to support completing the recording of the lender's show 822. This is an example of repossessing more than one loan amount. That is, in this example, when the lender has outstanding loan amounts to more than one borrower, or more than one loan to the same borrower, wherein returning from the borrower to the lender at least part of the loan amount includes returning at least parts of loan amounts from more than one borrower.
The storage space requirement 246 for a show 240 is an estimate calculated on the basis of the duration 247 of the show and the estimated compression level for the show.
As an aid to understanding, we discuss an example of a calculation of a desired minimum compression level. As mentioned earlier, one of the formats defined for HDTV broadcasting within the United States is 1920 pixels horizontally by 1080 lines vertically, at 30 frames per second. If these numbers are all multiplied together, along with 8 bits for each of the three primary colors, the total data rate required would be approximately 1.5 gigabits per second. Because of the 6 megahertz channel bandwidth allocated for HDTV, each channel will only support a data rate of 19.2 Mb/sec, which is further reduced to 18 Mb/sec by the fact that the channel must also support audio, transport, and ancillary data information. This restriction in data rate means that the original signal must be compressed by a figure of approximately 83:1. This estimated minimum compression is for broadcast only, with commercial HDTV quality of frame rate and resolution. In addition, this estimated minimum compression is raw broadcast compression only, just enough to fit a video stream into a transmission bandwidth, not yet affected by desirable further (relative) compression needed to fit a show into a particular space requirement in the storage space of a PVR. As illustrated by the example compression level records in
As a further aid to understanding compression operations in PVRs, we present an example calculation of a compression ratio, presented in terms of a single image, which could be, for example, a static graphic image or a single video frame. The compression ratio is defined for calculation as the number of bits/pixel in the original image divided by the number of bits/pixel in the compressed image. Assume that the original image has a resolution, or rather a size, of 320�240 pixels each represented in a 24-bit data word. And assume that after initial compression the compressed file size is 5000 bytes. Then the bits/pixel for the compressed image is (5000*8)�(320*240)=0.52 bits/pixel. In other words, the original image used need 24 bits to represent each pixel, but after compression, only need 0.52 bits are used to store each pixel (on average). The compression ratio therefore is 24�0.52=46.
Factors that affect overall estimate compression level are shown in tables 420 and 602 in
The example records in table 420 show several examples of compression level 422 estimated on the basis of the factors affecting compression. The compression levels are shown in absolute terms and then in parenthesis relative to a video source bit stream. Table 420 is organized with respect to an HDTV source having an initial resolution 430 of 1930�1080. Table 602 is organized with respect to an NTSC source having an initial resolution of 720�480.
Record 440 shows an estimated initial raw compression level 422 in the source stream of 80:1 estimated on the basis of encoding according to MPEG-2, colorspace size 4:4:4 or '48,' frame rate 428 of 30 frames/second, resolution of 1930�1080 pixels (an HDTV standard), with 'High' audio quality 432. Record 440 is show with a relative compression of (1) with respect to itself.
The target records, records 442 through 450, illustrated compression levels supported by an exemplary PVR with respect to a video source of the kind represented in the source record 440. Record 442, for example, shows an estimated absolute compression level 422 of 480:1, or a compression level of (4) relative to the source stream, estimated on the basis of encoding according to MPEG-2, colorspace size '48,' frame rate 428 of 30 frames/second, resolution of 720�480 pixels (an NTSC video standard), with 'High' audio quality 432. In other words, recompressing the source stream using a resolution reduced from 1930�1080 (HDTV) to 720�480 (a high quality of NTSC video) reduced projected space requirement for a subject show by a factor of six. This is a useful demonstration of the fact that, although algorithmic compression alone can result in absolute compression ratios in the range of approximately 100 to 200, reductions in parameters other than compression technique as such, factors such as, for example, colorspace, frame rate, resolution, and audio quality, can result in very large overall compression levels.
Record 444 shows an estimated absolute compression level 422 of 960:1 and a relative compression of (12) with respect to the source stream, achieved by reducing the size of the colorspace 426 from 48 to 24, that is, for example, from 4:4:4 to 4:2:4. Record 446 shows an increase in relative compression to approximately (48) through an additional reduction in resolution 430. Record 448 shows an estimated relative compression level of (100) from changing encoding 424 to MPEG-1 and reducing audio quality 432. Record 450 shows an estimated relative compression level (140) estimated from an additional change in encoding 424 to MJPEG and an additional reduction in audio quality 432.
For a further example, consider table 602 in
The examples records representing various compression levels in
Tables such as those shown in
For example, consider given a 30 minute NTSC show broadcast in MPEG-2 with a resolution of 720�480 requiring with no further compression an initial raw compressed file size of 50 megabytes, corresponding to a supported video source depicted at record 604 in table 602 on
The tables in
Shows recorded on PVRs generally are compressed, but the actual level of compression actually achieved generally is known only as an estimate. Each show's storage space requirement, therefore, is an estimate. In other words, when a PVR begins recording a show, perhaps even borrowing storage space in dependence upon a comparison of the show's storage requirement and a user's free space, the PVR cannot know for certain that the amount of space borrowed can actually support the recording. A method is needed for checking the show's storage space requirement during recording and borrowing more space if needed. In fact, we disclose two ways of administering the risk of storage space estimation, one method using a space check threshold for checking a show's storage space requirement during recording and a second method using overallocation.
The space check threshold 310 is the portion of the show duration (247 in show record 240) to be recorded before recalculating the show's storage space requirement 246. The space check threshold can be implemented in data structures as shown at reference 310 in the PVR profile structure 300 in
When the tracked recording period is at least equal to the space check threshold 310 multiplied by the show's duration 247, the PVR checks the estimated storage space requirement by comparing the actual storage space used with the amount of storage space projected to be used based on the estimated storage space requirement. The projected usage is the space check threshold 310 multiplied by the original estimated storage space requirement 247.
If the actual space used is greater than the projected usage, the PVR according to the method of
The method of
Assume that the initial bit rate for a 30 minutes show, a video download for example, is 150 kilobits/second, which would be fairly high quality video at MPEG-1. Thirty minutes is 1800 seconds, the duration of the show. 150,000 multiplied by 1800 is 270 megabits total space requirement, divided by 8 bits/byte is about 34 megabytes for the show's storage space requirement. This show is downloaded with quite a lot of compression, and the storage space requirement is definitely an estimate.
Because we know before beginning recording that the storage space requirement is an estimate, another way of dealing with the risk of estimation is shown in the method illustrated in
The method of
Returning the unused loan amount 474, expressed in terms of the data structures of
The effectiveness of compression depends on genre. More particularly, the effectiveness of actual video compression depends on the motion of the subjects depicted in the video. Consider five frames of a close-up still life of an apple. The first frame must be encoded in its entirety, but the subsequent four frames need only refer to the first frame; they need not be encoded at all. In five frames of video tightly focused on eleven football players during a play, however, a large proportion of the pixels in the frame will change from frame to frame for each of the five frames. Five frames of football is must less effectively compressed than five frames of a fine arts show. The arts are more effectively compressed than drama. Drama is more effectively compressed than action movies. Action movies are more effectively compressed than sports events, and so on.
The methods of
In a PVR implementing the method of
In a PVR implementing the method of
With reference to
With reference to
At this point we have disclosed at length personal video recording with loans of storage space among users. We can add power and flexibility to personal video recording, however, by supporting various ways of allowing users to aggregate their abilities to lend, borrow, and record shows. We therefore now turn our attention to pools and groups.
We begin with a reconsideration of overall structure of storage space. With reference to
A pool is an aggregation of storage space for lending. Pools are assigned their own storage space. Pools lend their storage space to borrowers. Although there is nothing within the scope of the present invention that excludes pools from lending, in this disclosure, our examples of aggregations for borrowing are the 'groups' described below. In our examples of pooling, to reduce the risk of confusion and augment clarity of explanation and understanding, we describe examples of pools that do not borrow.
Pools acquire their storage space by assignments of storage space from unassigned storage space or through allocations from users' free space. Pools are generally authorized to lend their storage space to users or to groups. An example of an authorization to lend is creations of a lending authorization record.
More particularly,
Loans of storage space from a pool are authorized in lending authorization records such as those depicted at reference 220. The lending authorization records comprise the data elements LenderID 222. In the case of loan authorizations from pools, the LenderID field stores a pool ID. Fields of the lending authorization records also include a BorrowerID 224, which stores a user ID or a group ID of a user or group authorized to borrow from the pool. The BorrowerID field 224 can also store a wild card value such as a '*,' indicating authorization to lend from the pool to any user or group. Fields of the lending authorization records also include a MaximumLoan field 226 in which is stored the maximum amount of storage space authorized by the lending authorization record for lending from the pool to a borrower.
The selecting is carried out in dependence upon the deficit amount 1512. That is, for example, a lender is selected who has authorized lending of at least the deficit amount and who has free space at least equal to the deficit amount. Alternatively, if no single lender has sufficient free space and sufficient lending authorized, several lenders may be selected, until the lenders' aggregate free space and maximum loan amount authorizing lending to the borrower are at least equal to the deficit amount.
The method according to
In the method according to
More particularly,
Now with respect to the overall storage space structures illustrated in
Groups are aggregations of recording power. That is, groups aggregate free space and borrowing power in support of recording rather than lending. Although it is not a limitation of the present invention, in our exemplary aggregations, it is groups rather than pools that are authorized to borrow storage space. It is pools rather than groups, in our examples, that lend storage space. Groups comprise members, and groups, at least implicitly and as described in more detail below, apportion storage space among their members.
Group space, that is, storage space assigned to a group, can be allocated or borrowed. Group space can be allocated from users' free space or from unallocated space. Group space can be borrowed from any lender issuing a lending authorization record in favor of a group, that is, from users or pools.
The exemplary data structures of
The member records 2106 contain a user ID field 322 identifying a user as a member of the group identified in the GroupID field 2104. The user ID field 322 is a foreign key linking the member records one-to-many to user profiles 202. In the exemplary data structures of
Groups can have stated preferences. More particularly, groups, through their authorized representatives, can create expressions of preference in the form, for example, of user preference records 320. For groups' expressions of preference, the UserID field 322 in a preference record 320 stores a group ID, acting as a foreign key, linking user preference records 320 one-to-many to groups. That is, each group can assert many preferences. PVRs according to embodiments of this kind are programmed to carry out preference recording for groups in the same way that preference recording is done for individual users.
Groups' authorized representatives can schedule recordings of shows for groups in the same way that shows are scheduled for users, for example, by creation of a show record effected through a user interface. More particularly, a show 240 scheduled to be recorded on behalf of a group 2102 has stored in its OwnerID field 244 the group ID of the group on whose behalf the show is scheduled to be recorded. In such embodiments, that group is considered the owner of such a show.
As for borrowing, any lending authorization record (220 on
Borrowing for groups can be further explained with reference to the exemplary method of personal video recording depicted in
Loans from pools to groups are optional. That is, there is no requirement within the present invention for pools to loan to groups, and it is entirely within the scope of the present invention for a PVR's programming to effect loans to groups only from individual users.
PVRs can be programmed to accept scheduling entries for shows or expressions of group preferences from all group members or less than all. The example data structure for member records 2106 includes a Boolean field AuthorizedRep 2110 in which is stored an indication whether the member represented by the member record 2106 is authorized to schedule shows and assert preferences on behalf of the group.
To the extent that group allocation comes from members' free space 1904, members' allocated space (as reference 198 on
It is an advantage of the use of groups to record shows that the use of individual user's free space is leveraged. An example of such leveraging is a show having a storage space requirement of 50 megabytes recorded for a group having three members each of whom contributed 20 megabytes of user free space to the group's storage space, that is, equal contributions from each user. In this example, each user's free space is implicitly used at the level of 16.67 megabytes in return for which each user is empowered to record and view a 50 megabyte show.
It is also an advantage that group ownership in shows implicitly apportions ownership among members according to their relative contributions to a group storage space. Consider an example in which three users group to record comedy shows knowing in advance that users 1 and 2 have less interest in comedy that user 3. The users contribute their free space to group storage space in the proportion 1/1/2, that is, 10 megabytes from user 1, 10 megabytes from user 2, and 20 megabytes from user 3. In using 10 megabytes to record a show, therefore, the three users implicitly use their storage space respectively at the levels of 2.5 megabytes, 2.5 megabytes, and 5 megabytes. This is an explicit use of group storage space that implicitly apportions the space requirement according to predetermined weighted coefficients, set by the users themselves, rather than equally among all three members of the group.
In all our example thus far regarding groups, it is a group as a whole that records and deletes each show, and, despite the implicit apportionment of storage space, it is nevertheless the group as a whole who benefits from or suffers from the use of the show's entire space requirement at all times. It would be advantageous to have more flexibility than that. It would be advantageous to be able to allow users to aggregate their storage space in groups and then opt out user by user, with flexibility granted to each user when to opt out, rather than requiring the entire group to wait until they all recoup a show's used space at the same time. It would be useful to be able to explicitly apportion ownership, and loan amounts also, among members of a group.
We now describe an additional class of embodiments of PVRs according to the present invention, embodiments for recording shows for groups in which a show's storage space requirement is charged to group members rather than to a group as such. In such embodiments, with reference to the example data structures in
In other embodiments, two modes of operation are supported, one for charging space requirements to a group as such, another mode for charging space requirements to group members. In the first mode, the fields for charging space requirements to groups are utilized; in the second mode they are ignored. PVRs according to such embodiments can switch between the two modes of operation using a mode switch implemented, for example, in a Boolean field established for that purpose, such as, for example, the field GroupMode 2116 in the example group profile 2102 on
With reference to
The method includes also creating show records when shows are identified for preference recording 2154 on the basis of indications of member preference 2150.
Members are users, and users, as described in detail above, are supported by PVRs of the present invention in data entry of indications of user preference, including, for example, entry into user preference records 320 users' indications of preferred show titles 324 and preferred actors 326, as well as users' indications of the relative intensity with which such preferences are asserted, as, for example, in the preference level field at reference 328.
A show 240 to be recorded on behalf of a group 2102 has stored in its OwnerID field 244 the group ID of the group on whose behalf the show is to be recorded. In such embodiments, that group, rather than any individual user, is considered the owner of such a show.
In the method of
In the method of
In the method of
Further with regard to weighted coefficients of preference, we present this example for further explanation. In user preference records 320 for the show title "Dukes of Hazzard," Mom asserts a preference level of '3,' Dad asserts a preference level of '2,' Son asserts a preference level of '1,' and Daughter asserts no preference for "Dukes of Hazzard." The weighted coefficients of preference for the member respectively are 3/6, 2/6, 1/6, and 0/6, or, in terms of percentages, 50%, 33.33%, 16.67%, and 0%. The show's storage space requirement for an episode of "Dukes of Hazard" is 10 megabytes. The apportioned amount for each member respectively then is 5 megabytes, 3.3 megabytes, 1.67 megabytes, and 0 megabytes. In this example, the members' UsedSpace 204 is incremented and FreeSpace 206 is decremented in each member's user profile 202 respectively by 5 megabytes for Mom, 3.3 megabytes for Dad, 1.67 megabytes for Son, and 0 megabytes for Daughter. In this example, Daughter gets a free ride, which is reasonable in light of the fact that she expressed no preference for the show.
Despite their prior agreement to join a group, it is possible that members may wish to recoup their free space allocated to group storage of a show by opting out of the group's joint ownership of a show. A member may wish to opt out and therefore recoup storage for other uses, for example, when the member has viewed a show. A member may wish to opt out upon discovering that the group has recorded, and therefore apportioned part of a show's storage requirement to the member, a show in which the member has little interest. Remember the example just above in which the Son expressed a preference level of '1' for "Dukes of Hazzard." Upon learning that his group has recorded an episode of "Dukes of Hazzard," the Son might very well believe this his storage space might be better utilized elsewhere.
In our teachings thus far regarding personal video recording, there is no very easy way for a member to opt out of group ownership of a show. Consider, for example, the case of storage space apportionment according to the number of members in a group. We disclosed storing the group size in the NumberMembers field 2114 in a group profile 2102, shown on
The exemplary reapportionment record 2174 of
The exemplary reapportionment record 2174 provides a UserID field 280 storing a user ID of one of the member to whom the show's storage space requirement is to be reapportioned. The exemplary reapportionment record 2174 also provides a reapportionment amount field 282 storing the portion of the show's space requirement to be reapportioned to the member identified in the UserID field 280 of the reapportionment record 2174.
The method of
Reapportioning 2166 also includes creating 2168 reapportionment records 2174, one reapportionment record for each group member remaining after one opts out. Each reapportionment record 2174, as shown in
In the method of
In the method of
In the method of
We now describe an additional class of embodiments of PVRs according to the present invention, embodiments for recording shows for groups where, in addition to apportioning storage space requirements among members, loans of storage space are also apportioned among members. It is useful to note that a need for a loan can arise in at least two ways. One way a need for a loan can arise is when a deficit is discovered at the time of a user-scheduled or recording or in preference recording.
Another way a need for a loan can arise is when a member opts out of group ownership of a show. When a user opts out, the remaining members' apportioned amounts of the show's storage space requirement typically will increase. If one member's apportioned amount exceeds the member's free space, a deficit exists that requires borrowing if recording is to continue.
PVRs according to the embodiments under discussion charge group loan amounts by apportionment to group members rather than to a group as such. If a member opts out, then any outstanding group loan amount is reapportioned to the remaining members.
With reference to the exemplary data structures of
The LenderID field 232 in each member loan record stores a user ID of a member and therefore serves as a foreign key relating the member loan record to a user profile 202. From the point of view of the user profile 202, the member loan record looks like any other loan record, but it is in fact a little different. The LoanAmount 236 in the member loan record 230 represents an amount to be added to a member's BorrowedSpace 208 and subtracted from a member's FreeSpace 206, just like any other loan to a user. There is a difference, however, because the only actual loan in question is one which was authorized as a loan to the group, in a lending authorization record issued in favor of the group, not for any particular member of the group. The only loan involved here is a loan to a group. The LoanAmounts in the member loan records are apportionment amounts of a group loan, not actual loans to individual members.
Described in the paragraphs just preceding is one exemplary way to represent group loans in data structures. Another way would be to create a separate table for the header records, the group loan records. Many other data structures for representing group loans will occur to those of skill in the art and all such structures are well within the scope of the present invention.
The method of
The method of
The method of
In the method of
In the method of
In the method of
The method of
Cancelling the loan includes scanning through the loan records 230 for the show and, for the member identified in each member loan record, decrementing a member's BorrowedSpace 208 by the LoanAmount 236 for that member and incrementing a member's FreeSpace 206 by the LoanAmount 236 for that member. Cancelling the loan then includes deleting all the loan records 230 for the show, that is, all the loan records related to the show record through the ShowID field 241.
When a member opts out of responsibility for group ownership, not only must the storage space requirement be reapportioned (as described in detail above in this disclosure), but any existing loan amount must be reapportioned also.
There is no particular timing limitation on opting out. A member can opt out before or after a show is recorded, before or after a show is viewed or displayed. When a member opts out therefore, it is possible, in fact likely, that the members' free space quantities have changed since the related show record was created. The method of
If members' free space has changed so that no deficit currently exists, then the method of
If members' free space has not changed, so that a deficit still exists, of if members' free space has changed but nevertheless a deficit still exists, the method of
Reapportioning the loan amount includes reversing 2606 the current apportionment of the loan, deleting 2608 the member loan record of the member opting out, and recalculating the 2610 members' apportioned amounts of the loan.
Reversing 2606 the current apportionment of the loan includes scanning through the loan records 230 for the related show and, for the member identified in each member loan record, decrementing a member's BorrowedSpace 208 by the LoanAmount 236 for that member and incrementing a member's FreeSpace 206 by the LoanAmount 236 for that member. Then, because the method at this point is not canceling the loan entirely, only the member loan record for the member opting out is deleted 2608.
In the method of
In the method of
In the method of
In this specification so far, our discussion has assumed that, if a show's storage space requirement exceeds available free space and it is not possible find a lender so that storage space can be borrowed, then the show will not be recorded. See, for example, our discussion above regarding the method depicted in
See also, for example, our discussion above regarding the methods depicted in
It would be advantageous, however, if there were other ways to find or create additional free space, so that recording can continue over a broader range of circumstances and storage space can be used more efficiently. One way to proceed against this problem is to note that at any given moment, used space may store recorded shows portions of which have already been displayed to viewers. It would be useful to have ways of recovering such displayed storage space for current use in recording shows.
In the following discussion, we use the terms "displayed storage space" or "displayed space" to refer to the storage space upon which is recorded portions of shows that have already been displayed to viewers.
DisplayStartTime 2750 and DisplayStopTime 2752 record display start time and display stop time respectively for a display period for a show 240. The amount of used space that has been displayed for the show can be stored in DisplayedSpace 2766, or the amount of displayed space can be calculated on the fly as described in more detail below.
DisplayStartTime 2754 and DisplayStopTime 2756, in the viewing records 250, record display start time and display stop time respectively for a display period for a show identified in ShowID 252 for a particular user as identified in ViewerID 254. The amount of used space that has been displayed for the show to the user can be stored in DisplayedSpace 2764 or can be calculated on the fly as described below.
In the method of
Referring again to
Consider, for example, a thirty-minute show displayed at a frame rate of thirty frames per second having a display period of ten minutes. In this example show, there are 10 minutes�60 seconds/minutes�30 frames/second equals 18,000 displayed frames. That is, the displayed space for such a show can be represented as comprising the first 18,000 frames of the video file in which the show is recorded. If the show's storage space requirement is 60 megabytes, then the displayed space for the show can alternatively be represented as comprising one third of the show's storage space requirement or 20 megabytes of displayed space.
The PVR needs the frame rate for calculating displayed space in terms of video frames. PVRs according to some embodiments of the present invention store the frame rate 2766 for a show directly on the show record 240. Other embodiments treat frame rate as one factor in compression level 279 and store frame rates in tables keyed by compression level, such as, for example, the tables depicted in
In the method of
In all this opening, closing, and deleting of files, in PVRs according to many embodiments of the present invention, the application software in a PVR will need the shows' filenames for dealing with the PVR's operating system. Shows' filenames are stored, for example, in fields provided for that purpose, such as the one at reference 242 in show record 240 on
It is useful to consider in more detail the process of deleting displayed frames and excluding displayed frames from a stream to a new video file as these processes apply to discarding displayed frames. More particularly, it is useful to identify how to determine when to stop. That is, it is useful to have particular ways of determining in deleting displayed frames which is the last frame to be deleted, assuming the PVR takes as the first frame to be deleted the first frame in the video file. Similarly, with respect to excluding displayed frames from a steam to a new file, it is useful to be able to identify exactly which frame is to be the last frame excluded from the stream to the new file, assuming that the PVR begins exclusion with the first frame in the original video file. The answer as to which frame is the last frame depends on the video encoding of the video being worked upon, the file from which frames are to be deleted or the file from which frames are streamed to a new file.
MJPEG, for example, compresses only a single frame at a time, so-called intra-frame or spatial compression. Each MJPEG video frame is a complete picture in itself. Identifying a particular MJPEG frame as the last frame to be deleted or excluded a stream is straightforward: Count the number of frames identified by use of, for example, the method of
MPEG, on the other hand, is an inter-frame compression format that uses both spatial compression in each frame and temporal compression across frames. In MPEG, that is, several frames at once are considered while performing encoding operations.
A frame or picture can be of type I (3410), P (3412), or B (3414). An I-frame is an 'intracoded' frame, intracoded meaning coded only with reference to itself. I-frames are coded spatially with no reference to any other frame in the sequence. That is, I-frames are coded spatially but not temporally. I-frames can be decoded, or reconstructed for display, with no reference to other frames. Each I-frame is a complete picture ready for display on its own after decoding.
Starting with an I-frame, an MPEG encoder can forward predict a future frame. A forward-predicted frame is called a 'P-frame,' 'P' for 'predicted.' P-frames are predicted from I-frames and from other P-frames. P-frames are encoded both spatially and temporally. It is not possible to reconstruct or decode a P-frame without data from another frame. P-frames are forward predicted only, from the most recently preceding I-frame or P-frame.
B-frames are both forward predicted and backward predicted, 'B' for 'bidirectional.' B-frames are forward and backward predicted from the last and next I-frame or P-frame, therefore requiring two other frames to reconstruct each encoded B-frame.
As an example of the usage of I, P, and B-frames, consider the following sequence of six-frame GOPs: IBPBPB, IBPBPB, IBPBPB . . . The I-frames are coded spatially only and the P-frames are forward predicted based on previous I and P-frames. The B-frames are coded based on forward prediction from a previous I or P-frame, as well as backward prediction from a succeeding I or P frame. The example sequence is processed by the encoder so that the first B frame is predicted from the first I frame and first P frame; the second B frame is predicted from the second and third P frames; and the third B frame is predicted from the third P frame and the first I frame of the next group of pictures.
Note that the second B-frame in each GOP, in addition to depending on backward prediction from a next I-frame, also depends on forward prediction from a preceding P-frame which in turn depends on forward prediction from a preceding P-frame and a preceding I-frame. Because the P-frames and B-frames between I-frames depend, directly or indirectly, on forward prediction from a previous I-frame, cutting an MPEG sequence at a point in the sequence between I-frames renders useless the frames between the cut point and the next I-frame. Cuts for deleting displayed frames from MPEG video files and excluding displayed frames from MPEG streams in PVRs according to embodiments of the present invention, therefore, are usefully made at I-frames.
With reference to the methods of
In other words, if the last frame to be deleted or excluded is a P-frame or a B-frame, then PVRs processing MPEG video according to these embodiments can delete all the frames up to the next I frame. If the cut would then occur in the middle of GOP, requiring editing a GOP header, then PVRs can delete or exclude all the frames up to the beginning of the next GOP, including the GOP header for the current GOP. A typical MPEG block frame count is sixteen frames including one I-frame. On average, this method therefore would be expected to exclude about eight undisplayed frames comprising about a fourth of a second of video display, which is unlikely to be noticed by viewers.
An alternative for MPEG that is slightly more conservative and slightly more complex is to buffer GOPs, that is, buffering all the frames in each GOP one-by-one as each GOP is processed for deletion or exclusion. Then when a displayed frame count indicates a mid-GOP discard, the PVR can still include or stream out to the new video file the entire current GOP, including the displayed frames in the GOP as well as the undisplayed frames in the block, thereby deleting somewhat fewer than all the displayed frames, but conservatively preserving all the frames not yet displayed.
We discussed in this disclosure several ways of carrying out deletions and exclusions of displayed frames, particularly with reference to the exemplary encodings MJPEG and MPEG. Many ways of deleting or excluding displayed frames in these encodings and other encodings will occur to those of skill in the art, and all such ways are well within the scope of the present invention.
Above in this disclosure, we discussed various ways of making free space available for recording shows, including lending free space to other users or groups of users, repossessing loaned space, and recovery of displayed space. We discussed also the fact that compression levels affect storage space requirements and storage space usage. In light of that discussion, we note now that it would be useful also to be able, not only to calculate and reset storage space requirements in dependence upon compression levels, but also to affect compression levels as such. Having the capability of changing compression levels for shows already recorded or currently in the process of being recorded would add a useful alternative way of making free space available for recording.
We turn now to a discussion of further compression of shows. We speak of "further" compression because, as readers will realize from our earlier discussion of compression, all shows are compressed to some extent during delivery or capture and storage. Readers will also understand by now that in this discussion the term "show" includes show records that identify shows and store the shows' attributes, as well as the physically recorded video and audio content associated with particular shows. Although it is true that the physically recorded content can be stored in a variety of media including streams and temporary data structures in RAM, for ease of explanation, we generally speak in this disclosure of recording shows in files for storage in file systems on magnetic or optical media.
The need to make additional free space available for recording can arise in several ways. Additional free space is needed for scheduled recording and for preference recording when, for example, a show to be recorded for a user has a storage space requirement larger than the user's free space. Additional free space is needed for apportioning and reapportioning shows' storage space requirements among group members, when, for example, an apportioned amount of a storage space requirement exceeds a member's free space. Additional free space is needed for apportioning and reapportioning group loan amounts among group members, when, for example, an apportioned amount of a loan exceeds a member's free space.
In addition to the method of further compressing recorded shows, PVRs can implement also the method of
A further kind of embodiment, illustrated also in
The highest supported compression level, in this example context, is '20480:1.' 'Highest supported compression level' means the highest level for which a PVR has a codec capable of handling the show's present encoding as an input and producing a more compressed encoding of video as output. In this example context, such a 'highest supported compression level' is indicated in record 614 of table 602. As long as the show's original compression level is less than a highest supported compression level, the show is a candidate for further compression. In this example, as among several candidate shows, selecting a show for further compression includes selecting the first show among the candidates having an original compression level lower than a highest supported compression level in a particular PVR according to an embodiment of the present invention.
The method of
In the method of
Encoding parameters implement factors affecting compression level, including, as illustrated, for example, in
In addition, when changing encoding types, it may or may not be necessary to change codecs. At least some codecs that handle MPEG-2 also handle MPEG-1, for example. Our system block diagram in
The method of
Regarding changing compression levels, our discussion thus far has centered on changes for existing recorded shows. It would be useful also, however, to have ways of changing compression level during recording, if, for example, a need for additional free space is discovered during a check of an estimated storage space requirement. If there were at that time no other useful or desirable way of quickly freeing space for continuing recording, it would be useful to be able to increase compression 'on-the-fly,' so to speak.
More particularly, the codec operating parameters are changed so as to increase the compression level. Again with reference to
The method of
Alternatively, it is possible within the scope of the present invention to leave a single show fragmented among more than one video file, each video file having different encoding parameters. PVRs implementing this alternative then would need to expand the data structures representing shows (see
Among embodiments that leave a show fragmented among more than one video file, recording is simplified by reducing, or even eliminating, the need to further compress the first video file to the compression level of the second video file and concatenate the two files. On the other hand, decoding a show for display is easier if the show is encoded at record time into a single video file, because there is no need during playback to track and change video files, change codec parameters, or change codecs. In addition, further compressing the first video file at record time increases the amount of free space made available by changing to a higher compression level. Some increases in compression level, such as, for example, changes in audio quality, have no effect on video playback quality, although they may affect other aspects of playback. Nevertheless, leaving the show fragmented in more than one file having more than one compression level may affect display quality if the show is later replayed, changing display quality when playback changes from the first video file to the second video file, particularly when changes in resolution or frame rate were required in order to effect a particular increase in compression level.
The exemplary method of
We have now discussed in this disclosure several ways of further compressing or increasing compression of shows in PVRs. Many ways of further compressing or increasing compression of shows in PVRs will occur to those of skill in the art, and all such ways are well within the scope of the present invention.
It will be understood from the foregoing description that modifications and changes may be made in various embodiments of the present invention without departing from its true spirit. The descriptions in this specification are for purposes of illustration only and are not to be construed in a limiting sense. The scope of the present invention is limited only by the language of the following claims.
|Cited Patent
|Filing date
|Publication date
|Apr 12, 2002
|Aug 14, 2003
|Johnson Carolynn Rae
|Allocation of recording space per user and application
|Brown, Bruce; "TiVo PTV 100"; PC Magazine, Jun. 22, 1999; p. 60.
|Conley, Jim; The Future of TV is Here Ziff Davis Smart Business for the New Economy, Feb. 1, 2001, p. 152.
|White, Ron; 'How it Works: Personal TV'; PC/Computing, Nov. 1999; p. 272.
|Citing Patent
|Filing date
|Publication date
|Nov 18, 2003
|Mar 9, 2010
|Electronics And Telecommunications Research Institute
|Apparatus for controlling storage and playback of digital broadcasting contents
|Apr 2, 2004
|Jan 18, 2011
|Sony Corporation
|Data processing method, device thereof and program
|Jun 2, 2010
|Sep 25, 2012
|International Business Machines Corporation
|Replace content with like content to enhance program experience
|Mar 18, 2008
|Jan 29, 2013
|Google Inc.
|Personal video recorder with storage space loans
|Jun 29, 2007
|Mar 5, 2013
|International Business Machines Corporation
|Personal video recording with machine learning for messaging
|Nov 24, 2008
|Mar 12, 2013
|International Business Machines Corporation
|Personal video recording with storage space distributed among remote personal video recorders
|May 28, 2008
|Apr 2, 2013
|International Business Machines Corporation
|Personal video recording with machine learning for messaging
|Jun 25, 2002
|Apr 9, 2013
|International Business Machines Corporation
|Personal video recording with messaging
|Aug 14, 2007
|Oct 29, 2013
|Google Inc.
|Personal video recording with storage space requirement checking
|Jun 29, 2007
|Aug 26, 2014
|International Business Machines Corporation
|Personal video recording with storage space distributed among remote personal video recorders
|Jun 29, 2007
|Sep 30, 2014
|Google Inc.
|Personal video recording with further compression of recorded shows
|Jun 7, 2012
|Oct 14, 2014
|International Business Machines Corporation
|Replace content with like content to enhance program experience
|Jun 25, 2002
|Oct 21, 2014
|Google Inc.
|Personal video recording with apportioned loans of storage space
|Jun 29, 2007
|Jun 21, 2016
|International Business Machines Corporation
|Personal video recording with messaging
|Jun 25, 2002
|Dec 25, 2003
|International Business Machines Corporation
|Personal video recording with apportioned loans of storage space
|Jun 25, 2002
|Dec 25, 2003
|International Business Machines Corporation
|Personal video recording with messaging
|Nov 18, 2003
|May 27, 2004
|Seok Jong Won
|Apparatus for controlling storage and playback of digital broadcasting contents
|Nov 26, 2003
|Jun 10, 2004
|Jong-Won Seok
|Broadcasting server system for protecting and managing digital broadcasting contents and an operation method thereof
|Apr 21, 2004
|Oct 28, 2004
|Sony Corporation
|Data management method for recorded programs stored on a digital recording device
|Apr 2, 2004
|Oct 13, 2005
|Sony Corporation
|Data processing method, device thereof and program
|Aug 14, 2007
|Dec 6, 2007
|Boston Stephen B
|Personal Video Recording With Storage Space Requirement Checking
|Jun 29, 2007
|Dec 13, 2007
|Boston Stephen B
|Personal Video Recording With Messaging
|Jun 29, 2007
|Dec 13, 2007
|Boston Stephen B
|Personal Video Recording With Further Compression Of Recorded Shows
|Jun 29, 2007
|Jan 17, 2008
|Boston Stephen B
|Personal Video Recording With Storage Space Distributed Among Remote Personal Video Recorders
|Mar 25, 2008
|Jul 17, 2008
|International Business Machines Corporation
|Personal Video Recording With Pools And Groups
|Mar 18, 2008
|Sep 4, 2008
|International Business Machines Corporation
|Personal Video Recorder With Storage Space Loans
|May 28, 2008
|Sep 25, 2008
|International Business Machines Corporation
|Personal Video Recording With Machine Learning For Messaging
|Nov 24, 2008
|Mar 19, 2009
|International Business Machines Corporation
|Personal Video Recording With Storage Space Distributed Among Remote Personal Video Recorders
|Jun 2, 2010
|Dec 8, 2011
|International Business Machines Corporation
|Replace content with like content to enhance program experience
|Jun 17, 2014
|May 5, 2016
|Hanwha Techwin Co., Ltd.
|Method and apparatus for storing image
|U.S. Classification
|International Classification
|Cooperative Classification
|European Classification
|Jun 25, 2002
Owner name: INTERNATIONAL BUSINESS MACHINES CORPRATION, NEW YO
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BOSTON, STEPHEN B.;BLASCHKE, DAVID EARL;BROWN, MICHAEL WAYNE;AND OTHERS;SIGNING DATES FROM 20020619 TO 20020624;REEL/FRAME:013062/0878
|Oct 1, 2010
Owner name: GOOGLE INC., CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:INTERNATIONAL BUSINESS MACHINES CORPORATION;REEL/FRAME:025077/0868
Effective date: 20100930
|Oct 4, 2010
Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BOSTON, STEPHEN B.;BLASCHKE, DAVID EARL;BROWN, MICHAEL WAYNE;AND OTHERS;SIGNING DATES FROM 20020619 TO 20020624;REEL/FRAME:025084/0501
|Jan 24, 2011
|Fee payment
Year of fee payment: 4
|Jan 26, 2015
|Fee payment
Year of fee payment: 8


text: this is the first time im using a gamecube controller and im using it to play harvest moon:magical melody. my question is, when i use the L/R buttons, does it only work by pressing it all the way down until you hit the small button at the end? does the L/R button only function that way or does it also work with just light presses on other games. at first i thought the L/R buttons on my controller were broken because im pressing it lightly without clicking the button at the end and so it wouldn't work on the function in the game i want to use it for. sorry if it seems such a silly question but help would be appreciated.

subset: commoncrawl


text:
Do you know what latest trends of bridal dresses 2014 for Barat function are coming ahead inside the fashion market? Well we all know that each single year the trend of Barat dresses have been taking many changes and are simply taking away the attention of the fashion lovers. There is no doubt about the fact fashion designers play one of the major roles in letting the people know about the new trends of wedding dresses. Barat function dresses should be traditional and covered with the eastern concepts that let the bride feel elegant and versatile sophisticated for others.
Trends Of Bridal Dresses 2014 For Barat Function
According to the new trends, these days long shirts with lehengas are becoming one of the latest and favorite clothing trends for Barat function. In the past the bride used to favor choosing with the short shirts but now the trend has been complete changed. Barat bridal dresses are set with the high adornment of the embroidery along with the stone, motifs, dabka and work of zari patterns as well. In simple by the end of the day you will just going to find the dress that is heavy in terms of beautification. For the readers here we will going to allocate some of the lovely images of stunning trends of bridal dresses 2014 for barat function.
Moreover mentioning about the colors, then there are various form of color shades such as light as well as bold schemes that are found inside bridal dresses for Barat. Some of the common color shades are red, green, pink, white, blue and many more. You can learn more about the latest trends of dresses for Barat function by visiting fashion websites. If you are getting married very soon then stop thinking and start searching the brilliant bridal dress for Barat right now!


text:
x10ephem computes sunrise and sunset times. It consists of a library and an assortment of utilities. The most useful utility is x10events, which parses crontab files and updates the time fields to track sun events. Combined with an X10 interface like HEYU or X10, this allows the scheduling of lighting events to follow the changing seasons and daylight savings time automatically. This application does not depend on X10; it can be used for any crontab entry you like.
xtctl is a script for setting/changing xterm properties. It can change the foreground, background, cursor, and mouse colours of an XTerm window, and the icon and background image (only known to work with Eterm). xtctl can also modify the window's title, icon name, highlight background, font, size, position, z-order (raise and lower), and iconified/restored status. There are experimental options for full and soft reset.
Zsh is a UNIX command interpreter (shell) which of the standard shells most resembles the Korn shell (ksh). It includes enhancements of many types, notably in the command-line editor, options for customising its behaviour, filename globbing, features to make C-shell (csh) users feel more at home and extra features drawn from tcsh.
A SCXML to C++ compiler.
A survey tool.


text:
The Langoliers Trailer (1995)
"Prepare yourself for the flight of your life!" 14 May 1995 Drama, Horror, Thriller 180 mins
On a red eye flight from LA to Boston, 10 people wake up to a shock. All the passengers and crew have vanished. When they try to contact the ground they make no connections. They land the plane only to discover that things haven't changed. But its like the world is dead. No one is there, the air is still, sound doesn't echo, the food is tasteless. A distant sound is getting louder, something is coming closer.
Watch the official The Langoliers 1995 trailer in HD below or find more The Langoliers videos on Vidimovie.


text:
Its arched hull shape and waterline length have been designed to provide stability and predictable behavior.
The Edge 15 is easy to handle, requiring minimum effort to maintain a good cruising speed.
These characteristics are sure to appeal to the day or weekend paddler who love to go exploring in all weather and water conditions, without having the storing inconvenience of a 17 foot kayak.
Comes standard with a rudder system.
Length: 15'-0"
Width: 23.25"
Weight: 64 lbs
Capacity: 260 lbs
Cockpit Size: 17" X 32"
This kayak model was formerly known as the Boreal Design Sedna.
Collections: Day Touring Kayaks, Kayaks, Riot Kayaks, Riot Kayaks Edge Series Collection, Sea Kayaks
Type: Sea Kayaks
Vendor: Riot Kayaks
Sign up to get the latest on sales, new releases and more …
Grand River Kayak, 2 Port Maitland Road, Dunnville, ON, N1A 1Y3
© 2017 Grand River Kayak


text:
Yaounde — The main opposition party in the Republic of Congo, the Pan-African Union for Social Democracy (UPADS), has chosen Mr Pascal Tsaty-Mabiala as its candidate for the March presidential election.
Mr Tsaty-Mabiala is the UPADS first secretary.
"The national council has decided that UPADS will participate in the forthcoming presidential elections and that Mr Mabiala will be our coalition's candidate," the coalition said in a statement issued after an extraordinary session of the national council of the party in Brazzaville on Sunday.
Reports say Mr Tsaty-Mabiala has promised to focus on "national unity through values of solidarity and social justice; fight against poverty; protection of all Congolese people, observance of the impartial state authority and fight against all forms of injustice and nepotism".
He is currently serving as an MP of the UPADS party.
Mr Tsaty-Mabiala, 66, once served as Defence minister in the government of President Pascal Lissouba (1992-1997).
The leading opposition party boycotted the 2002 and 2009 presidential elections.


text:
RepairPal is your advocate for car care advice and guidance
Q: had dealer replace upper hose and less than 20 miles, overheats and now need on 2006 BMW 530i
a engine, is the dealer responsible, since they tested the system and now the engine is blown?
Was it out of coolant? Did you have any indication the engine was getting HOT? Maybe a gauge or a light warning you that something wasn't right? What happened to the orignial hose, did it blow out, leak or was it replaced as P.M.? Need more info.
the light came on an I open the hood and found coolant over the engine. towed to dealer, pick it up 2 days later, drove home and on my way back to town, all the lights came on, oil, then coolant, I pull over, tow it again, and oil was in the radiator. remove it from the dealer, had the coolant reservoir replaced and the oil back in the radiator, engine blow head gasket.. tech says replace engine
| |
depends on invoice and what is stated. were there any disclaimers in the note section
they did the battery cable connection campaign and changed the onupper radiator hose from coolant and replaced hose and bleed system charged $358.74 didn't drive car had 105825 In and 105826 out, I drove less than 20 miles. lights come on I stop tow it back and oil in the radiator, took it away had the coolant reservoir replace and oil still in radiator, head gasket blown, tech says replace engine
Didn't find what you were looking for?


text:
Mr. Todd E. Anderson
About Me
Award winning British designer, developing innovative branding and packaging solutions.
|Member Type
Todd Anderson is a multiple-award winning British designer, currently based in Cape Town. He has an extensive international career, developing innovative brand and packaging solutions with a variety of clients; partnering with some of the world's largest retailers, alongside nurturing smaller companies just starting out.
Winning the 'New Designer Award' launched his career, which commenced at Habitat, creating branding and packaging design. Later with Future Publishing, he played a significant role in the launch and rebranding of a number of longstanding technology magazines and then worked for Village Design agency on several national print and branding campaigns.
Employment as an art director with Somerset Creative commenced in 2002. There, alongside two other colleagues, Todd grew the design studio of the company that subsequently ranked 12th fastest growing UK company in the Sunday Times Fast Track Awards and won the prestigious Queen's Award. This role also allowed him to personally win a National Business Award for 'The Best Use of Technology' and become a finalist for 'The Orange Award for Bright Business.
2009 brought a creative directorship and relocation to Cape Town where design partnerships and great products and brands have been made with some of the worlds largest retailers. As part of The Cape Town Toiletry Company, he plays a client facing and design role across the span of brand and packaging design, product development, project management and print production.
Consequently Todd's portfolio illustrates a distinctive career. Clearly evident is his awareness of global trends together with a knowledge and understanding of brand strategy and consumer behaviour. His cutting-edge design aesthetics, solid typography, chromatic skills and acute eye for detail demonstrate an enthusiasm for design and general zest for life!


text:
iBall launched the iBall Slide Cuddle 4G. iBall Slide Cuddle 4G sports 17.65 cm (6.95") High Bright HD IPS full-capacitive Multi-Touch display.The iBall Slide Cuddle 4G has a unique Metallic Blue back. iBall Slide Cuddle 4G is with dual 4G SIM support.
SEE ALSO: Samsung Galaxy S7 front panels leaks, comparison with older Samsung Galaxy Flagship
The iBall Slide Cuddle 4G has a ARM Cortex A53 1.0 GHz Quad-core 64-bit processor to let users multi-task. The device has a 64-bit Quad Core processor and Mali - T720 Graphics core to enhance overall performance. The Slide Cuddle 4G has a powerful 2GB RAM and 16GB internal storage.
The iBall Slide Cuddle 4G has an 8MP Auto Focus Camera with LED Flash supported with 5MP rear Camera for Video Chatting and clicking selfies. The camera has several camera settings and functions especially like Panorama, Face beauty, Motion track mode, Live photo mode, Anti-Flicker.
SEE ALSO: India's mobile phone subscriber base crosses 1 billion mark
Connectivity options on the iBall Slide Cuddle 4G includes Wi-Fi Hotspot for internet sharing, Bluetooth V4.0, Bluetooth Tethering, Micro USB Port, USB OTG Function, USB Tethering and iBall OTA for online software update. It also has Light sensor, Gravity Sensor, Proximity sensor and Magnetic sensor for various applications.
The iBall Slide Cuddle 4G is a Dual SIM-supporting device that offers flexibility to use either normal SIM card as well as a Micro SIM. The Tablet PC has support for 21 Indian regional languages. The iBall Slide Cuddle 4G is available for Rs. 9,999.00


text:
BELLEVUE, WA, August 31, 2016 – Radiant Logistics, Inc. (NYSE MKT: RLGT), a third party logistics and multimodal transportation services company, today announced that Bohn Crain, the company's founder and chief executive officer, will participate at the Cowen and Company 9th Annual Global Transportation Conference to be held at The Boston Harbor Hotel in Boston, MA. Mr. Crain will be presenting on Wednesday, September 7, 2016, at 2:10 p.m. (EST) with one-on-one meetings held throughout the conference to discuss the Company's strategy for continued growth.
The Radiant presentation will be available for the public to access via the Investor Relations section of the Radiant corporate Website, www.radiantdelivers.com, or at http://wsw.com/webcast/cowen35/RLGT.
For more information about the conference or to schedule a one-on-one meeting with Radiant Logistics management, please contact your Cowen representative directly or the company at email@example.com.
About Radiant Logistics (NYSE MKT: RLGT)
Radiant Logistics, Inc. (www.radiantdelivers.com) is a comprehensive North American provider of third party logistics and multimodal transportation services delivering advanced supply chain solutions through a network of company-owned and strategic operating partner locations across North America. The company operates under the Radiant, Wheels, Airgroup, Adcom, Distribution By Air and Service By Air brands providing domestic and international freight forwarding services, truck and rail brokerage services and other value-added supply chain management services, including customs brokerage and materials management and distribution solutions to a diversified account base including manufacturers, distributors and retailers using a network of independent carriers and international agents positioned strategically around the world.


text:
Posted April 17th, 2006, 08:45 PM
Just wondering if ships are often late into ports of call. I'd like to book a non-Carnival excursion on my upcoming Sensation cruise. We are scheduled to get into port at 7:00 a.m. in Nassau and I would need to be to the Hilton Hotel by 8:30 to make the shuttle for the trip. This is an expensive all day excursion to the Exuma islands so I'd like to have a pretty good chance of making the shuttle. What do you think my odds are?


text:
Punjab Revenue Authority has been established under Punjab Revenue Authority Act. 2012 to collect and administer sales tax on services in terms of Punjab Sales Tax on Services Act, 2012. The Authority hereby invites applications from eligible candidates to fill the following positions on contract basis initially for a period of 3-year.
1. Application should be submitted on prescribed form to be downloaded from www.pra.puniab.gov.pk.
or can be directly collected from the officc of undersigned.
2. The complete CV. attested copies of relevant documents must be attached with the application form. Incomplete applications will not be entertained / considered.
3. Prescribed age limit and relaxation will be in accordance with existing Government policies and Instructions.
4. Posts will be subject to quotas if and when applicable.
5. Only short-listed candidates will be called for the interview.
6. Candidates presently working in Government / Semi-Government and autonomous bodies should apply through proper channel.
7. These appointments will be made on purely contract basis for a period of 3 – years (extendable on
8. The Applications must reach on or before 319' December. 2012 through post / courier. (By hand applications will not be entertained).
9. The Competent Authority reserves the right to decrease or increase the number of posts. 10. No TA/DA will paid to the Candidates for interview / test.
Babar Nawaz Raja
Additional Commissioner (HQs) Punjab Revenue Authority IPL-16054 5-B Danepur road, Lahore, praadcl @pra.punjab.gov.pk
Google keywords
- www pra punjab gov pk
- pra punjab gov pk
- www pra gov pk
- punjab revenue authority
- www pra punjab
- www pra punjab gov pk application form
- punjab revenue authority jobs
- www pra punjab pk
- www pra punjab gov pk jobs
- www pra punjab gov pk jobs form


text:
O2 is entering the financial services market with the launch of 'O2 money' and two prepaid debit cards in partnership with NatWest. The network will launch the free prepaid Visa cards, designed to give O2 customers 'better control of their money', by the end of August. The first, 'Cash Manager', is aimed at customers, particularly the student market, that want to control spending. Money can be transferred onto the card and used in shops, abroad and online. 'Load & Go' is aimed at the under 16s youth market and will be marketed as 'the replacement for pocket money'. It can be used online and on the high street, and to draw money from an ATM. Parents can load money onto the card online and it can not be used on over 18s products. Both cards provide real time text updates every time they are used. The company said the service is the start of a number of financial products that will see the convergence of phone and wallet. O2 has recently undertaken Near Field Communication (NFC) trials that could see mobiles used as Oyster or credit cards. O2 CEO Ronan Dunne said: 'O2 has a strong and successful track record of innovation and O2 Money will represent a launch pad into a wide range of mobile banking services. 'We believe that we are at the start of a journey towards the coming together of the phone and the wallet and we intend, through O2 money, to be at the forefront of this trend. 'This launch represents an important step towards O2 becoming a leading service provider with mobile at its core.'
Mobile Industry Awards 2017 - B2B & Distribution Finalists
Mobile Industry Awards 2017 – Retail Finalists announced
Mobile Industry Awards 2017 - Best Ruggedised Device
Nazish Dossa Joins Brighstar as UK Managing Director.
Get your FREE copy of Mobile's e-zine and stay up to speed on your PC, laptop or
Get your FREE e-zine
Huawei - 'Our 2017 focus is premium products'
Retail Special
S6 to re-ignite the market
Brightstar 20:20 and HTC join forces
Meeting the challenge of in-building coverage