U.S. patent application number 11/234967 was filed with the patent office on 2006-02-02 for systems for user-selectable configuration of media transactions.
Invention is credited to Robert O. Banker, Arturo A. Rodriguez, John Eric West.
Application Number | 20060026080 11/234967 |
Document ID | / |
Family ID | 26909575 |
Filed Date | 2006-02-02 |
United States Patent
Application |
20060026080 |
Kind Code |
A1 |
Rodriguez; Arturo A. ; et
al. |
February 2, 2006 |
Systems for user-selectable configuration of media transactions
Abstract
In one embodiment of the present invention, a media service
system provides at least one transaction configuration option that
is enabled to be selected by a user. The media service system
implements a transaction process in response to a user
selection.
Inventors: |
Rodriguez; Arturo A.;
(Norcross, GA) ; Banker; Robert O.; (Cumming,
GA) ; West; John Eric; (Roswell, GA) |
Correspondence
Address: |
SCIENTIFIC-ATLANTA, INC.;INTELLECTUAL PROPERTY DEPARTMENT
5030 SUGARLOAF PARKWAY
LAWRENCEVILLE
GA
30044
US
|
Family ID: |
26909575 |
Appl. No.: |
11/234967 |
Filed: |
September 26, 2005 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
09894508 |
Jun 28, 2001 |
|
|
|
11234967 |
Sep 26, 2005 |
|
|
|
60214987 |
Jun 29, 2000 |
|
|
|
Current U.S.
Class: |
705/26.81 ;
348/E5.002; 348/E5.004; 348/E7.071 |
Current CPC
Class: |
G06Q 30/06 20130101;
H04N 21/4782 20130101; H04L 65/4007 20130101; H04N 21/6168
20130101; H04L 29/06 20130101; H04L 67/10 20130101; H04L 12/2801
20130101; H04N 21/2543 20130101; H04L 65/4084 20130101; H04N
21/25866 20130101; G06Q 30/0601 20130101; H04N 21/26266 20130101;
H04N 21/2347 20130101; H04N 21/8106 20130101; G06Q 30/0641
20130101; H04N 7/17318 20130101; G06Q 30/0635 20130101; H04N 21/482
20130101; H04N 21/241 20130101; H04N 21/23617 20130101; H04L
29/06027 20130101; H04N 21/6118 20130101; H04N 21/47202
20130101 |
Class at
Publication: |
705/026 |
International
Class: |
G06Q 30/00 20060101
G06Q030/00 |
Claims
1-39. (canceled)
40. A system for providing media services in a Subscriber
Television System (STS), the system comprising: a memory for
storing logic; a processor for executing the logic stored in
memory; logic configured to provide at least one transaction
configuration option; logic configured to enable at least one
selection by a user of the at least one transaction configuration
option; and logic configured to require an implementation of at
least one transaction process responsive to the selection of the at
least one transaction configuration option.
41. The system of claim 40, wherein the at least one transaction
configuration option is a single execution transaction option, and
wherein the implementation implements at least one transaction
process responsive to the selection of the single execution
transaction option to enable a subscriber to initiate and complete
an entire purchase in one execution.
42. The system of claim 41, wherein the one execution is the
depression of a remote button.
43. The system of claim 41, wherein the one execution is the
depression of a remote button, the remote button becoming active
only when a slide switch on an associated remote is in the active
position.
44. The system of claim 41, wherein the memory exists in a client
device and stores a subscriber record necessary to complete the
single execution transaction, and wherein the subscriber record
exists in a backup duplicate record on a STS headend device, the
backup duplicate record being used to refresh the memory in the
client device when the subscriber record is lost.
45. The system of claim 40, wherein the user is an
administrator.
46. The system of claim 45, wherein the at least one transaction
process is executed by at least one client device when a subscriber
utilizes the at least one client device to complete a purchase.
47. The system of claim 40, wherein the user is a subscriber.
48. The system of claim 47, wherein the enabling step is responsive
to at least one selection by an administrator.
49. The system of claim 40, wherein the at least one transaction
configuration option is a PIN option, and wherein the
implementation implements the transaction process responsive to at
least one selection of the PIN option requiring a correct PIN entry
to complete a transaction.
50. The system of claim 49, wherein the correct PIN entry enables a
single execution transaction, the single execution transaction
enabling a subscriber to initiate and complete an entire purchase
in one execution.
51. The system of claim 50, wherein the single execution
transaction is enabled for an active period.
52. The system of claim 51, wherein the active period exists until
the user deactivates the single execution transaction.
53. The system of claim 51, wherein the active period expires after
a time value, the time value comprising an amount configured by the
user.
54. The system of claim 40, wherein a portion of the system is
implemented in a STS headend device and enabled to communicate with
another portion implemented in a client device.
55. The system of claim 40, wherein the memory and the processor
exist in a client command device.
56. A Subscriber Television System (STS) client device in a media
service system, the STS client device comprising: a memory for
storing logic; a processor for executing the logic stored in
memory; logic configured to provide at least one transaction
configuration option; logic configured to enable at least one
selection by a user of the at least one transaction configuration
option; and logic configured to require an implementation of at
least one transaction process responsive to the selection of the at
least one transaction configuration option.
57. The STS client device of claim 56, wherein the at least one
transaction configuration option is a single execution transaction
option, and wherein the implementation implements the at least one
transaction process responsive to at least one selection of the
single execution transaction option to enable a subscriber to
initiate and complete an entire purchase in one execution.
58. The STS client device of claim 57, wherein the one execution is
the depression of a remote button.
59. A Subscriber Television System (STS) headend device in a media
service system, the STS headend device comprising: a memory for
storing logic; a processor for executing the logic stored in
memory; logic configured to provide at least one transaction
configuration option to a plurality of client devices; logic
configured to enable at least one selection by a user of the at
least one transaction configuration option; and logic configured to
require an implementation of at least one transaction process
responsive to the selection of the at least one transaction
configuration option a transmission link to enable the STS headend
device to communicate with a plurality of client devices.
60. The STS headend device of claim 59, wherein the at least one
transaction configuration option is a single execution transaction
option, and wherein the implementation implements the at least one
transaction process responsive to at least one selection of the
single execution transaction option to enable a subscriber to
initiate and complete an entire purchase in one execution.
61. The STS headend device of claim 60, wherein the one execution
is the depression of a remote button.
Description
CROSS-REFERENCE TO RELATED APPLICATION
[0001] This application claims priority to co-pending U.S.
provisional application Ser. No. 60/214,987, filed Jun. 29, 2000,
which is entirely incorporated herein by reference.
TECHNICAL FIELD
[0002] The present invention is generally related to television
systems, and, more particularly, to the field of transaction
options.
BACKGROUND OF THE INVENTION
[0003] Media service systems have awakened, through advancements in
transmission and communications technology, to provide subscribers
with a plethora of media content never before possible. Along with
the advent of a distribution of a wide variety of media content,
comes a wide range of choices for the subscriber. Many advanced
media service systems provide a programming guide to allow the
subscriber to acquire information about the subscriber's media
content choices.
[0004] A typical media service system involves a central headend
unit distributing a plurality of instances of media content over a
transmission system, usually a cable or satellite network, to a
multitude of client devices, such as a settop, as one example among
others. Each client device contains the necessary hardware and
software to interpret a transmission from the network and provide
that transmission to be presented by a presentation device, such as
a television, among other examples. The client device is also
enabled to accept commands from the subscriber regarding the
display of certain choices of media content. Certain choices by the
subscriber require the client device to communicate with the
central headend to request desired services.
[0005] One type of media content choice by a subscriber involves
renting a movie presentation. Many media service systems will allow
a subscriber to rent a movie presentation to be displayed at a time
provided by the system. The subscriber will view information
concerning a desired movie and then proceed to enter a buy
sequence. The buy sequence usually begins when the subscriber
indicates a desire to purchase a particular movie. Next, the client
device will enter a process by which the purchase is validated and
confirmed. In this process, the client device will usually require
the subscriber to confirm the purchase and enter authentication
information, such as a Personal Identification Number (PIN). The
client device may thus require the subscriber to complete multiple
confirmations to confirm that the movie presentation purchase is
truly desired before the purchase will be executed.
[0006] Although there may be a wide variety of various types of
media content available, the buy sequence for different types of
media content most often remains the same. Not only does the media
content vary greatly, but the characteristics and desires of the
subscribers using the system varies by an even greater degree.
Despite the wide range of variances in types of product, people,
and purchases, the sequence required to buy media content remains
unadaptable.
[0007] Thus, a heretofore unaddressed need exists in the industry
to address the aforementioned deficiencies and inadequacies.
SUMMARY OF THE INVENTION
[0008] In one embodiment of the present invention, a media service
system provides at least one transaction configuration option that
is enabled to be selected by a user. The media service system
implements a transaction process in response to a user
selection.
[0009] Other systems, methods, features, and advantages of the
present invention will be or 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 advantages be included within this
description, be within the scope of the present invention, and be
protected by the accompanying claims.
BRIEF DESCRIPTION OF THE DRAWINGS
[0010] The accompanying drawings, incorporated in and forming a
part of the specification, illustrate several aspects of the
preferred embodiments of the present invention, and together with
the description serve to explain the principles of the preferred
embodiments of the invention. The components in the drawings are
not necessarily to scale, emphasis instead being placed upon
clearly illustrating the principles of the preferred embodiments of
the present invention. Moreover, in the drawings, like reference
numerals designate corresponding parts throughout the several
views. The reference numbers in the drawings have at least three
digits with the two rightmost digits being reference numbers within
a figure. The digits to the left of those digits are the number of
the figure in which the item identified by the reference number
first appears. For example, an item with reference number 209 first
appears in FIG. 2. In the drawings:
[0011] FIG. 1 is a block diagram of a high level view of the
architecture of the media service system in accordance with one
preferred embodiment of the present invention.
[0012] FIG. 2 is a block diagram illustrating the headend of the
media service system of FIG. 1 in accordance with one preferred
embodiment of the present invention.
[0013] FIG. 3 is a block diagram illustrating the client device of
the media service system of FIG. 1 in accordance with one preferred
embodiment of the present invention.
[0014] FIG. 4 is a block diagram illustrating the client command
device of the media service system of FIG. 1 in accordance with one
preferred embodiment of the present invention.
[0015] FIG. 5 is a diagram depicting an example of a transaction
configuration options screen enabled by the transaction
configuration module of FIG. 1 in accordance with one preferred
embodiment of the present invention.
[0016] FIG. 6 is a diagram depicting an example of a first time
subscriber registration screen enabled by the transaction
configuration module of FIG. 1 in accordance with one preferred
embodiment of the present invention.
[0017] FIG. 7 is a diagram depicting an example of a purchase
options and reminder options screen enabled by the transaction
configuration module of FIG. 1 in accordance with one preferred
embodiment of the present invention.
[0018] FIG. 8 is a diagram depicting an example of a reminder
options screen enabled by the transaction configuration module of
FIG. 1 in accordance with one preferred embodiment of the present
invention.
[0019] FIG. 9 is a diagram depicting an example of a video on
demand transaction configuration options screen enabled by the
transaction configuration module of FIG. 1 in accordance with one
preferred embodiment of the present invention.
[0020] FIG. 10A is a diagram depicting an example of a PIN entry
screen enabled by the transaction configuration module of FIG. 1 in
accordance with one preferred embodiment of the present
invention.
[0021] FIG. 10B is a diagram depicting an example of a multiple PIN
entries screen enabled by the transaction configuration module of
FIG. 1 in accordance with one preferred embodiment of the present
invention.
[0022] FIG. 11 is a diagram depicting an example of a video on
demand screen illustrating a notification icon enabled by the
transaction configuration module of FIG. 1 in accordance with one
preferred embodiment of the present invention.
[0023] FIG. 12 is a diagram depicting an example of a video on
demand screen illustrating a notification barker enabled by the
transaction configuration module of FIG. 1 in accordance with one
preferred embodiment of the present invention.
[0024] FIG. 13 is a diagram depicting an example of a subscriber
profile setup screen enabled by the transaction configuration
module of FIG. 1 in accordance with one preferred embodiment of the
present invention.
[0025] FIG. 14 is a diagram depicting an example of administrative
configuration settings enabled by the administrative transaction
configuration module of FIG. 1 in accordance with one preferred
embodiment of the present invention.
[0026] FIG. 15 is a diagram depicting an example of administrator
user interface enabled by the administrative transaction
configuration module of FIG. 1 in accordance with one preferred
embodiment of the present invention.
[0027] FIG. 16 is a diagram depicting an example of a remote
subscriber user interface screen illustrating one implementation of
the subscriber user interface of FIG. 1 in accordance with one
preferred embodiment of the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
[0028] The preferred embodiment of the present invention provides
transaction configuration options to the users of a media service
system. An option will be understood to include an element, which
will provide a certain feature when selected. In a non-limiting
example, this feature could provide a benefit to the users of the
system or method described herein. A transaction will be understood
to mean the action that takes place during the purchase of an item
or a sequence of actions that take place during the purchase of an
item. A transaction configuration option is an option that
determines the action or sequence of actions that take place during
the purchase of an item. A transaction process is understood to
mean a process that transpires prior to the consummation of a
purchase and that is instantiated by a user exercising a step or
set of steps comprised in one or many transaction configuration
options that were selected to determine the action or actions that
take place during the purchase of an item. A user is understood to
be anyone who utilizes the system or method described herein and
can be, in accordance with various embodiments, an administrator or
a subscriber. An administrator is typically one who controls the
system or method described herein, such as, for example, a system
operator located at a system headend. A subscriber is typically a
customer or local user of a client device in the system or method
described herein. Selections are indications of choices made by a
user. A purchase refers to the act of buying an item, such as, for
example, an entity, media content, or event, the act of renting an
item for a period, and/or the act of gaining the right to view an
item for a period of time. The term media is used synonymously with
the term media content and is herein used to describe any type of
entertainment, news, event, etc. that can be presented to a
person.
[0029] Reference will now be made in detail to the description of
the preferred embodiments of the invention as illustrated in the
drawings. While the various embodiments of the invention will be
described in connection with these drawings, there is no intent to
limit it to the embodiment or embodiments disclosed therein. On the
contrary, the intent is to cover all alternatives, modifications,
and equivalents included within the spirit and scope of the
invention as defined by the appended claims. All examples,
embodiments, implementations, etc., are understood to be
non-limiting and among others.
[0030] FIG. 1 depicts the general architecture of a media service
system 110 in which a subscriber television system (STS) headend
120 provides media content over an STS transmission system 130 to
numerous client devices 140. Each client device, such as client
device 140A, interprets information received from the STS headend
120 via the STS transmission system 130 such that it can be
provided to the presentation system 150A and then presented to the
subscriber. The client command device 160A enables the subscriber
to provide commands to the client device 140A. With the client
command device 160 A, the subscriber can enter input to effect the
presentation that is to be displayed on the presentation system
150A.
[0031] The presentation system 150A can be any system that enables
a user to experience a session provided by the client device 140A.
The presentation system 150A can be, for example but not limited
to, a television, a computer monitor, a projection unit, or a
simulator providing visual and audible stimulation. The
presentation system 150A processes information from the client
device 140A. The presentation system 150A processes the information
such that it can be viewed, heard or otherwise presented to the
senses of the user. The user is able to perceive the information in
the subscriber user interface 180 through the use of the
presentation system 150A. Furthermore, the user can effect the
information in the subscriber user interface 180 to be presented by
the presentation system 150A by entering input with the client
command device 160A. The user is able to give commands to client
device 140A to interact with the transaction configuration module
100 with a client command device 160A. The client command device
160A can be any entity that relays user input to the client device
140A. Examples of the client command device 160A include, among
others, a remote control, a wired or wireless keyboard, a mouse,
and a voice command device. The commands given by the client
command device 160A dictate, among other things, the execution of
certain actions within the subscriber user interface 180. With the
use of the client command device 160A and the presentation system
150A, the user can experience and interact with the subscriber user
interface 180. In an alternate embodiment of the system depicted in
FIG. 1, the client device 140A and the presentation system 150A can
be implemented in the same device. In addition, the client command
device 160A could be incorporated into an entity containing the
client device 140A and/or the presentation system 150A.
[0032] The client command device 160A preferably allows the
subscriber to utilize the functionality of the client device 140A.
Using the client command device 160A, the subscriber can, among
other things, navigate and scroll through media content guides and
make selections. The media service system 110 enables the
subscriber to interact with the system with regard to particular
services. The media service system 110 provides programming that is
accessible with interactive user inputs such as, for example but
not limited to, broadcast pay-per view programming, and broadcast
near video on demand (NVOD). Furthermore, the media service system
110 provides on demand programming that is also accessible with
interactive user input such as, for example but not limited to,
video on demand (VOD), internet applications, and/or interactive
media guides (IMG). The subscriber may navigate different guides,
information, and programs in a subscriber user interface 180 to
gain information and to learn about available items. If the
subscriber discovers an item of interest that requires or allows a
purchase, then that subscriber may enter and complete a transaction
for purchasing the item of interest. This transaction may involve
one or more steps, execution of which is required to complete the
purchase of the item desired.
[0033] With access to varied applications, including access to the
internet, it is possible for a subscriber to complete purchases for
many kinds of goods and services in addition to media content
services. The discussion herein shall focus upon transactions for
media content purchases, but the scope of the present invention is
not limited thereto and extends to virtually all types of
purchases.
[0034] In one embodiment of the current invention, the transaction
configuration module 100 is enabled to configure transaction
processes. The term "user" is used herein with reference to this
embodiment to refer to administrators of the media service system
110, as well as subscribers of the media service system 110, and
the configuration can be performed by either. The transaction
configuration options module 100 is illustrated in FIG. 1 as an
entity within client device 140A. It should be clear to one of
ordinary skill in the art that the transaction configuration
options module 100 could be implemented in various ways. Examples
include, among others, an independent unit, a logic module within
the client command device 160A, a software logic module within the
STS headend 120, a module within the STS transmission system 130,
or a logic module within any device in the media service system
110. Furthermore, a distributive transaction configuration module
100 could be implemented in various ways such as, for example but
not limited to, part in the STS headend 120 and part in the client
device 140A.
[0035] In one embodiment of the present invention, the
administrator, or system operator, of the media service system 110
can determine what types of transaction options are provided to the
subscriber by controlling the media service system 110 through the
administrative transaction configuration module 170. In one
implementation of this embodiment, the administrative user
interface 170 provides the administrator with an interface from
which the administrator can select transaction configuration
options that configure the set of transaction configuration options
that are available to the subscriber through the transaction
configuration module 100. A transaction configuration option can
constitute the inclusion of a step or steps in the sequence of
steps required by a transaction process. Likewise, a transaction
configuration option can constitute an omission of a step or steps
in the sequence of steps required by a transaction process. In one
implementation, as shall be described in greater detail below, the
administrator can define certain transaction configuration options
to be available to designated regions of the network and even to a
particular one of the client devices 140.
[0036] In one implementation of this embodiment, the subscriber is
able to access the transaction configuration module 100 through the
subscriber user interface 180. Using the subscriber user interface
180, the subscriber may also determine the manner in which a
transaction is completed for one or more future purchases. In one
embodiment, the subscriber may enter selections with the client
command device 160A of certain transaction configuration options
made available by the administrator. By choosing among the options
made available to that particular client device by the
administrator, the subscriber determines the transaction process.
In one embodiment, the transaction configuration module 100 creates
a specified transaction process by implementing the options
selected by the subscriber. In this manner, when a particular
subscriber requests a certain type of item, then that subscriber
will be required to complete the specified transaction process in
order to purchase the chosen item.
[0037] In an example implementation, a global set of transaction
configuration options could be provided by the administrative
transaction configuration module 170 to the administrator. The
administrator could select a subset of transaction configuration
options, herein with reference to this implementation referred to
as a client set, from among the global set of transaction
configuration options. Thus, enabling only those transaction
configurations options in the client set to be presented to the
subscriber. Thereby, the subscriber could be provided with the
client set of transaction configuration options by the transaction
configuration module 100. The subscriber could then select the
desired transaction configuration options. In addition, the
subscriber can select to omit undesired transaction configuration
options. Those options selected by the subscriber would be
implemented as a transaction process. Therefore, the steps involved
in the transaction process thereafter could be determined by the
transaction configuration options selected by the subscriber. In a
non-limiting example, this transaction process would then be
executed by the client device 140A whenever the subscriber
indicates a desire to purchase an item. In another non-limiting
example, this transaction process might be associated with a
particular type of purchasable item, such as a movie. In this
example implementation, the subscriber would be required to
complete the steps of this movie transaction process to complete a
movie purchase.
[0038] In one embodiment of the invention, the administrator
pre-configures a plurality of transaction processes, each
transaction process comprising a respective set of steps required
to be conducted during a purchase by the subscriber. Alternatively,
the administrator can select a subset of transaction processes from
a global set provided by the administrative transaction
configuration module 170. Thereby, the subscriber selects one from
a plurality of pre-configured transaction processes to be
implemented as a transaction process for future transaction
purchases.
[0039] In an alternate embodiment, the subscriber is allowed to
deselect respective steps in a subscriber-selected pre-configured
transaction process. Certain steps of a pre-configured transaction
process may be de-selectable while others may not.
[0040] A first transaction process, be it either a
subscriber-selected pre-configured transaction process or a
subscriber-configured transaction process, may be configured to be
associated with a first type of media content service. Thereafter,
the first transaction process becomes active only during the
purchase of a first type of media content service. A second
transaction process may be configured to be associated with a
second type of media content service and thus becomes active only
during the purchase of a second type of media content service. A
third transaction process may be configured to be associated with a
plurality of types of media content services and thus becomes
active only during the purchase of any of the respective types of
media content services.
[0041] In one embodiment, the set of permissible associations
between types of media content services and transaction processes
that a subscriber can configure is designated a priori by the
administrator. The administrator either selects and enables a
plurality of types of media content services that can be associated
with each respective transaction process, and/or a plurality of
transaction processes that can be associated with each respective
media content service.
[0042] FIG. 2 depicts an implementation of the STS headend 120A in
accordance with one embodiment of the present invention. STS
headend 120A is configured to provide numerous functionalities to
the client devices 140 (FIG. 1). One of these functionalities is
the media service system 110 (FIG. 1). In a non-limiting example,
the media service system 110 (FIG. 1) is controlled from the
headend by a computer shown as the digital network control system
(DNCS) 213. The DNCS 213 includes an administrative transaction
configuration module 170 that is responsible for reserving and
configuring system resources needed to provide configuration and
service data to the transaction configuration module 100 (FIG. 1).
In an alternate implementation, the administrative transaction
configuration module 170 exists separate from the DNCS 213.
[0043] The DNCS 213 provides complete management, monitoring, and
control of the network's elements and broadcast services provided
to users. The DNCS 213 controls the content servers 211 that drive
the video & data pumps providing on demand media content to the
STS transmission system 130 as well as the infrastructure for
broadcast media services such as PPV and NVOD. In one
implementation, the DNCS 213 uses a data insertion multiplexer 212
and a data QAM 214 to insert in-band broadcast file system (BFS)
data in to a MPEG-2 transport stream that is broadcast over the STS
transmission system 130 to the client devices 140 (FIG. 1). The
content servers 211 house the video & data pumps which supply
media content to the client devices 140 (FIG. 1) through the QAM
group 215. The QPSK modem 217 can be utilized to transport the
out-of-band datagram traffic between the STS headend 120A and the
client devices 140 (FIG. 1). Through the use of the control and
management devices in the STS headend 120A, an administrator can
control the services provided by the system and more specifically
the media service system 110 (FIG. 1).
[0044] A service application manager (SAM) server 220 is a server
component of a client-server pair of components, with the client
component being located at the digital home communications terminal
(DHCT) 140A (FIG. 3). Together, the client-server SAM components
provide a system in which the user can access services, which are
identified by an application to run and a parameter, such as
particular data content, specific to that service. The
client-server SAM components also manage the life cycle of the
applications on the system, including the definition, activation,
and suspension of services they provide and the downloading of the
applications into the DHCT 140A (FIG. 3) as necessary. With the use
of SAM Server 220 and the client-server SAM components, a
subscriber's DHCT 140A (FIG. 3) is able to access services such as
NVOD, VOD, pay-per view, electronic program guides (EPG), digital
music, and media on demand (MOD).
[0045] Applications on both the STS headend 120A and the DHCT 140A
(FIG. 3) can access the data stored in a broadcast file system
(BFS) Server 219 in a similar manner to a file system found on
operating systems. The BFS server 219 is a part of a broadcast file
system that has a counterpart BFS client module in a DHCT 140A
(FIG. 3) connected to the STS transmission system 130. The BFS
server 219 repeatedly sends data for applications on a data
carousel over a period of time in cyclical repeated fashion so that
a DHCT 140A (FIG. 3) may read any particular data file or parts
thereof, and receive it and store it in memory 320 (FIG. 3).
Reception of such data may be a result of a subscriber request or
instigated by one or more application or internal processes in DHCT
140A (FIG. 3). Data, such as transaction configuration options and
transaction processes, is accessed from memory 320 (FIG. 3) and if
necessary converted to a displayable format for inclusion as a part
of the subscriber user interface 180 (FIG. 1).
[0046] The STS headend 120A depicted in FIG. 2 is merely provided
as an example implementation. The STS headend 120A could be
implemented in many other ways without many of the components
depicted in FIG. 2 and with many more additional components.
[0047] FIG. 3 is a diagram depicting an implementation of one of
the client devices 140 (FIG. 1) in accordance with one embodiment
of the current invention. The device depicted in FIG. 3 is DHCT
140A, a specific implementation of one of the client devices 140
(FIG. 1). The DHCT 140A is typically situated within a residence or
business of a user. It may be integrated into a device that has a
display unit, such as a television set, or it may be a stand-alone
unit that couples to an external display. The DHCT 140A includes a
processor 310 for controlling operations of the DHCT 140A, a video
output port such as an RF output system 364 for driving the
presentation system 150A, and tuner system 362 for tuning into a
particular television channel to be displayed for sending and
receiving various types of data from the STS headend 120A. The
tuner system 362 includes, in one implementation, an out-of-band
tuner for bi-directional Quadrature Phase Shift Keying (QPSK) data
communication and a Quadrature Amplitude Modulation (QAM) tuner for
receiving television signals. Additionally, DHCT 140A includes a
receiver for receiving externally generated information, such as
user input from a client command device 160A. In this
implementation shown in FIG. 3, the client command device 160A is a
remote control. Other types of client command devices such as a
keyboard, a mouse, or a voice command device may also provide the
user inputs. The DHCT 140A may also include one or more wireless or
wired communication interfaces, also called ports, for receiving
and/or transmitting data to other devices.
[0048] Memory 320, such as non-volatile (i.e., SRAM or FLASH
memory) and dynamic random access memory (DRAM), is coupled to the
processor 310 and stores operation parameters, such as commands
that are recognized by the processor 310. The most basic
functionality of the DHCT 140A is provided by an operating system
330 that operates in memory 320. One or more programmed software
applications, herein referred to as applications, are executed by
utilizing the computing resources in the DHCT 140A. The application
executable program stored in memory 320 is executed by processor
310 (e.g., a central processing unit or digital signal processor)
under the auspices of the operating system 330. Data required as
input by the application program is stored in memory 320 and read
by processor 310 from memory 320 as need be during the course of
application program execution. Input data may be data stored in
memory 320 by a secondary application or other source, either
internal or external to the DHCT 140A, or may have been created
with the application program at the time it was generated as a
software application program. Data may be received via any of the
communication ports of the DHCT 140A, from the STS headend 120A via
the DHCT's network interface (i.e., the QAM or out-of-band tuners)
or as user input via receiver 361. In a non-limiting example, data
in files that are broadcast from BFS server 219 can be received via
the QAM and/or out-of-band tuners. Data generated by an application
program is stored in memory 320 by processor 310 during the course
of application program execution.
[0049] In accordance with the embodiment depicted in FIG. 3, the
transaction configuration module 100 is responsible for executing
most functionality regarding the implementation of transaction
processes for the media service system 110 (FIG. 1) in relation to
DHCT 140A. The transaction configuration module 100 is enabled to
execute in accordance with the aforementioned interactions with,
among other things, the memory 320, the processor 310, and the
operating system 330. The requests made by the user via the client
command device 160A are interpreted by the receiver 361, stored in
memory 320, and assigned to the transaction configuration module
100 by the operating system 330. The transaction configuration
module 100 executes, on the processor 310, the commands provided by
the user in addition to those received through the communications
interface 363 provided by the STS headend 120A. In addition to the
received commands, the transaction configuration module 100 can
also require that certain application specific stored information
be executed by the processor 310. A non-limiting example is
illustrated by the transaction process 340 stored as part of the
configuration module 100. In one implementation, a transaction
process 340 is a transaction process that was implemented by the
transaction configuration module 100 based on selections by a
subscriber among available transaction configuration options.
Thereby, in this implementation the transaction process 340 could
be executed in processor 310 in the DHCT 140A when the subscriber
requested a purchase to be made. The DHCT 140A would require the
subscriber to satisfy the steps of the transaction process 340 to
fulfill the purchase. In other embodiments, there are no separate
transaction processes and transaction processes proceed as a
function of applications, such as, for example, video on demand.
The transaction process could be dictated by the STS headend 120 or
DHCT 140A as a bit setting in the memory sequence for an
application, such as, for example, video on demand. Thereby, the
specific transaction process could be, in one implementation, a
setting in the memory for the video on demand application to not
require a PIN entry. The transaction process could be other than a
process as commonly understood, thus the transaction process could
simply be a setting in an application.
[0050] The subscriber database 350 depicted in FIG. 3 can be
utilized to store information relating to the subscribers who use
the DHCT 140A. The subscriber database 350 depicted in FIG. 3
comprises of structured data such as a database, table of multiple
fields, or data organized in memory 320 for purposes of retaining
information pertinent to the transaction configuration module 100.
Herein, database will refer to a database, structured data, or
other data structures well known to those of ordinary skill in the
art. As a non-limiting example, subscriber database 350 includes
subscriber personal information, subscriber registration,
subscriber-selectable transaction configuration options,
subscriber-selectable transaction processes, and
subscriber-configured transaction processes, including associations
between transaction processes and types of media content services.
In one implementation, the subscriber database 350 is a designated
area in memory 320 in which the transaction configuration module
100 can direct the information gathered about the subscriber to be
stored for future use. In addition, the subscriber database 350
could further be utilized to store information concerning multiple
subscribers using the DHCT 140A. In one implementation, the
subscriber specific information could be employed for use in
conjunction with a subscriber login option. The subscriber login
option will be described in detail below.
[0051] In an example embodiment, the subscriber database 350
provides a designated area in memory 320 to store information
necessary to complete a single execution transaction. A single
execution transaction is one in which the user can initiate and
complete an entire transaction to purchase an item with one
execution. In a non-limiting example, when a subscriber finds a
item that the subscriber would like to purchase, the subscriber can
do so by executing a single step. Examples of this execution
include, among others, a click of a mouse, a keystroke, a
depression of a button on a remote, a tap of a touch screen, and a
voice command. In one embodiment, the single execution transaction
is made possible by accessing pre-stored information that is
important in completing a purchase and for billing purposes. In a
non-limiting example, the pre-stored information could be the
subscriber's name, address, and billing information. In one
implementation, this information could be stored in the subscriber
database 350 and accessed by the DHCT 140A when a subscriber
executes a single execution transaction. Alternatively, such
information could also be stored and accessed at the STS headend
120A since the subscriber already has a subscription with the STS
headend 120A provider.
[0052] The transaction configuration module 100 contains one or
more transaction processes configured and activated by one or more
subscribers that use DHCT 140A. In one embodiment, each stored
transaction process contains information as to which media content
service it is associated.
[0053] The DHCT 140A depicted in FIG. 3 is merely provided as an
example implementation of one of the client devices 140 (FIG. 1).
The client devices 140 (FIG. 1) could be implemented in many other
ways without many of the components depicted in FIG. 3 and with
many more additional components.
[0054] FIG. 4 is a diagram depicting an example of a client command
device 160A in accordance with one embodiment of the current
invention. Certain keys on the client command device 160A are
utilized in many implementations of the subscriber user interface
180 (FIG. 1). In one implementation, the navigation pad 420 allows
the subscriber to browse the subscriber user interface 180 (FIG.
1). In a non-limiting example, a free floating arrow, similar to a
conventional personal computer mouse pointer, could be displayed
and controlled by the navigation pad 420 on the client command
device 160A. In another example, the arrows on the navigation pad
420 could enable the subscriber to cycle through selectable
elements. In one implementation, pressing the right arrow on the
navigation pad 420 causes the next selectable element on the screen
to be highlighted or come into focus. When the element is shown as
highlighted or in focus, then that element is currently active. In
most implementations, the subscriber can perform a function on an
element when it is active. In one implementation, when the
subscriber strikes the select button 430 key, then the active
element is selected. The select button 430 can be used for a
variety of functions, examples including, among others, enabling a
certain transaction configuration option, disabling a certain
transaction configuration option, and maneuvering to different
screens in the interface. In addition to the select button 430,
there are other keys on the client command device 160A termed
function keys 440. The function keys are used, among other things,
for performing functions on non-highlighted elements. In one
implementation, the "C" button of the function keys 440 can be
pressed to exit from a particular screen.
[0055] A one button buy 410 key shown on the client command device
160A illustrates one implementation of a special key used in
conjunction with the transaction configuration module 100, though
not present in all embodiments of the present invention. In an
example embodiment, the one button buy 410 could be utilized by the
subscriber when completing a single execution transaction. As
mentioned above, the single execution transaction allows the user
to initiate and complete a desired purchase with one execution. In
the implementation depicted in FIG. 4, pressing the one button buy
410 key is the single execution of the single execution
transaction. In a non-limiting example, the subscriber could enable
single execution transactions through the use of the transaction
configuration module 100. Once enabled, the subscriber can search
for items to purchase and when a desired item is found, that
subscriber can purchase the item simply by pressing the one button
buy 410 key. In an alternate implementation, the one button buy 410
key could be enabled under limited circumstances, for example, in
association with the purchase of certain items, when a certain user
is logged in, or when the price of an item is below a set
value.
[0056] In alternate embodiment, one button buy 410 is not an actual
button but a slide switch on the right or left side of the top view
client command device 160A requiring activation with a push towards
the front or rear of client command device 160A. This slide switch
could be used, among other things, to avoid accidental presses.
[0057] In another embodiment, the client command device 160A is
implemented without the one button buy 410 key. In a non-limiting
example, the client command device 160A could be a standard TV
remote control.
[0058] In some of the discussion below, reference is made to
numerous diagrams depicting screen shots of the subscriber user
interface 180 (FIG. 1). These screen shots depict different
implementations of the subscriber user interface 180 (FIG. 1). The
screen shots do not represent a flow of configuration screens in
the subscriber user interface 180 (FIG. 1). The screens displayed
are independent implementations unless otherwise stated in the
description below, and these screens may be accessed in a variety
of ways, examples including, among others, from a general settings
menu or from within a particular application. In one
implementation, the subscriber could make a selection within a
particular application, such as video on demand, to go to a
transaction configuration screen.
[0059] It should be understood that when the title of a particular
subscriber user interface 180 (FIG. 1) screen is referenced, all
the elements in the screen or portion of the screen associated with
that title are being referenced. One of ordinary skill in the art
should recognize that the subscriber user interface 180 (FIG. 1)
could be implemented in a variety of different manners instead of
or in addition to those shown in the figures.
[0060] FIG. 5 is a diagram of subscriber user interface 180A, an
example implementation of subscriber user interface 180 (FIG. 1),
depicting a transaction configuration options 540 screen. This
implementation illustrates one manner in which the transaction
configuration module 100 may be configured. In one implementation,
the administrator can allow the subscribers in the system access to
only this option. Thereby, the administrator can dictate,
preferably through the administrative user interface 190 (FIG. 1),
that the transaction configuration module 100 (FIG. 1) enable this
screen of the subscriber user interface 180 (FIG. 1) to be
displayed when the subscriber accesses the subscriber user
interface 180 (FIG. 1), such as via a general settings menu or
other path. In an alternate implementation, the screen depicted in
FIG. 5 could be one of many presented to a subscriber upon
accessing the subscriber user interface 180 (FIG. 1).
[0061] The subscriber has two choices in the implementation shown
in FIG. 5. The subscriber can use the client command device 160A
(FIG. 4) to manipulate the up and down arrows on the navigation pad
420 (FIG. 4) to toggle between the two available selections. If the
subscriber highlights the disable single execution transaction 520
option and presses the select button 430 (FIG. 4), then the
subscriber will not be able to complete a purchase using a single
execution transaction. If the subscriber highlights the enable
single execution transaction 510 and presses the select button 430
(FIG. 4), then the subscriber will be able to complete a single
execution transaction and thereby initiate and complete an entire
purchase simply by executing one step. In FIG. 5, the enable single
execution transaction 510 option has been highlighted and selected,
thus the subscriber will have the ability to initiate and complete
a purchase in a single execution. In a non-limiting example, the
subscriber might desire to purchase a NVOD movie. If the enable
single execution transaction 510 option has been selected by the
subscriber to be implemented as that subscriber's transaction
process, then the subscriber would be able to merely press a single
button on the client command device 160A (FIG. 1) in order to
initiate and complete a NVOD movie purchase. In one implementation,
this button could be the one buy button 410 shown in FIG. 4. The
transaction process in this implementation involves one execution,
the pressing of a button on a remote. It is expressly noted that an
execution is an action instigated by a subscriber and should not be
confused with an execution by a device. The client device 140A
would not prompt the subscriber for any other actions, as it would
if the disable single execution transaction 520 option is selected,
such as a screen requesting confirmation of the desire to purchase,
the entering of a PIN and/or username info, etc. Instead, the
process would complete the purchase and would allow access to the
desired NVOD movie at the prescribed time.
[0062] A single execution transaction could be very advantageous to
certain types of customers. The transaction processes of the
systems in the prior art could prove quite tedious to a person
living in a single adult household. Prior art systems might require
an adult living alone to enter an authentication PIN and confirm
every purchase. The requirements exist despite the fact that they
are likely to be the only subscriber making such requests from the
client device 140A (FIG. 1) of that subscriber. In the embodiment
of the present invention illustrated in FIG. 5 and described above,
the single adult could configure the single adult's client device
140A (FIG. 1) to initiate and complete a purchase based on one
execution, a single execution transaction. In the environment of a
single adult home, the likelihood of an unauthorized person making
such purchases is quite remote. The ease of use for such customers
is a great advantage that comes with little or no risk of
unauthorized purchases. If any user, however, is unable to control
such functionality, the STS headend 120 (FIG. 1) can terminate this
functionality.
[0063] In an alternate embodiment, the screenshot depicted in FIG.
5 could be a transaction configuration options 540 screen for a
particular type of item of the various available items. In a
non-limiting example, a subscriber might select the enable single
execution transaction 510 option for video on demand movies. The
same subscriber might select the disable single execution
transaction 520 option for pay-per view events. This would allow
the subscriber to have quick and easy access to purchases of low
cost video on demand movies and more complicated and secure access
to purchases of higher cost pay-per view events. Therefore, in this
embodiment the selection of enabling or disabling a single
execution transaction would be associated with a particular type of
media content service, such as, for example, video on demand
[0064] FIG. 6 is a diagram of subscriber user interface 180B, an
example implementation of subscriber user interface 180 (FIG. 1),
depicting a first time subscriber registration 610 screen. In one
embodiment, this diagram illustrates a screen that would be
encountered by a subscriber after the first time that the
subscriber selects the enable single execution transaction 510
option in FIG. 5. In order for the media service system 110 to
process a request by the subscriber pursuant to one execution, the
system might require stored information about the subscriber. In a
non-limiting example, if the subscriber orders a movie, then the
media service system 110 (FIG. 1) may need to have the name of the
subscriber, the subscriber's address, and billing information such
as, for example, an account number. The screenshot in FIG. 6
illustrates a first time subscriber registration 610 screen. As
denoted in FIG. 6, subscriber user interface 180B is presented the
first time a subscriber enables a single execution transaction. The
subscriber user interface 180B enables the subscriber to enter
subscriber information, such as, for example, a name 620, address
630, and, if applicable, credit card 640. In one implementation, a
subscriber is given the choice to bill purchased media services to
the account of the subscriber or to charge them to a credit card of
the subscriber.
[0065] In one implementation, information entered by the subscriber
is stored in memory 320 (FIG. 3) and backed up at the STS headend
120 (FIG. 1). The copy stored at the STS headend 120 (FIG. 1)
serves to restore the information in the event of power outage to
client device 140A (FIG. 1). In an alternate implementation, this
information is stored at the client device 140A (FIG. 1) in
non-volatile read-write memory, either included as part of memory
320 (FIG. 3) or as separate independent memory, thus allowing for
recovery in the event of a power outage. An alternative is
presented when the client device 140A (FIG. 1) includes a connected
storage device, either internally or externally connected to the
client device 140A through a communication or peripheral port, to
store information entered by the subscriber. Regardless of where
the configuration information resides and where it is backed up,
the subscriber data is accessed in some implementations when a
single execution transaction is enabled. The subscriber data
acquired through the subscriber user interface 180 screen shown in
FIG. 6 enables the media service system 110 to initiate and
complete a purchase based on a single execution by the subscriber.
In a non-limiting example, when the subscriber presses the buy
button on the remote after selecting the enable single execution
transaction 510 (FIG. 5), the purchase can be completed without
requesting any additional input from the subscriber. In one
implementation, the subscriber could be required to enter the
information via subscriber user interface 180B only one time.
Thereby, the subscriber could enable the single execution
transaction option without reentering information. The transaction
configuration module 100 could pull the necessary information from
a record stored elsewhere in memory 320 (FIG. 3), non-volatile
memory, or a in a storage device connected to client device 140A
(FIG. 1). The subscriber would not have to enter the personal
information unless the subscriber desired to update that
information. In a non-limiting example, the administrator could
implement single execution transactions simply based upon the same
information used in providing standard service. Other embodiments
include never accessing such information or requiring it to be
entered by the subscriber, instead simply applying the purchase to
a subscriber record based upon other identification of the
subscriber.
[0066] FIG. 7 is a diagram of subscriber user interface 180C, an
example implementation of subscriber user interface 180 (FIG. 1),
depicting a purchase options 710 and reminder options 720 screen.
This implementation of the subscriber user interface 180C allows
the subscriber to choose from among available options under
purchase options 710 and options under reminder options 720. After
the subscriber chooses the desired options, the transaction
configuration module 100 can implement those chosen options to
create a transaction process or set of transaction processes.
[0067] In one implementation of this embodiment, the administrator
can designate in the administrative user interface 190 what options
are available to the subscriber, using an interface (not shown)
resembling that of FIG. 7, as would be understood by the reasonably
skilled. As illustrated in FIG. 7, the purchase options are grouped
into a scrolling window 730. The administrator can determine the
options that are seen by the subscriber in the scrolling window
730. As will be described further below, the administrator can
select from a set of possible options and decide which options are
to be made available. The same functions could be performed on the
set of reminder options 720 that are made available to the
subscriber.
[0068] When the subscriber enters the subscriber user interface
180C depicted in FIG. 7, that subscriber may choose those options
which best suit the subscriber's desires for a transaction process.
The first scrolling window 730 displays the available purchase
options 710. In one implementation, the purchase options 710
determine what takes place when a purchase is initially conducted,
and the reminder options 720 determine events subsequent to the
initial transaction and/or prior to the commencement of the
purchased item. As a non-limiting example, reminder options 720 are
useful when a subscriber purchases a media content service or item
to be received by the subscriber at a future time. The first of the
purchase options 710 is the PIN required 731 option. When the PIN
required 731 option is selected, the implemented transaction
process will include a PIN entry request. This PIN entry request
will prompt the subscriber for a secure set of numbers, characters,
or combination thereof. In a non-limiting example, the subscriber
could request a pizza to be delivered, and the media service system
110 would prompt the subscriber to enter an authentication PIN to
ensure that the subscriber is authorized for such activities. If
the PIN required 731 option is unselected, then it will not be
included in the transaction process implemented by the transaction
configuration module 100. This is true for many of the available
options in FIG. 7.
[0069] In an alternate embodiment, the PIN required 731 option
could be specific to a particular subscriber or specific level of
authorization. Thereby, the client device 140A (FIG. 1) would keep
track of more than one PIN for different subscribers and different
levels of authorization. In one implementation, a master PIN could
be assigned to an individual subscriber, such as, for example, the
head of the household. Another PIN could be a limited PIN assigned
to another individual subscriber, such as, for example, the child
in the family. Certain purchases could be placed using the limited
PIN and certain purchases would required the master PIN. In another
example implementation, a PIN could be used, not to authenticate a
purchase, but to authenticate a block of a purchase. A blocking PIN
could be enabled to block all or certain purchases made by the
client device 140A (FIG. 1).
[0070] When the subscriber selects the multiple PINs required 732
option, the transaction process will be implemented to include a
multiple PIN entry request. Upon making a request for purchase, the
subscriber will be required to enter multiple PINs before the
transaction process will proceed. Similar to the PIN required 731
option, this adds even more security to the transaction process.
The multiple PINs required 732 option enhances that security by
requiring that the subscriber be aware of at least two
authorization PINs. Entering multiple PINs may be frustrating to
some subscribers, especially those living at home. In this
embodiment, the number of PINs needed for the multiple PINs
required 732 option is configured by the administrator. In an
alternate embodiment, the administrator could configure a range for
the number of multiple PINs required and then allow the subscriber
to choose from that range. The multiple PINs required 732 option is
mutually exclusive with the PIN required 731 option, and this is
indicated by the crosshatching of multiple PINs required 732
option's activation button.
[0071] The subscriber login required 733 option adds a subscriber
login to the transaction process. If the subscriber selects this
option of the purchase options 710, then that subscriber will be
required to enter a subscriber login consisting of a user name and
password in order for a transaction process to proceed. As will be
discussed below, the subscriber login can be used for a variety of
different applications, such as authentication and subscriber
identification for subscriber specific services.
[0072] The confirmation screen required 734 option can be selected
by the subscriber when it is desired that a purchase request be
followed by a confirmation screen. Pursuant to selecting this
confirmation screen required 734 option, a transaction process
could include the presentation of a screen that prompts the
subscriber to confirm that the subscriber intends for a purchase to
be made and is aware that the transaction process is underway.
[0073] The notification icon displayed 735 option can be selected
by a subscriber to provide a notification when certain transaction
processes are activated by the transaction configuration module
100. In a non-limiting example, the subscriber might have chosen
the PIN required 731 option to be implemented as a transaction
process. Therefore, this subscriber might want a notifier to be
displayed by the Presentation System 150A to indicate that a
purchase can be completed by entering only one PIN. In an example
situation, the subscriber might be cognizant that other subscribers
in the household, although not authorized to make purchases, are
aware of this PIN. Thus, the subscriber would want to be notified
of the unauthorized subscriber's ability to complete purchases.
This notifier option shall be described in further detail
below.
[0074] The charge credit card 736 option can be selected by the
user to be implemented as part of the transaction process. When
activated, the charge credit card 736 option will stipulate the
billing method by which the purchase is processed. If selected,
then the associated charges could be billed to a credit card,
rather than the subscriber access bill, such as a cable TV bill as
one example.
[0075] The next section of options depicted in the screenshot of
FIG. 7, are the reminder options 720. These options pertain to
settings regarding reminders that are prompted by the media service
system 110 to be displayed to the subscriber. The reminder prior to
viewing 742 option will require the system to prompt the subscriber
with a reminder prior to the viewing of a purchased item. The
crosshatched filling in selection box 746 indicates to the
subscriber this reminder option may be selected to the exclusion of
selection box 745. The second reminder option depicted in FIG. 7 is
reminder requiring authentication PIN prior to viewing 743, and it
activates a reminder requiring a PIN entry by the subscriber. In an
non-limiting example, if the subscriber were to purchase a pay-per
view event two weeks in advance, then the system would prompt that
subscriber at some point, prior to viewing, with a reminder. That
reminder would require the subscriber to enter a PIN for
authentication purposes. If that PIN was not entered or entered
incorrectly, the transaction process may provide the subscriber a
subsequent chance to enter a PIN, or after exhausting one or few
additional chances to enter a PIN, the purchase may be abandoned
and the purchase may become void. Herein, an incorrect PIN entry
should be assumed to include the exhaustion of a number of
additional attempts to provide a subscriber a chance to enter a
correct PIN. More reminder options may be available to the
subscriber and can be accessed by scrolling down in the reminder
options 720 window 740.
[0076] FIG. 8 is a diagram of subscriber user interface 180D, an
example implementation of subscriber user interface 180 (FIG. 1),
depicting a reminder options 810 screen. This implementation of a
reminder options 810 screen differs from the one depicted in FIG. 7
and potentially could be associated with different implementations
of the media service system 110 (FIG. 1) or its applications. In
this implementation, the user, either the administrator or the
subscriber, is able to choose among available reminder options 810.
The reminder options 810 screen shown in this figure allows the
user to set five reminders. A reminder is activated by selecting
its associated activation button, such as reminder #1 820 and
activation button 850. If all are unselected, then no reminders
will be provided to the subscriber regarding a purchase. In an
example implementation, all reminders could be unselected when the
subscriber is presented with the reminder options 810 screen for
the first time. If the subscriber desired a reminder to be
activated, then that subscriber could select the activation button
associated with that reminder, such as activation button 850
associated with reminder #1 820. After enabling reminder #1 820 by
selecting activation button 850, the subscriber can further define
the reminder feature via the PIN required 830 field 831 and the
time prior to event 840 field 841. In a non-limited example, the
subscriber could dictate that reminder #1 820 have a PIN
requirement by selecting the 831 field and toggling the response to
YES. When the subscriber is subsequently prompted by the client
device 140A (FIG. 1) with a reminder about a purchase, then that
reminder will require the user to enter a PIN. If the subscriber
enters the correct PIN, then the purchase process continues. If the
PIN is incorrect, then the purchase may be voided and subscriber
may not receive the item desired. In addition to setting a PIN
requirement, the subscriber can also dictate or configure at what
time a reminder is shown relative to the start time of a media
content service or relative to the time that the purchase
transaction was completed. In a non-limiting example, the
subscriber can determine that reminder #1 820 require a reminder be
shown to the subscriber at the start of the viewing of the
requested media content, or in other words immediately prior to the
start of the requested media content. The subscriber can change the
time at which the reminder is shown by selecting the time prior to
event 840 field 841 that is associated with reminder #1 820. The
settings for time prior to event 840 range in this implementation
from "At Start" to "1 week". When a reminder is activated, it is
assigned a default value for time prior to event 840. In one
implementation, the administrator configures the default value and
the range of available settings for time prior to event 840.
[0077] The subscriber can set up to five reminders in the
implementation of the subscriber user interface 180C shown in FIG.
8. If the subscriber accepts the settings shown in FIG. 8, then
that subscriber would be prompted by the two reminders associated
with selected activation buttons 850 and 860. After requesting a
purchase, the client device 140A (FIG. 1) would prompt the user
with a reminder notice thirty minutes before the event, in
association with reminder #3 870, and this reminder notice would
require the subscriber to enter a PIN. Secondly, the client device
140A (FIG. 1) would prompt the subscriber with another reminder
notice, associated with reminder # 1 820, at the start of the
event, and this reminder notice would not require a PIN entry.
[0078] In one implementation the reminders activated in the
reminder options 810 screen could be associated with all purchases.
Therefore, a subscriber could be prompted with the activated
reminders whenever the subscriber purchased any kind of item. In
another implementation, the settings for reminder options 810 shown
in FIG. 8 could apply only to a specific purchase. In a non-limited
example, the reminder #1 850 and reminder #3 860 shown as activated
in FIG. 8, would be prompted to the subscriber when a
pre-determined item was purchased such as, for example, a NVOD,
VOD, or pay-per view event.
[0079] FIG. 9 is a diagram of subscriber user interface 180E, an
example implementation of subscriber user interface 180 (FIG. 1),
depicting a video on demand transaction configuration options 910
screen. This diagram depicts an interface where transaction
configuration options are defined in association with a specific
application within the media service system 110 (FIG. 1). FIG. 9 is
a depiction of an interface where a subscriber can choose among the
options shown in subscriber user interface 180E. It should be
apparent to one of ordinary skill in the art that the application
specific interface of FIG. 9 could similarly be provided for any
application in the media service system 110 (FIG. 1), not just
video on demand.
[0080] Use of the configuration tools in FIG. 9 allows the
subscriber to choose certain transaction configuration options for
video on demand purchases. Therefore, in one implementation the
transaction configuration options selected in the video on demand
transaction configuration options 910 screen can apply to all video
on demand purchases. The first set of transaction configuration
options presented to the subscriber in the video on demand
transaction configuration options 910 screen regards billing
preferences. The option selected by the user for billing 920 will
dictate the manner in which charges associated with video on demand
purchases will be billed to the subscriber. The transaction
configuration options provided in billing 920 are mutually
exclusive options. With mutually exclusive options, the OR 922
indicates that either the charge cable bill 924 option can be
selected or the charge credit card 925 option can be selected. Both
options may not be selected at the same time. Therefore, when the
subscriber selects the charge cable bill 924 selection box 921, the
charge credit card 925 selection box 923 will be shown as filled
with crosshatching as depicted in FIG. 9. The crosshatching shown
over the selection box 922 illustrates that the charge credit card
925 option has not been selected. If the subscriber desires for a
video on demand purchase to be billed to a credit card, then that
subscriber can select the 923 selection box. This new selection
would cause the charge cable bill 924 selection box 921 to be
filled with the crosshatching, indicating an unselected state.
[0081] The second set of transaction configuration options
presented to the subscriber in the video on demand transaction
configuration options 910 screen regards reminders. The reminders
930 area of the interface presents two transaction configuration
options to the subscriber. Unlike the billing 920 options, the
reminders 930 options are not mutually exclusive; therefore, both
options can be activated at the same time. The subscriber can
select the reminder at start 931 selection box 932 if it is desired
that a reminder be presented at the start of the event. Similarly,
the subscriber can select the reminder following purchase 933
selection box 934 to activate this reminder. Such a selection would
require a reminder to be shown to the subscriber immediately
following a video on demand purchase.
[0082] The third set of transaction configuration options presented
to the subscriber in the video on demand transaction configuration
options 910 screen regards request parameters. This set of
transaction configuration options illustrates a significant
advantage enabled by the transaction configuration module 100 (FIG.
1). By offering application specific transaction configuration
options, both the provider and the subscriber of the media service
system 110 can benefit from very specific transaction processes.
Transaction processes where the subscriber can configure the
subscriber's preferences in accordance with the options made
available by the administrator. The request parameters 940 options
are options that are specifically associated with video on demand
purchases. In one implementation, the administrator could offer a
cost savings to those subscribers who are willing to purchase a
video on demand and wait a period of time until traffic on the STS
transmission system 130 (FIG. 1) is reduced. The administrator
could provide this delayed session at a lower cost based on
bandwidth efficiencies, thus charge the subscriber a lower cost. In
one implementation, the subscriber could enable these cheaper
purchases by selecting the delayed session (economical) 943
selection box 944. If the subscriber was unwilling to accept such
delayed sessions, then that subscriber could mandate that all video
on demand purchases be immediate and without a potential discount.
This could be done by selecting the immediate session (premium) 941
selection box 942. The request parameters 940 options are mutually
exclusive such that one is selected at the exclusion of another.
The settings illustrated in FIG. 9 show the immediate session
(premium) 941 option as selected and the delayed session
(economical) 943 as unselected. The crosshatching filling selection
box 944 indicates that the delayed session (economical) 943 is
unselected.
[0083] In another embodiment, the request parameters 940 can also
include a threshold field for which a subscriber enters a dollar
amount that serves as a threshold for the maximum purchase price.
When invoking a transaction, such as a single execution
transaction, the subscriber's transaction process proceeds when the
intended purchase price is less than the threshold. In the event
that the purchase price exceeds the threshold, a barker is
displayed expressing that the threshold value has been exceeded and
subscriber input is requested to complete the purchase.
[0084] The fourth set of transaction configuration options
presented to the subscriber in the video on demand transaction
configuration options 910 screen regards general settings 950. The
general settings 950 transaction configuration options allow the
user to enable a subscriber login required 951 option and a
notification icon displayed 953 option. Both of these options can
be enabled at the same time. The subscriber will be required to
login to complete a video on demand purchase if the subscriber
login required 951 selection box 952 is selected. The subscriber
login option will be described in further detail below. If the
subscriber selects the notification icon displayed 953 selection
box 954, a notification icon will be provided to a subscriber
considering a video on demand purchase. The notification icon
option will be described in further detail below.
[0085] The fifth set of transaction configuration options presented
to the subscriber in the video on demand transaction configuration
options 910 screen regards PINs. As previously mentioned, the
subscriber is required to enter an authentication sequence of
number, characters, or combination thereof when a PIN option is
enabled. If the PIN is entered incorrectly then the purchase can be
voided. The options in the PINs 960 section are mutually exclusive.
The PIN required 961 option can be selected at the exclusion of the
multiple PINs required 963 option. If the PIN required 961 option
is selected, then the subscriber will have to enter one PIN to
complete a video on demand purchase. If the multiple PINs required
963 option is selected, then the subscriber will be required to
enter multiple authentication PINs to complete a video on demand
purchase. In one implementation, the administrator determines the
number of PINs required when the multiple PINs required 963 option
is selected. In another implementation, the subscriber could
subsequently configure the number of PINs required for the multiple
PINs required 963 option.
[0086] As previously described, a transaction process can be
implemented for all purchases or it can be implemented for specific
kinds of purchases. In an implementation involving the video on
demand transaction configuration options 910, a transaction process
is implemented specifically for VOD purchases. When the subscriber
accepts the selections shown in FIG. 9 for the video on demand
transaction configuration options 910, a transaction process is
then generated for VOD purchases. Given the selections shown in
FIG. 9, the transaction process could dictate that a VOD purchase
be billed to the cable bill, prompt the subscriber with a reminder
at the start of the VOD, accept only immediate VOD sessions, and
require the subscriber to enter a PIN when requesting the VOD
purchase. In one implementation, this transaction process could be
assigned to all subscribers purchasing VODs on a particular one of
the client devices 140 (FIG. 1). In another implementation, this
transaction process could be assigned to an individual subscriber
of one of the client devices 140 (FIG. 1) and be activated when
that subscriber logs in.
[0087] In an example embodiment, the subscriber can be enabled to
make the selections described above, in relation to the video on
demand transaction configuration options 910, through the use of
the client command device 160A (FIG. 1). In a manner previously
described, the subscriber user interface 180 (FIG. 1) could provide
a free floating arrow to select objects or could allow the
subscriber to press an arrow key to cycle through the selectable
objects.
[0088] FIG. 10A is a diagram of subscriber user interface 180F, an
example implementation of subscriber user interface 180 (FIG. 1),
depicting a PIN entry 1010 screen. In one embodiment, the screen
depicted in FIG. 10A could be presented to the subscriber when that
subscriber enabled a PIN entry option. In a non-limiting example,
the subscriber could select the activation button for the PIN
required 731 (FIG. 7) option supplied as one of the purchase
options 710 (FIG. 7) depicted in FIG. 7. If this was the first time
the subscriber had enabled the PIN required 731 (FIG. 7) option,
then the media service system 110 (FIG. 1) might have to establish
a secure PIN sequence. Thereby, the transaction configuration
module 100 (FIG. 1) could prompt the subscriber with the PIN Entry
1010 screen depicted in FIG. 10A. From the PIN Entry 1010 screen,
the subscriber could enter a 4 digit PIN 1020 made up of
characters, numbers, or a combination thereof. After entering the 4
digit PIN 1020, the subscriber could confirm the PIN by re-entering
it into the confirm PIN 1030 boxes. Once an acceptable 4 digit PIN
1020 was entered, the media service system 110 (FIG. 1) could store
the PIN in order to authenticate purchases in the future. In one
implementation, the media service system 110 (FIG. 1) could store
the PIN in memory 320 (FIG. 3) in the DHCT 140A (FIG. 3). In an
alternate implementation, the media service system (FIG. 1) could
store the PIN in the administrative transaction configuration
module 170 (FIG. 1) in the STS headend 120 (FIG. 1). In addition to
prompting the user with the PIN entry 1010 screen the first time a
PIN option is enabled, the media service system might also be
configured, by administrator or subscriber, to require a new PIN
entry 1010 screen to be presented every time the PIN entry option
is re-enabled.
[0089] FIG. 10B is a diagram of subscriber user interface 180G, an
example implementation of subscriber user interface 180 (FIG. 1),
depicting a multiple PIN entries 1040 screen. The multiple PIN
entries 1040 screen allows the subscriber to create the necessary
PINs when a multiple PIN entry has been enabled. In one example
implementation, the subscriber could enable the multiple PINs
required 963 (FIG. 9) option in the video on demand transaction
configuration options 910 (FIG. 9) interface screen depicted in
FIG. 9. To implement this option, the media service system 110
(FIG. 1) might need to acquire the PINs from the user through the
multiple PIN entries 1040 interface screen. When prompted with the
multiple PIN entries 1040 screen, the subscriber could enter the
desired authentication sequences into the prescribed areas for PIN
#1 1050, PIN #2 1060, and PIN #3 1070. Once the subscriber had
successfully entered the PINs into the appropriate areas, the
subscriber could store those PINs in the media service system 110
(FIG. 1) by selecting the "A" 1080 key. In one implementation this
"A" 1080 key could be one of the function keys 440 (FIG. 4) on
client command device 160A (FIG. 4). Furthermore, the subscriber
could use the client command device 160A (FIG. 4) select button 430
(FIG. 4) to activate the "SEL" 1090 icon and the navigation pad 420
(FIG. 4) to toggle between PINs for entry.
[0090] The methods of PIN entry depicted in FIGS. 10A and 10B are
provided as examples of different means by which the media service
system 110 (FIG. 1) can acquire a PIN from the subscriber. One of
ordinary skill in the art will recognize that many other methods
could be employed to implement a PIN option, examples including,
among others, providing an administrator configured PIN or
subscriber submission of a PIN via mail or fax.
[0091] FIG. 11 is a diagram of subscriber user interface 180H, an
example implementation of subscriber user interface 180 (FIG. 1),
depicting a video on demand 1120 screen. This implementation of the
subscriber user interface 180 (FIG. 1) illustrates an example
implementation of the notifier option provided by the media service
system 110 (FIG. 1). As previously mentioned, the media service
system 110 (FIG. 1) may provide to the subscriber a notifier option
such as the Notification Icon Displayed 736 option shown in FIG. 7.
The notifier option can be utilized to notify the subscriber of a
particular transaction process that is currently enabled.
[0092] In a non-limiting example, the subscriber may have enabled a
single execution transaction option. As previously described, a
single execution transaction allows the subscriber to initiate and
complete a purchase of an item by simply executing one action. This
option provides a powerful tool for the subscriber, but in some
instances, it may incur a risk of inadvertent purchases. To avoid
such inadvertent purchases, the subscriber may choose to enable a
notifier option. In one implementation, once the subscriber has
enabled a notifier option, a notification will be displayed to that
subscriber whenever a single execution transaction can be
completed. The video on demand 1110 screen demonstrates a
non-limiting example of the notifier option. It can be assumed for
this example that the subscriber has previously enabled single
execution transactions for VOD purchases. Thus, a notification icon
1100 is displayed when the subscriber is viewing the video on
demand 1110 purchase screen depicted in FIG. 1. In this video on
demand 1110 screen, the subscriber can browse through a list of
available movies 1120. In one implementation, the subscriber could
browse through the available movies by pressing the up and down
arrows on the navigation pad 420 (FIG. 4) on the client command
device 160A (FIG. 4). The subscriber could select a movie by
pressing the select button 430 (FIG. 4). The subscriber could watch
a preview of the movie in the video display area 1150 of FIG. 1 by
selecting the "A" 1160 key on the client command device 160A (FIG.
4). A selected movie, such as Traffic 1130, could be purchased by
the subscriber simply by pressing the one buy button 1140. The
notification icon 1100 warns the subscriber that a purchase can be
initiated and completed just by selecting the one buy button 1140.
Thereby, the subscriber will be warned of the ramifications of
selecting the one buy button 1140 whenever the subscriber sees an
encircled lighting bolt, the notification icon 1100.
[0093] It should be noted that one of ordinary skill in art would
recognize that a notification icon could be any type of icon used
to indicate not only single execution transactions, but also any
type of transaction process. In an alternate implementation, a
notification icon can be used to indicate that a PIN will be
required, a credit card will be charged, or a user login will be
required to complete a purchase.
[0094] FIG. 12 is a diagram of subscriber user interface 1801, an
example implementation of subscriber user interface 180 (FIG. 1),
depicting a notification barker 1200 screen. In this example
embodiment, the notifier option is not a notification icon but a
notification barker. For this example embodiment, it is assumed
that the subscriber has previously enabled a single execution
transaction option. The single execution transaction option can be
completed in the video on demand 1210 purchase interface screen by
selecting the one buy button 1220. In this implementation, the
subscriber is warned that single execution transactions are enabled
in the video on demand 1210 screen by the notification barker 1200.
This notification barker 1200 is a separate screen implemented by
the subscriber user interface 180I to be displayed upon entry into
the video on demand 1210 screen. The text area 1230 in the middle
of the notification barker 1200 specifies the particular warning
that is being supplied to the subscriber. The text area 1230 for
the notification barker 1200 depicted in FIG. 12 indicates to the
subscriber that single execution transactions have been enabled.
Thereby, the subscriber is made aware of the ramifications of
inadvertently selecting the one buy button 1220. In one
implementation, the subscriber can dismiss the notification barker
1200 by selecting the clear key, "C" 1240. In a non-limiting
example the "C" 1240 key is one of the function keys 440 (FIG. 4)
on the client command device 160A (FIG. 4).
[0095] In manner similar to the notification icon, the notification
barker 1200 can be used to indicate numerous enabled transaction
processes in addition to single execution transactions. In an
alternate implementation, the text area 1230 of the notification
barker 1200 could be used to described the transaction process
currently enabled by the media service system 110 (FIG. 1) for that
subscriber. In a non-limiting example, the transaction process
specifically associated with VOD purchases could be described in
the text area 1230 of the notification barker 1200. In this manner,
when the subscriber entered the video on demand 1210 purchase
screen, that subscriber might be aware of the requirements for
completing a VOD purchase.
[0096] FIG. 13 is a diagram of subscriber user interface 180J, an
example implementation of subscriber user interface 180 (FIG. 1),
depicting a subscriber profile setup 1300 screen. The subscriber
profile setup 1300 is utilized to enable a subscriber login option.
A subscriber login option allows a particular subscriber to login
to the media service system 110 (FIG. 1) such that features
individual to that subscriber may be enabled. In a non-limiting
example, a subscriber login may enable a transaction process or set
of transaction processes configured by an individual subscriber.
The aforementioned examples of transaction processes can be
associated with a particular subscriber login. The subscriber
profile setup 1300 enables the subscriber to initialize this
subscriber login option. A subscriber could be prompted by the
subscriber profile setup 1300 the first time that subscriber
enables a subscriber login option. The subscriber can enter a
desired user name in the corresponding user name 1310 box. In
addition, the subscriber can create a password 1320 for this user
name 1310 and confirm this password sequence in the confirm
password 1330 box. The subscriber logins created in the subscriber
profile setup 1300 can be used for individual subscribers or groups
of subscribers, such as the adults or the children in a
household.
[0097] The subscriber profile setup 1300 also enables the
subscriber to configure certain general settings to be associated
with the newly created subscriber login. In one implementation, the
transaction configuration options given here are general settings.
As mentioned above, the subscriber logins can enable specific
transaction processes or sets of transaction processes. In one
implementation, the transaction configuration options enabled under
the subscriber profile setup 1300 could be implemented as a default
transaction process. This default transaction process could be
activated whenever no other transaction processes were provided.
Therefore, if the subscriber enabled a different set of transaction
configuration options in another interface, then the subsequent
transaction process could override the default transaction process.
In addition, if the subscriber selects a certain set of options for
a particular kind of purchase, such as a VOD, then the associated
transaction process could be implemented instead of the default
transaction process for that particular kind of purchase.
[0098] The first transaction configuration option under the
subscriber profile setup 1300 is the enable single execution
transaction 1340 option. Selecting the option will enable a single
execution transaction as previously described in detail above. In
this implementation, the enable single execution transaction 1340
option is mutually exclusive with the respect to the other options
provided in the subscriber profile setup 1300 interface screen. The
OR 1343 depicted in FIG. 13 implies that the subscriber can select
either the enable single execution transaction 1340 option or any
other option provided. When the enable single execution transaction
1340 option is selected then the subscriber's default transaction
process, when logged in, can allow the purchase of an item with one
execution. The subscriber further has the ability to determine how
long the enable single execution transaction 1340 option is
activated. If the subscriber selects the until logout 1341 option,
then that subscriber will be allowed to purchase with single
execution transactions until that subscriber logs out of the media
service system 110 (FIG. 1). Alternatively, the subscriber can
select the until timeout 1342 option to allow single execution
transactions until a timeout period expires. In one implementation,
the timeout period is configurable by the administrator. In another
implementation, the timeout period is configurable by the
subscriber. The activation button for the until timeout 1342 option
is filled with crosshatching in FIG. 13 to indicate that it is a
mutually exclusive option with respect to the until logout 1341
option and is therefore unselected. In other embodiments, the
period of activation can be implemented to depend on numerous other
parameters besides a logout or timeout, examples including, among
others, the activation of another transaction process, the
completion of a certain number of purchases, and exiting from a
particular application. In a non-limiting example, the enable
single execution transaction 1340 option may be configured to
activate when the subscriber enters the VOD purchase interface and
deactivate when that subscriber exits the VOD purchase interface.
This might prove advantageous when the subscriber wants to logon to
the VOD purchase interface, make numerous single execution
transactions for the different VOD items, and then logout.
[0099] In one embodiment, the period of activation for the enable
single execution transaction 1340 option can be extended by the
subscriber prior to expiration by entering additional information
causing an activation period extension. As a non-limiting example,
the user may enter a PIN or a password upon the request of an
extension to the activation period with a remote key or by a
selection within the subscriber user interface 180 (FIG. 1).
Alternatively, after the expiration of the activation period, the
subscriber may be queried to enter a PIN or password to extend the
single execution transaction period.
[0100] The second option provided is the charge credit card 1350
option. The subscriber can select this option if that subscriber
desires their purchases to be billed to a credit card. The third
option, display notification icon 1360, enables the notifier option
as previously described in detail above. In one implementation, the
selection of the display notification icon could cause a notifier
icon, similar to the one depicted in FIG. 11, to be displayed by
the subscriber user interface 180 (FIG. 1) when a specific
transaction process is enabled. The subscriber can select the
reminder prior to event 1370 option if that subscriber desires this
to be a step in the default transaction process. Furthermore, the
subscriber can select the reminder requires a PIN 1380 option if
the subscriber desires for an authentication PIN to be required as
part of a reminder to complete a purchase. It should be clear to
one of ordinary skill in the art that the transaction configuration
options shown in the subscriber profile setup 1300 could contain
numerous other options not depicted.
[0101] FIG. 14 is a diagram depicting a graphical tree model as a
non-limiting example of administrative configuration settings
provided by the administrative transaction configuration module 170
(FIG. 1). As previously described, the administrator of the media
service system can configure the transaction configuration options
that are available to the subscriber. The administrator is enabled
to perform this task through the use of administrative user
interface 190 (FIG. 1) and thereby the administrative transaction
configuration module 170 (FIG. 1). The administrative configuration
settings depicted in FIG. 14, 1410, 1420, and 1430, are graphical
representations of data stored in the administrative transaction
configuration module 170 (FIG. 1). The administrative user
interface allows the administrator to either make the options
available for configuration by the subscriber or make transaction
processes implemented from selections of the possible options
available to the subscriber.
[0102] The first administrative configuration settings model 1410
is a very simplistic. Under this model the administrator can make
option level 1 1411 available to the subscriber, or the
administrator can dictate that the client device of the subscriber
implement a transaction process based on a selection in option
level 1 1411. Therefore, the administrator can give the subscriber
the ability to choose to enable or disable single execution
transactions or the administrator can dictate that the subscriber's
client device either performs or does not perform single execution
transactions.
[0103] The second administrative configuration settings model 1420
has three levels of options. Option level 1 1421 concerns
subscriber logins, option level 2 1422 concerns the scope of a
subscriber login, and option level 3 1423 concerns a notifier
option. This administrative configuration settings model 1420
illustrates an implementation where an administrator chooses a
particular transaction process to be provided to the client devices
140 (FIG. 1). The darkened line 1424 outlines the options selected
to create the transaction process, terminating with the circled end
node 1425. This transaction process will enable a subscriber to
login 1428, enable subscriber to login to a session 1427, and
display a notification icon 1429 in association with the activated
transaction process.
[0104] The third administrative configuration settings 1430 model
has four option levels. The administrator has the ability to
provide these option levels to the subscriber. If the administrator
provides these options, then the subscriber can choose among them
and subsequently have transaction processes implemented based on
those choices.
[0105] In one example embodiment, the administrative configuration
settings, such as 1430, are provided to the administrator by the
administrative user interface 190 (FIG. 1) in a format similar to
their graphical representation in FIG. 14. In another
implementation, the administrative user interface 190 (FIG. 1) is a
command line interface where the administrator configures the
available options and/or transaction process through the entry of
certain commands. One of ordinary skill in the art will recognize
that there are a variety of different methods by which to implement
the functionality provided by administrative user interface 190
(FIG. 1).
[0106] FIG. 15 is a diagram that depicts the administrative user
interface 190A, an example embodiment, enabled by the
administrative transaction configuration module 170. The
administrative user interface 190A enables the administrator to
determine what options are available and to whom they are
distributed. The administrative user interface 190A provides an
interface screen to configure allowable general settings 1510,
notifiers 1520, PINs 1530, billing 1540, subscriber login 1550, and
reminders 1560 options. In one implementation, the administrator
can configure what reminders 1560 options are available and to whom
they are available. After selecting the reminders 1560 tab, the
administrator will be presented with the possible reminder options
window 1561. The administrator can choose from among the possible
reminder options window 1561 those options to be made available to
the subscriber. In a non-limiting example, the administrator can
add the options to the chosen reminder options window 1563 by
selecting an option in the possible reminder options window 1561
and then selecting the ADD 1562 button. Once an option has been
added to chosen reminder options window 1563, it can be removed by
selecting the option and then selecting the remove 1564 button. In
one implementation, those options that are placed into the chosen
reminders options window 1563 are subsequently provided to the
subscriber where they can be chosen and then implemented as
transaction processes.
[0107] Not only does the administrative user interface 190A enable
the administrator to determine what options are available to the
subscriber, it also enables the administrator to determine which
subscribers are provided with the chosen options. In a
non-limiting, example the administrator can dictate what regions of
the media service system 110 (FIG. 1) are provided with the chosen
options by making selections in the regions where available window
1570. In the implementation depicted in FIG. 15, the north region
1571 and the eastern region 1572 have been selected to receive the
chosen options. In this implementation, the media service system
1570 has been broken into four regions and only the client devices
140 (FIG. 1) in those regions whose activation buttons are selected
by the administrator will receive the chosen options. In addition
to defining the areas of distribution of chosen transaction
configuration options to regions, the administrator can restrict
and permit distribution of these options to particular client
devices. The subscribers to exclude 1580 window enables the
administrator to restrict options from being provided to particular
subscribers by entering the subscriber identification number in the
subscriber identification box 1581. In one implementation, multiple
subscriber identification numbers could be entered separated by
commas. This implementation provides the administrator with many
features. In a non-limiting example, the administrator might desire
to deny delinquent customers or customers with bad credit from
gaining access to certain options. In a non-limiting example,
delinquent customers may not be provided the option to charge to a
credit card. In addition, the administrator could deny those
customers with a history of making numerous inadvertent purchases
the ability to enable single execution transactions. Not only can
the administrator deny particular subscribers, but the
administrator may also include particular subscribers by using the
subscribers to include window 1590. The subscriber identifications
entered in the subscriber identification box 1591 will have access
to the chosen options although their region has been excluded. In
this manner, the administrator could give preferential treatment to
subscribers with exceptional credit or good payment histories. In a
non-limited example, the administrator might want to deny single
execution purchases to specific areas of the media service system
110 (FIG. 1) but singularly allow them to the good customers in
that same area.
[0108] In one embodiment, the subscriber identification numbers
could relate to particular subscribers using a subscriber login to
access the media service system 110 (FIG. 1) through one of the
client devices 140 (FIG. 1). In an alternate embodiment, the
subscriber identification number could correspond to a particular
one of the client devices 140 (FIG. 1). In a non-limiting example,
the subscriber identification could be implemented like a unique
hardware address within the client device.
[0109] It should be noted that one of ordinary skill in the art
would recognize that the regions where available window 1570, the
subscribers to exclude window 1580, and the subscribers to include
window 1590 could apply specifically to the reminders 1560 options
or more generally to all the options as a whole. Furthermore, the
embodiment depicted in FIG. 15 is merely one example of the variety
of ways in which the administrative user interface 170 (FIG. 1)
could be provided.
[0110] FIG. 16 is a diagram of subscriber user interface 180K, an
example implementation of subscriber user interface 180 (FIG. 1),
depicting a remote subscriber user interface 1600 screen. In one
implementation, the subscriber might be able to access the remote
subscriber user interface 1600 via the internet. Thereby, a
subscriber could select among the available transaction
configuration options and have these selections implemented as
transaction processes in that subscriber's client device. The
subscriber could select from the given tabs to set general settings
1610, notifiers 1620, PINs 1630, billing 1640, subscriber login
1650, and reminders 1660 options. The interface layout depicted in
FIG. 16 is similar to the subscriber user interfaces previously
described. The reminders 1660 options section depicted allows the
subscriber to enable reminders and configure the parameters
associated with those reminders. In a non-limiting example, the
subscriber could access the remote subscriber user interface 1600
in an ordinary internet browser and select the desired transaction
configuration options. The next time that subscriber used the
subscriber's client device, the prescribed options would be
implemented in the appropriate transaction processes when making
purchases using the media service system 110 (FIG. 1).
[0111] In addition to the subscriber user interface 1600 variation
shown in FIG. 16, many other variations are possible. In a
non-limiting example, the subscriber user interface 180 (FIG. 1)
could be implemented as voice command software. The voice command
software could be a component within the client device 140A (FIG.
1) or a device coupled to the client device 140A (FIG. 1) over a
communications link. The voice command software could enable the
user to give voice commands regarding choices of available
transaction configuration options. After commencing a voice command
session of the subscriber user interface 180 (FIG. 1), the client
device 140A (FIG. 1) could implement the appropriate transaction
processes.
[0112] The media service system 110 (FIG. 1) utilizes standard
encryption techniques to protect the sensitive subscriber
information requested in the subscriber user interface 180 (FIG.
1). The embodiments described above, in many cases, will increase
the security of subscriber transactions by requiring less
repetitive entries of sensitive information. In addition, the
subscriber user interface 180 (FIG. 1) may show only partial
amounts of sensitive information when used for verification
purposes.
[0113] The transaction configuration module of the present
invention can be implemented in hardware, software, firmware, or a
combination thereof. In addition, the transaction configuration
module can be implemented in a distributed fashion in more than one
device in the system. In the preferred embodiment(s), the
transaction configuration module is implemented in software or
firmware that is stored in a memory and that is executed by a
suitable instruction execution system. If implemented in hardware,
as in an alternative embodiment, transaction configuration module
can be implemented with any combination of the following
technologies, which are all well known in the art: a discrete logic
circuit(s) having logic gates for implementing logic functions upon
data signals, an application specific integrated circuit (ASIC)
having appropriate combinational logic gates, a programmable gate
array(s) (PGA), a field programmable gate array (FPGA), etc.
[0114] The transaction configuration module, 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 if necessary, and then
stored in a computer memory.
[0115] In concluding the detailed description, it should be noted
that it will be clear to those skilled in the art that many
variations and modifications can be made to the preferred
embodiments without substantially departing from the principles of
the present invention. All such variations are intended to be
included herein within the scope of the present invention, as set
forth in the following claims.
* * * * *