US 20050240961 A1
Included is a method for an interactive media services system to provide a screen saver utility to a user through an interactive media services client device. The client device may be coupled to a programmable media services server device. The method may include the steps of providing a system operator with an interface to the programmable media services server; and providing control options within the interface to allow the system operator to dictate media to be presented in the screen saver utility, a plurality of parameters that result in activation of the screen saver utility, and a procedure to be followed in exiting the screen saver utility.
1. A method for an interactive media services system to provide a screen saver utility to a user through an interactive media services client device, said client device coupled to a programmable media services server device, said method comprising steps of:
providing a system operator with an interface to said programmable media services server; and
providing control options within said interface to allow said system operator to dictate media to be presented in the screen saver utility, a plurality of parameters that result in activation of the screen saver utility, and a procedure to be followed in exiting the screen saver utility.
2. The method of
3. A method for an interactive media services system to provide a screen saver utility to a user through an interactive media services client device, said client device coupled to a programmable media services server device, said method comprising steps of:
implementing said client device to present an interactive media guide; and
implementing said client device to activate a screen saver utility if said client device has presented a non-variant screen for longer than a plurality of configured parameters allow.
4. The method of
5. The method of
6. A method implemented by a server coupled to a television set-top terminal (“STT”) via a bi-directional communication network, the method comprising the steps of:
receiving a request from the STT for a motion video presentation;
establishing a dedicated network session between the server and the STT;
providing the motion video presentation to the STT via the established network session;
suspending the provision of the motion video presentation responsive to a first user input; and
providing a promotional motion video presentation to the STT responsive to the first user input.
7. The method of
8. The method of
9. The method of
10. The method of
11. The method of
12. The method of
13. The method of
14. A television set-top terminal (“STT”) coupled to a server via a bi-directional communication network, the STT comprising:
memory having program code stored therein; and
at least one processor that is programmed by the program code to enable the STT to:
request a motion video presentation;
establish a dedicated network session with the server;
provide the motion video presentation to a user via the established network session;
suspend the provision of the motion video presentation responsive to a first user input; and
provide a promotional motion video presentation to the user responsive to the first user input.
15. The STT of
16. The STT of
17. The STT of
18. The STT of
19. The STT of
20. The STT of
This application is a divisional of Application Ser. No. 09/590,434, filed June 9, 2000, which claims priority to Provisional Application No. 60/138,756 filed Jun. 11, 1999, both of which are entirely incorporated herein by reference.
This invention relates in general to television systems, and more particularly, to the field of media-on-demand.
Historically, television services have been comprised of analog broadcast audio and video signals. Cable television systems now receive broadcasts and retransmit them with other programming to users over land-line networks, typically comprising fiber optic cable and/or coaxial cable. With the recent advent of digital transmission technology, cable television systems are now capable of providing much more than the traditional analog broadcast video. In addition, two-way and advanced one-way communications between a subscriber and a cable system headend are now possible.
In implementing enhanced programming, the home communication terminal (“HCT”), otherwise known as the settop box, has become an important computing device for accessing video services and navigating a subscriber through a maze of services available. In addition to supporting traditional analog broadcast video functionality, digital HCTs (or “DHCTs”) now also support an increasing number of two-way digital services such as video-on-demand.
Each HCT or DHCT (collectively hereinafter “DHCT”) is typically connected to a cable or satellite television network. The DHCTs generally include hardware and software necessary to provide the functionality of the digital television system at the client's site. Preferably, some of the software executed by a DHCT is downloaded and/or updated via the cable television network. Each DHCT typically includes a processor, communication components and memory, and is connected to a television or other display device, such as a personal computer. While many conventional DHCTs are stand-alone devices that are externally connected to a television, a DHCT and/or its functionality may be integrated into a television or personal computer, as will be appreciated by those of ordinary skill in the art.
With the advent of media guide “browsers” for use in cable television systems, viewers (also referred to as “subscribers” or “users”) can scan programming information in a variety of methods. For specialized services such as on-demand video services, hundreds, or even thousands, of title options may be made available to the user for purchase and viewing. The service is not usable if the user is besieged with choices with no effective method for navigating and selecting a desired choice. For example, navigating a library of thousands of movie titles in a scrolling list alphabetically is very cumbersome.
A problem exists in providing a method to efficiently configure promotional information within the user interface provided to a user. A problem exists in providing a user promotional information to entice rental or purchase the media assets.
An additional problem exists in including advertisements in media guide browsers where the advertisements are not located at the cable television providers' transmitting location, but rather external thereto. With the advent of internet banner advertising, a need exists for a similar type of modular advertising that is easily update and may be tailor to an individual user or groups of users. A problem exists in configuring the media guides to enable third parties to seemlessly integrate advertisements without constant intervention and reconfiguration by the cable television provider.
The present disclosure includes embodiments of a method for an interactive media services system. One embodiment of the method can provide a screen saver utility to a user through an interactive media services client device, said client device coupled to a programmable media services server device. Additionally, the method includes the steps of: providing a system operator with an interface to the programmable media services server and providing control options within the interface to allow said system operator to dictate media to be presented in the screen saver utility, a plurality of parameters that result in activation of the screen saver utility, and a procedure to be followed in exiting the screen saver utility.
Also included in this disclosure are embodiments of a television set-top terminal ( “STT”). One embodiment of the STT is coupled to a server via a bidirectional communication network. The STT includes a memory having program code stored therein, and at least one processor. The processor is programmed by the program code to enable the STT to request a motion video presentation, establish a dedicated network session with the server, and provide the motion video presentation to a user via the established network session. Additionally, the processor can be programmed to suspend the provision of the motion video presentation responsive to a first user input and provide a promotional motion video presentation to the user responsive to the first user input.
Other systems, methods, features and/or advantages will be or may become apparent to one with skill in the art upon examination of the following drawings and detailed description. It is intended that all such additional systems, methods, features and/or advantages be included within the scope of the present invention and be protected by the accompanying claims.
The invention can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present invention. In the drawings, like reference numerals designate corresponding parts throughout the several views.
The DNCS 23 provides complete management, monitoring, and control of the network's elements and broadcast services provided to users. The DNCS 23 uses a data insertion multiplexor 29 and a data QAM 30 to insert the in-band BFS data into an MPEG-2 transport stream. The DNCS 23 also contains a Digital Storage Media-Cinnad-in-Control (DSM-CC) session and resource manager 34 that works with other components of the DNCS 23 in order to support the delivery of the MOD service to the user. The DSM-CC session and resource manager processes user to network (U-N) session signaling messages, manages allocation of session-related network resources and supports network management operations. The DSM-CC session manager 34 (
The MOD application server 19 communicates via the Ethernet connection 32 to a service application manager (SAM) server 25 contained on the DNCS 23. The SAM 25 provides a model in which the user can access services available on the system. A service consists of an application to run and a parameter, such as data content, specific to that service. The SAM handles the lifecycle of the applications on the system, including the definition, initiation, activation, suspension and deletion of services they provide and the downloading of the application into the DHCT 16. Many services can be defined using the same application component, with different parameters. The MOD application server 19 defines its application to the SAM server 25 and the SAM server 25 instructs a broadcast file system (BFS) server 28 to add the MOD application client executable code to the carousel (not shown) for distribution to the various DHCTs 16 in the network 18.
The BFS server 28 is a part of a broadcast file system that has a BFS client 43 (
The VOD content manager 21 and VOD content servers 22 deliver MPEG-2 content to a service group of QAM modulators that comprise service group number 24. The content manager 21 is responsible for managing the content on the VOD content servers 22. The MOD application server 19 utilizes the VOD content manager 21 and VOD content servers 22 to deliver the video and audio streams that make up the MOD services. The MOD application server 19 is also responsible for controlling the VOD content manager 21 and VOD content servers 22. The service group 24 is actually a multiplex of QAMs that illuminate a particular DHCT 16. A network session manager (not shown) in a DNCS 23 uses the service group 24 to determine which QAM modulator has access to a particular DHCT 16. The QAM modulators that comprise the service group 24 receive the MPEG-2 transport stream from the VOD content servers 22 and convert it to an RF signal at a specified frequency (channel). The QAM modulators of the service groups 24 are also responsible for encrypting the transport stream and inserting other data and information into the stream.
The QPSK modem 26 is responsible for transporting the out-of-band IP (internet protocol) datagram traffic between the distribution headend 11 and a DHCT 16. Data from the QPSK modem 26 is routed by headend router 27 within the headend 11. The headend router 27 is also responsible for delivering upstream application traffic to the various application servers 19, 20.
In one implementation, a memory portion 41 of the DHCT 16 includes flash memory 42 and dynamic random access memory (DRAM) 44 for storing the executable programs and related data components of various applications and modules for execution by the DHCT 16. Both the flash memory 41 and the DRAM memory 44 are coupled to the processor 35 for storing configuration data and operational parameters, such as commands that are recognized by the processor 35.
Basic functionality of the DHCT 16 is provided by an operating system 46 that is contained in flash memory 42. One or more programmed software applications, herein referred to as applications, are executed by utilizing the computing resources in the DHCT 16. The application executable program stored in flash memory 42 or DRAM 44 is executed by processor 35 (e.g., a central processing unit or digital signal processor) under the auspices of the operating system 46. Data input by the application program is stored in DRAM 44 or other source, either internal or external to the DHCT 16, or possibly anticipated by the application and thus created with the application program at the time it was generated as a software application program, in which case it is stored in flash memory 42. Data may be received via any of the communication ports of the DHCT 16, from the headend 11 via the DHCT's network interface (i.e., the QAM or out-of-band tuners) or as user input via receiver 39. A type of input data fulfills and serves the purpose of parameters as described below. Data generated by application program is stored in DRAM 44 by processor 35 during the course of application program execution.
The flash memory 42 also contains a platform library 48. The platform library 48 is a collection of functionality useful to applications, such as a Timer Manager, Compression Manager, Database Manager, Widget Toolkit, String Managers, and other utilities (not shown). These utilities are accessed by applications so that each application does not have to contain these utilities thus resulting in memory consumption savings and a consistent user interface.
The SAM, as discussed above, includes a SAM server 25 (
An application client is the portion of an application that executes on the DHCT 16 and provides the application's services to the user typically through a graphical user interface. Also contained in flash memory 42 is a navigator application 51 that provides a navigation framework for the user to access services available on the cable system. Examples of the services include, in one implementation, watching television and pay-per-view events, listening to digital music, and an interactive program guide, each of which is controlled through separate applications in flash memory 42. The navigator 51 also allows users to access various settings of the DHCT 16, including volume, parental control, VCR commands, etc.
Interactive program guide (IPG) 53, Watch TV 55, and pay-per-view (PPV) 57 are all resident applications in flash memory 42. The IPG 53 displays a program guide to the user and populates the guide with program data for selection. Watch TV 55 enables a user to simply “watch television” while PPV 57 enables other services to be organized into events and purchased as premium television services. These applications, because they are in flash memory 42, are always available to the user and do not need to be downloaded each time the DHCT 16 initializes.
The applications that are stored in the DRAM 44 may be applications that are loaded when the DHCT 16 initializes or are applications that are downloaded to the DHCT 16 upon a user-initiated command using an input device such as the remote 40. In this non-limiting example, as shown in
The applications shown in
The MOD application client 65 (
To provide the MOD service to the user, the MOD application client 65 interacts with the MOD application server 19 (
The first signal and scenario, as shown in step 71 in
The MOD application server 19 initialization scenario 79 (
The MOD application server 19 may also receive update messages from the DNCS 23 after the initial configuration 79 has been completed. The DNCS 23 periodically sends the configuration indication message 85, as show in
If the VOD content server 22 determines that it can deliver the service, it sends a ServerAddResourceRequest message 97 to the DNCS 23 to reserve the network resources to deliver that service. The DNCS 23 allocates the requested resources and sends to the VOD content server 22 a ServerAddResourceConfirm message 98 to indicate that the requested resources have been allocated. The VOD content server 22 then responds to the service session indication message 93 with a server setup response message 99 that indicates that the VOD content server 22 is ready to begin delivering the service using the resources allocated by the DNCS 23. VOD content server 22 session setup response message 99 may contain user data which is passed by the DNCS 23 to the DHCT 16. The DNCS 23 sends the ClientSessionSetupConfirm message 102 to the DHCT 16 that contains the resource descriptors (not shown) needed by the DHCT 16 to receive the requested service. This message 102 may contain the user data that was sent from the VOD content server 22. Finally, the DHCT 16 sends to the DNCS 23 a ClientConnectRequest message 104 indicating that the DHCT 16 is ready to receive the requested service, and the DNCS 23 sends the VOD content server 22 a connect indication message 105 indicating that the DHCT 16 is ready to receive that service.
The resource descriptors described above are used to define the resources which are allocated to a session. An interactive session has two resource “views”. VOD content server 22 defines the resources that are used to deliver the service from VOD content server 22 into the network 18. The MOD application client 65 defines resources that are used in order for the DHCT 16 to receive the service from the network 18.
The VOD content server 22 resource descriptor view is used when the server is delivering an MPEG program over a transport stream that is directly connected to the network 18 and does not require any signaling to set up the connection. The video on demand service architecture described above uses this type of connection.
For the MOD application server 19 resource descriptor view, two resource descriptors are used. The TSDownstreamBandwidth resource descriptor contains a transport stream ID field and a bandwidth field. The transport stream ID identifies the physical connection from the MOD application server 19 to the network 18. This transport stream ID is typically assigned by a network operator when a new connection is installed. The downstream bandwidth resource descriptor also identifies, in bits per second, the amount of bandwidth to deliver a service. This amount of bandwidth will be reserved in the network 18 for the duration of the MOD session with the DHCT 16 that requests the service.
The MPEG Program resource descriptor is another VOD content server 22 resource descriptor view. This resource descriptor identifies the MPEG Program that is carrying the service and used by the network to determine which program from the transport stream to route to the DHCT 16. The MPEG program also allows the application to assign association tags to each of the elementary streams in the program. These association tags may be used by the receiver to determine the use of each of the streams. The association tag is guaranteed to be maintained and to end in a session even if the MPEG program is remapped. The second resource view of an interactive session is the MOD application client 65 resource descriptor view. This view is used for all services that use MPEG to deliver the downstream data. The MOD service architecture defined above uses this type of connection for all downstream connections. The resource descriptor, “TSDownstreamBandwidth”, contains a transport stream ID field and a bandwidth field. The transport stream ID identifies the QAM modulator in service group 24 (
MPEG Program resource descriptor identifies the MPEG program that is carrying the service. This resource descriptor is used by the DHCT 16 to determine which program from a transport stream to decode. This descriptor also allows the MOD application client 65 to assign association tags (not shown) to each of the elementary streams in the program. These association tags may be used by the DHCT 16 to determine the use of each of the streams. The association tag is guaranteed to be maintained end-to-end in a session even if an MPEG program resource descriptor has been remapped.
Another signaling scenario supported by the present invention is the VOD content server 22 in-progress scenario.
The DNCS 23 periodically initiates a MOD application client session in progress request 114 as shown in scenario 113 in
The present invention permits the DHCT 16 to initiate a MOD session tear down scenario.
A session tear down scenario may also be initiated by the MOD application server.
A MOD session tear down scenario may also be initiated by the DNCS 23.
The VOD content server 22 provides an API by which the application servers can register interest in session setup and tear down events. Messages describing these events are sent to registered application servers and include the session ID and the user (application) data contained in the session setup request, such as the MAC address of the DHCT 16, the title ID, and the rental option in the case of the MOD application. In this way the MOD application server can be notified when a VOD session is established with the VOD content server 22 by the MOD application client 65. Additionally, the MOD application server 19 may use the API to request that the VOD content server 22 tear down the session if the user of the DHCT 16 is not authorized for the MOD service for billing reasons. The DHCT 16, the VOD content server 22, and the DNCS 23 may each initiate a session status scenario to determine the status of both the network and the other components described above.
The section described above is descriptive of one system for implementing the MOD service of the preferred embodiment of the present invention. The section below is descriptive of the MOD application client 65 user interface flow for navigating and executing other aspects of the MOD service.
An activate service event is then delivered to the MOD application client 65. Contained in the event is the is the parameter data defined for the service by the MOD application server 19 when it was provisioned by the system operator. The parameter includes the URL server 19, and other system operator configurable parameters such as the initial browse-by category to display the catalog screen, a trailer channel to tune upon activation, etc. as described in context below.
The first time the MOD application client 65 is activated, it connects to the MOD application server 19 and retrieve information about the user. The MOD application client opens a User Datagram Protocol (UDP) socket and sends the MOD application server 19 a request for current user information. The request includes a Media Access Control (MAC) address uniquely identifying the DHCT 16, and thus identifying the user. The MOD application server 19 then returns the requested user information, including but not limited to current rental information and user configuration information. This information has been stored in the MOD application server 19 database previously based on the MOD application client 65 creating VOD sessions and from commands from the MOD application client 65 over a UDP socket to store user configuration information. Both of these types of information are described in more detail in their relevant context below.
The MOD application client 65 then checks its internal state to determine if the user currently has any current rentals 193. If not, the MOD title catalog screen 197 (
Information about a MOD title highlighted in the current browse-by list 201 may optionally be presented to the user in the right portion 204 of the MOD title catalog screen 197. As a non-limiting example, a first option includes a still photo 204 a along with programming information 204 b related to a highlighted MOD title in the current browse by list 201. As the user navigates through different MOD titles, the still photo 204 a and the programming information 204 b change accordingly. As another non-limiting example, a second option for the right portion of the MOD title catalog display includes a long description 204 c that allows the user to obtain detailed information about the highlighted MOD title in the current browse by list 201. As still yet another non-limiting example, a third option includes presenting a streaming video portion in the location as described above for the still photo 204 a and program information 204 b similarly to option one described above. The streaming video may also be a reduced portion of a MOD title movie as a preview. The reduced portion of the MOD title may be any segment of the MOD title of length set by a system operator at headend 11. The video shown as a preview may either be the video of the title highlighted in the current browse-by list 201 or any other MOD title.
The button bar 209 at the bottom portion of the title catalog screen 197 includes options for the “A”, “B”, and “C” keys of remote unit 40 (
To present a preview of a MOD title in the reduced portion 204 a as described above, the actual MOD title MPEG content contained on the VOD content server 22 (
The MOD title catalog screen 197 (
A separate browse-by screen (not shown) allows the user to search the MOD title catalog for a desired MOD title. This embodiment includes a blank field where the DHCT 16 accepts user input for a specific MOD title to search. The search request is transferred from the DHCT 16 to the headend 11. Results of the search are returned to the DHCT 16 and are presented to the user.
The titles presented in the MOD title catalog screen 197 that are grouped in the various title categories are arranged by a system operator through an interface (not shown) at the headend 11. The interface is provided by the MOD application server 19 (
Whenever a catalog or title category is updated or created, the catalog manager of the MOD application server 19 generates and updates the catalog file(s) using the BFS server 28 (
Table I is a header file that is a pseudo-structure that describes the format of the MOD title catalog file as described above. Data types are indicated as follows: ui8=unsigned 8-bit integer; ui16=unsigned 16-bit integer; ui32=unsigned 32-bit integer.
Upon addition of a new MOD catalog or title category to the BFS server 28, the new files are immediately broadcast across the network 18 at intermittent intervals enabling the MOD application client 65 on each DHCT 16 to receive the updated information. To notify the MOD application client 65 that new catalog files are available, the MOD application server 19 uses the DSM-CC 34 on the DNCS 23 to send a UDP pass-thru message to the MOD application client via the operating system of the DHCT 16. Each MOD application client, upon determining that a new catalog or an updated version is available, uses the BFS client 43 (
Similarly, when new MOD titles are available for sale or release, a system operator adds the MOD titles to the MOD application server 19. The MOD application server 19 (
and installs the added MOD titles to the VOD content server 22 by transferring title ID and MOD title MPEG content. The VOD content manager 21 adds the MPEG content to the VOD content servers 22. The MPEG content for each newly added MOD title may include not only the video (or other media), but may also include MPEG data for a trailer for the MOD title that may be later included on a trailer channel or in the MOD title catalog screen 197 in portion 204 a as described above.
The system operator at the headend 11 may configure multiple MOD services to display different MOD title catalog screens 197; as mentioned previously each MOD service includes a URL for the catalog to be used by that service. The different services (and thus catalogs) may be constructed based on demographic information for different types of users according to geographic origin, ethnicity, age, gender, etc. provided such information is known about subscribers in the system. As part of the mapping of MOD services to channels provided by the SAM server 37, the operator may assign different MOD services with different catalogs to different geographic hubs in the television network. As a non-limiting example, the MOD title catalog screen 197 may predominately display MOD title categories tailored to Spanish programming, and these MOD title catalog screens 197 may be implemented in geographical areas where the interest in Spanish programming is high. Alternatively, the system operator can create a separate MOD service with a title catalog of adult content separate from the main library of titles. This adult MOD service may then be offered on a separate channel as a premium service to subscribers interested in that content. Thus, different MOD title catalog screens 197 are maintained at the headend 11 for presentation to users of varied interests.
Similarly, the MOD application client 65 on the DHCT 16 may be configured by the user to display MOD title categories in the MOD title catalog screen 197 according to interests for the individual user, if so configured by the system operator. As a non-limiting example, users with interests in sports programming may configure the DHCT 16 to display categories pertaining to sports programming in the MOD title catalog screen 197 as opposed to a regular configuration. When configured via the MOD application server GUI to operate in this mode, a single catalog contains all categories. Thus, the BFS client 43 at headend 11 would continuously broadcast all MOD title catalogs, but the DHCT 16 of the user with interest in sports programming would display the MOD title catalogs and MOD title categories pertaining to sports programming. The DHCT 16 may still download all MOD title categories so the user may still view MOD titles under those categories also, but separate action would be taken to display those categories. The list of categories desired for each individual user can be stored in non-volatile memory (NVM) (not shown) on the DHCT 16 if available. Preferably, the list of categories is transmitted over a UDP/IP socket to the MOD application server 19 by the MOD application client 65 using facilities of the digital television network 18. The MOD application client 65 then requests user information once after it is first initialized, as described previously. A settings graphical user interface offered by the MOD application client 65, if enabled by the system operator in the MOD service parameters, can be accessed by the user to set the list of categories that they desire be displayed. In navigating the MOD title catalog screen 197 to select a MOD title to purchase, the user may opt to preview a MOD title contained in the MOD title catalog screen 197. A preview of a MOD title enables the user to view a portion of the MOD title video stream substantially less than the entire title length. The preview may not necessarily start at the beginning of the MOD title, but rather may be any segment or segments of the MOD title. The portion of video contained in the preview may be configured by the system operator at the headend 11 through an interface (
An additional rental options that may be presented to the user in rental option screen 227 (
Still yet another rental option that may be purchased by the user from the rental option screen 227 (
As another rental option, the user may select to view a MOD title without any promotional advertising. As a non-limiting example, a user, upon selecting such an option, may view a MOD title without any movie trailers that are commonly shown in movie theaters prior to the feature presentation. As another non-limiting example, the MOD title may be presented to the user without any advertising logos, brands, or other marks that might otherwise be included in the presentation of the MOD title.
A MOD application server 19 graphical user interface (GUI) allows the system operator to define any number of rental options such as those mentioned above. Defined in the catalog is the information about each rental option: description, price, VOD stream control mechanisms enabled, trailers enabled, advertising enabled, etc. such that the MOD application client 65 can enforce the chosen rental option for a title. The system operator can assign via the GUI any number of rental options to a given title, including a default list of rental options that is assigned to a title when it is installed.
As still yet another rental option, the user may have the option to change the language setting of the purchased MOD title to one of any other available languages from the default setting. The MPEG data stream of the MOD title as delivered to the DHCT 16 may include two or more language audio tracks such that the DHCT 16 may be configured to play an alternately chosen language according to the preference of the user. As a non-limiting example, a French speaking user may configure the DHCT 16, by an interface (not shown) presented by the MOD application client 65 to present the purchased MOD title in French language audio as opposed to, for example, and English language default setting. Additionally, the DHCT 16 may, upon the user initially configuring the language, set the default for future presentations to the newly selected language. Alternatively, the MOD application client may access the language settings of the navigator 51 (
Once the user purchases a particular MOD title from the rental options screen 227 (
In another embodiment, the user may configure the MOD application client 65 through a graphical user interface menu (not shown) to block certain MOD titles grouped under certain themes. As a non-limiting example, a user may configure the DHCT 16 to block all MOD titles under an “Adult Programming” theme if such a theme was included in the browse-by category list 211 (
In yet another embodiment, the user may configure the MOD application client 65 to block rental of MOD titles according to some pre-set limits on media service. As a non-limiting example, the DHCT 16 may block presentation of MOD titles after a certain number of successful requests have been made in a given time period. Thus, a user may configure the DHCT 16 to allow five MOD title rentals in a month to control costs. In another non-limiting example, the user may limit the rental of MOD titles after a certain number of requests of a particular type of media has been ordered. Thus, the DHCT 16 may limit rental of all MOD titles after the user has ordered five premium-priced MOD title rentals. Additionally, the user, in another non-limiting example, may limit rental of all MOD titles after a specific monetary value has been expended in a given time period. Thus, the user may set a $50.00 per month for MOD title rental, and after that amount has been spent, the DHCT 16 blocks further rental attempts unless the user overrides the blocking process by entering the PIN. In each of these non-limiting examples, the user can override the block placed on the rental by entering a proper PIN as described above. All of this user-configured blocking information is stored in the MOD application server 19 database (not shown) as described for previous user configurations.
If the MOD application client 65 determines that the selected MOD title is not blocked by any of the aforementioned parameters, as in step 230 (
After the user has selected the desired MOD title for purchase, the MOD application client 65 causes the DHCT 16 to present the user an “please wait” message, as in step 250 (
If a session is available for transmitting the MOD title from the VOD content server 22 to the DHCT 16, the user is presented a help screen (actual help screen not shown) with the title purchased, as in step 257, prior to presenting the MOD title on display 31. This screen may include instructions about how the remote unit 40 (
In one embodiment, before the rented MOD title is actually presented to the user, promotional material may be presented to the user prior to the rented MOD title. Associated with a rental option may be a set of movie trailers, each with their own asset ID. The MOD application client 65 initiates a session for each of them with the specified VOD content server 22 (
In another embodiment, the DHCT 16 enables the user to reserve rental of a future MOD title presented as a trailer prior to the rented MOD title as described above. In this embodiment the reservation of future rentals would be made at a time when the MOD title to be rented in the future is not currently available. Thus, in a non-limiting example, the user, upon viewing a sequence of trailers of coming attraction MOD titles, may immediately reserve rental of one of the MOD titles shown in the trailer sequence for future viewing after the MOD title has been made available for rental. This advance rental provides the user priority for the time reserved for future viewing and insures that the system resources are available for at least fulfilling this rental request. Another non-limiting example enables the user to simply request notification of future release of a MOD title included in a sequence of trailers presented prior to the presentation of a rented MOD title. Thus, the user may receive a notification barker (not shown) instructing the user that the MOD title is now available for rental at the convenience of the user. In this non-limiting example, bandwidth is not reserved for the user at a given time, but instead, the user is prompted that a previously unavailable MOD title is now available for rental. Consequently, each reservation or request about a MOD title made by a user is communicated from the DHCT 16 to the headend 11 and stored in a memory (not shown). The future title reminders are transmitted to the MOD application server 19 by the MOD application client 65 via the UDP socket as described previously for other user customizations.
When the end of the MOD title is reached or the time allotted for viewing the MOD title has expired, the DHCT 16 presents the user with a message denoting that the rental period is over or that the MOD title has ended, as in step 260.
As an additional alternative, the user may prematurely end rental of the MOD title prior to expiration of the rental duration by stopping play of the MOD title and choosing an option to terminate the rental.
The MOD application client 65 may also present the user other barkers informing the user of other conditions prior to and during rental of a MOD title depending on specific situations that may occur. If, as a non-limiting example, a problem occurs during delivery of the MOD title to the DHCT 16 that causes an interruption in the service, a message may be presented to the user instructing the user of the problem.
If upon attempt to initially access the MOD channel, the system operator has defined a conditional access descriptor regulating access to the MOD service, and the navigator application 51 on the DHCT 16 determines that the conditional access package has not been transmitted to the DHCT 16, the navigator 51 will display an unauthorized barker 267 instead of activating the MOD service.
If during session setup the MOD application server 19 is notified of a VOD session setup for a particular title and rental option for which the user has been designated by the billing system used by the system operator as unauthorized, the MOD application server 19 will use an API of the VOD content server 22 with whom the session was created and ask that the session be tom-down because it is not authorized. When the MOD application client is notified that the session has been tom-down because the user is not authorized, the DHCT 16 may present the user a MOD rental not authorized barker 267 informing the user that the user is not authorized to receive MOD rentals and to contact the system operator.
Once the MOD application client 65 determines that the user has a current rental, it checks with the DNCS 23 to see if the session for that rental is active using the session status request described previously. If the session is active upon this determination in step 193, the MOD application client 65 causes the DHCT 16 to present the user a current rental screen. If the session is not active, another MOD session may be established. In a non-limiting example, the user is enabled to rent multiple MOD titles at a given time, in which case the session for the most recently viewed title would be established. In another non-limiting example, the user may be activating the MOD application client 65 at some time subsequent to a previous rental for completion of viewing of the previously rented MOD title. In another non-limiting example, the user may be re-activating the DHCT 16 and VOD application client 65 after a power outage that interrupted presentation of the previously purchased MOD title.
As discussed above and as shown in step 259 of
If the user enters depresses a key on remote 40 (
At any time in the presentation of the MOD title on the display 31, the user may stop the presentation of the video stream. Upon entry of a stop command on remote 40 (
Depressing a key on remote 40 (
If the user desires to pause the playing of the MOD title, a command on remote 40 (
Other inputs on the remote 40 (
If a still image is maintained on the display 31 for a pre-configured amount of time, the MOD application server 65 may invoke a screen saver function to protect the display 31 from a burn in effect that can occur if an image remains on a display too long. The still screen, as a non-limiting example, may be the current rental screen 227 as described above in regard to the stop and pause functions, or the still screen may be any other image that does not change with time. The system operator at the headend 11 may configure the MOD application to include a screen saver that may be activated after a set time has expired. The screen saver may comprise a sequence of still screens that may be advertisements, announcements or other information capable of display on a still screen. The sequence of still screens may be displayed in a rotation that enables each screen to be displayed for some configurable time period before the next still screen is displayed.
In another embodiment, the screen saver is presented as a video stream that, as a non-limiting example, is a set of movie trailers of movies currently available for rental in the MOD title catalog screen 197 (
In yet another embodiment, the screen saver may be configured by the system operator, through an interface on the MOD application server at the headend 11, to be some type of moving image. As a non-limiting example, the system operator may configure the MOD application to display a logo of the cable service provider to the user as the screen saver.
Because of the possible limited resources available for MOD title presentation (i.e., bandwidth, number of streams supported by MOD content server 21 (
In one embodiment, the user is informed by a display barker (not shown) at the beginning of the presentation session of the purchased MOD title of the time to finish the viewing of the MOD title. However, the user has full and free control of the VOD stream control mechanisms, as described above and in
Another embodiment is that the user is afforded full and free control of the VOD stream control mechanisms as described above and as shown in
Still another embodiment allows the user to utilize the VOD stream control mechanisms during a MOD period that is the calculated difference between the remaining rental duration and the remaining presentation length. While the MOD period is not equal to zero, the user is enabled to utilize all VOD stream control mechanisms as described above; however, when the MOD period does expire (become zero), the user is no longer enabled to use certain VOD stream control mechanisms unless the MOD period again becomes greater than zero. As a non-limiting example, if the MOD period expires, the rewind, stop and pause functions would no longer operate because otherwise the user would not be able to view the MOD title in its entirety because the remaining rental duration is insufficient. The user could still use the fast-forward function since this would operate to make the remaining rental duration greater than the remaining title length (i.e., a MOD period greater than zero). Thus, once the user fast-forwards the MOD title thereby making the MOD period greater than zero, the previously inoperative VOD stream control mechanisms (i.e., stop, rewind, and pause) would operate again.
If the user tunes to a channel other than the MOD channel that is presenting the purchased MOD title, or if the user powers off the DHCT, the stop mode is automatically entered . In one non-limiting example, if the MOD period does not expire before the returns to the MOD channel of the MOD title, presentation of the MOD title resumes where it was stopped. In another non-limiting example, if the MOD period does expire before the user returns to the MOD channel presenting the MOD title, the MOD title resumes streaming to the DHCT 16 even though the DHCT 16 is tuned to another channel and the user is alerted by a resume barker (not shown) of the MOD title presentation resumption. If, in another non-limiting example, the user returns after expiration of the MOD period, the presentation of the MOD title is resumed at the point in the MOD title such that the MOD title ends at the end of the rental duration thereby causing a middle portion of the MOD title to be unviewed by the user. Regardless of the different embodiments involving the MOD period, if the user returns to the MOD channel after the rental duration has expired, the MOD title catalog screen 197 is displayed and no portion of the MOD title is viewed.
Calculation of the MOD period, remaining title length, and rental period remaining are determined as follows. The MOD application client 65 stores in memory on the DHCT 16 the time at which the MOD title is purchased. It also stores the rental option, which includes the rental duration. Thus, at any time the MOD application client 65 can calculate the time remaining in the rental period.
The VOD content server 22 provides an API for the MOD application client 65 to request the normal play time (NPT) value of a video stream being played. Based on this information and the duration of the title (stored in the catalog), the MOD application client 65 can calculate at any given time the remaining title length. Alternatively, the MOD application client 65 can calculate the NPT based on the time of the last stream control operation and the rate at which the VOD content server is playing the stream.
The MOD application client 65 can then calculate at regular intervals such as once per minute the VOD period equal to the rental time remaining minus the remaining title length. During the rewind stream control operation, this calculation is done more frequently based on the rate of rewind that was specified to the VOD content server 22. In this case the MOD application client 65 can calculate the NPT based on NPT at initiation of rewind, rate of rewind, and duration of the rewind operation. This allows the MOD application client 65 to recomputed the VOD period at a constant interval of for example 60 NPT seconds. As a non-limiting example, if the rewind rate is 30 times the normal play rate the VOD period would be recalculated every 2 seconds (60 seconds divided by 30) to be effectively reevaluating the VOD period every 60 seconds of movie being streamed out of the VOD content server.
Alternatively, the MOD application client 65 can pre-compute the point in the stream during rewind that will cause the VOD period to drop below zero and request that the VOD content server 22 stop rewinding the stream at that point.
The system operator may configure, using the MOD application server GUI, parameters that determine when a session ends if the user interrupts the presentation of a MOD title. In one embodiment, the system operator may, via an interface (not shown), configure a session to be maintained for the entire rental duration even during the portion of the rental period when the user is not viewing the MOD title. This non-limiting example maintains the bandwidth for the user regardless of other system constraints or requests. In another embodiment, the system operator, through the interface at the headend 11, may configure the session providing the MOD title to be torn down after a pre-configured time. The pre-configured time may be based upon certain user input or some user inactivity. As a non-limiting example, if the user stops the presentation of a MOD title and the pre-configured time of inactivity expires, the session established to deliver the MOD title to the DHCT 16 of the user may be tom down as described above. When the user returns to the MOD channel the MOD application client 65 determines that there is a current rental but that no session exists. It then follows the steps described previously to set up a session with the VOD content server 22. If this session fails and the rental period is still active, the MOD application client 65 retries the session setup and different intervals based on the reason for the session setup failure. Additionally, a problem barker is displayed informing the user that the MOD service cannot be re-established and that the MOD application is retrying.
If DHCT 16 power is lost during MOD title viewing one of two scenarios may occur. First, for a power glitch whereby the DHCT 16 immediately reboots and the user subsequently tunes to the MOD channel, the session for the MOD title will still be playing. Thus, the MOD application client will discover from the MOD application server that the user has a current rental and will then verify with the VOD content server that the session is active. Hence, when the MPEG frequency and program information is retrieved from the DNCS 23 session and resource manager for that session, the stream will have been playing during the elapsed power outage time and the user will rewind the movie to view the portion they missed.
For a longer term power outage, the session and resource manager in the DNCS 23 will determine that the DHCT 16 is no longer responding to the session status request as described previously. The session will be torn down and the MOD application server 19 will be notified of the session tear-down and record the fact that there is no session for that user and title in the database. Then, when the DHCT 16 is powered-up and the MOD service activated, the MOD application client 65 will be told that no session currently exists for the current rental.
A system operator interface may enable the system operator to configure presentation of promotional information such as movie trailers or previews upon user requests for information about a MOD title. As described above in regard to
Additionally a system operator interface (not shown) for promotional information may enable a system operator to configure different areas of various screens, as described above, for example, the MOD title catalog screen 197. In one embodiment, the system operator can configure brand graphics to appear on the display screens mentioned above. Brand graphics may include graphics identifying the cable service provider. As a non-limiting example, a brand graphic 298 in
In similar fashion, the system operator may include advertising graphics (not shown) that are files placed on the BFS server 28 by the MOD application server 19, and are similarly accessed when a user activates the MOD application. Advertising graphics, as known in the art, refer to promotional information about an entity other than the cable television provider. Thus, in a non-limiting example, the advertising graphics may be graphics for merchants who purchased advertising through a particular cable television provider to have the merchants advertising graphics displayed whenever the user accessed the MOD application. In this example, the merchant could be a popcorn provider, and the graphic that appears in the MOD display screens (i.e. the MOD title catalog screen) could be an image of popped popcorn with descriptive text.
In an alternative embodiment, the advertising graphics that appear in the MOD screens may be provided by an external operator located at another physical location apart from headend 11. The system operator, in this embodiment, configures the MOD application, through the interface, to implement advertising graphics in the MOD display screens broadcast to the DHCTs 16 from the BFS 28 that are stored externally to the cable television system 10. As a non-limiting example, advertising graphics stored externally to the cable television system may be accessed by a universal resource locator (URL), for example, across the Internet for implementation in the MOD display screens. Thus, each time the MOD application client 65 attempts to retrieve an advertisement according to a pre-configured URL, a different advertisement graphic may be obtained from the external provider of the graphic so the user always sees different advertisements. In this embodiment, APIs (application programming interfaces) are provided to the external advertising graphic providers to enable compatibility with the MOD display screen configurations. Moreover, this embodiment enables advertisements to be quickly updated and tailored to the interests of an individual user or group of users.
A user may access the MOD application client 65, as described above, from a “trailer channel” if the user desires to purchase the MOD title corresponding to a particular trailer on the display. This configuration of the MOD service is indicated to the MOD application client 65 uses facilities of the operating system 46 to tune to the specified QAM frequency and MPEG program to display the trailers. The title ID about which trailer is currently playing is carried in an MPEG private data PID synchronous with the MPEG video and audio. The MOD application client 65, upon a user input initiated during a particular trailer presentation, would set the display 31 to the MOD title catalog screen 197 with the MOD title corresponding to the particular trailer highlighted. The user could then purchase that particular MOD title in a manner as described above.
As an alternative embodiment, the trailer channel may actually be a plurality of trailer-type channels configured according to style, genre, theme, etc. As a non-limiting embodiment, the MOD application server 19 may be configured to support a comedy trailer channel wherein all trailers advertise MOD titles that are comedies, a drama trailer channel for dramatic MOD titles, etc. Just as above, the user, upon viewing a trailer in any one of these trailer channels may, upon input by remote 40 (
The present invention describes the MOD application server 19 and client 65 as a system that delivers media to the user of the DHCT 16 where the media described is typically movies; however, it is not the intent to limit the present invention merely to a system that delivers video (i,e.movies) only. It should be clear that the MOD application may be implemented to deliver any type of visual and aural media to the user of the DHCT 16. As a non-limiting example, the headend 11 (
The MOD application, which comprises an ordered listing of executable instructions for implementing logical functions, can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. In the context of this document, a “computer-readable medium” can be any means that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer readable medium can be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. More specific examples (a nonexhaustive list) of the computer-readable medium would include the following: an electrical connection (electronic) having one or more wires, a portable computer diskette (magnetic), a random access memory (RAM) (electronic), a read-only memory (ROM) (electronic), an erasable programmable read-only memory (EPROM or Flash memory) (electronic), an optical fiber (optical), and a portable compact disc read-only memory (CDROM) (optical). Note that the computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via for instance optical scanning of the paper or other medium, then compiled, interpreted or otherwise processed in a suitable manner, and then stored in a computer memory.
The flow charts described above and shown in the figures of the present invention show the architecture, functionality, and operation of a possible implementation of the present invention. In this regard, each block represents a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that in some alternative implementations, the functions noted in the blocks may occur out of the order.
It should be emphasized that the above-described embodiments of the present invention, particularly, any “preferred embodiments” are merely possible examples of the implementations, merely setting forth for a clear understanding of the principles of the inventions. Any variations and modifications may be made to the above-described embodiments of the invention without departing substantially from the spirit of the principles of the invention. All such modifications and variations are intended to be included herein within the scope of the disclosure and present invention and protected by the following claims.