WO2000041117A2

WO2000041117A2 - Purchase manager

Info

Publication number: WO2000041117A2
Application number: PCT/US2000/000479
Authority: WO
Inventors: Bill J. Aspromonte
Original assignee: Powertv, Inc.
Priority date: 1999-01-07
Filing date: 2000-01-07
Publication date: 2000-07-13
Also published as: WO2000041117A3; KR20010103735A; EP1141870A2

Abstract

Applications perform secure purchasing transactions through the purchase manager which interfaces the application with a purchase device using an indirection mechanism. The purchase manager is preferably associated with an operating system and provides an application program interface (API) with which the application communicates. The application issues commands through the application program interface and these commands are mapped for execution through a dispatch table forming part of the purchase device module. The dispatch table identifies functions within the purchase device module.

Description

PURCHASE MANAGER

Background and Summary of the Invention

The present invention relates generally to computer operating systems and multimedia delivery systems. More particularly, the invention relates to a computer-implemented interface between a user application and a purchase device within a media delivery system such as within a set-top box delivery system. The Federal Communications Commission (FCC) has promulgated a new set of television broadcasting standards for implementing digital television (DTV). It is expected that digital television will eventually replace the current NTSC standard in homes across the country and throughout the world. Digital TV offers a number of advantages over the conventional NTSC standard, including high- definition pictures, vastly improved user interactivity, support for worldwide web and internet e-mail resources and the like.

We anticipate that the new digital TV standard will promote the confluence of computer and television technologies with far reaching impact. Thus the personal computer will someday function as home entertainment multimedia system and the television will someday function as a node on a variety of computer networks ranging from the home automation network to the internet. While there are a number of different possible physical packages for deploying digital television technology, currently most popular is the set-top box.

In early days the set-top box served primarily as the tuner and signal de-scrambler for cable TV. More recently, companies such as Scientific Atlanta have developed far more sophisticated set-top boxes, offering the power of the personal computer, complete with full-fledged computer operating system. The set-top box offers a challenging site to deploy a computer operating system. Memory resources within the set-top box are quite limited. Thus applications supported by the operating system must use memory in a highly efficient manner. Whereas the memory requirements of applications designed for general purpose operating systems can be met by simply adding more memory, that is not an acceptable solution in the set-top box environment.

The set-top box operating system must be extremely robust. Unlike general purpose operating systems, that can be rebooted when software problems occur, rebooting is not an acceptable solution for the set-top box. Viewers find it highly unacceptable when forced to reboot while watching a favorite program. Supporting rich user interactivity in this environment presents further challenges. The interactive environment affords the opportunity to offer goods and services for purchase. Pay-per-view televised events and movies and home shopping networks are but two examples. Heretofore there has been no standardized way of supporting interactive purchasing. Traditionally, applications written to facilitate on-line purchasing have dealt with communication issues, security issues, product identification issues and funds transfer issues on an ad hoc basis. There has heretofore been no operating system-level standardization.

The present invention provides this missing operating system-level standardization through a purchase manager for interfacing between applications and purchase devices, which can be any user-interactive purchasing mechanism. The purchase manager includes at least one purchase device module, associated with the purchase device and a purchase manager module that has a mechanism for identifying the purchase device module and for assigning it a module handle.

The purchase device module has an associated dispatch table that provides access to a plurality of predefined functions within the purchase device module. The module handle assigned by the purchase manager module affords access to the dispatch table.

The purchase manager further defines an application program interface (API) that has a plurality of predefined API functions that map onto the predefined functions of the purchase device. The purchase manager module thus defines an indirection mechanism whereby the application issues commands through the application program interface and these commands are mapped for execution through the dispatch table onto the predefined functions within the purchase device module. The purchase manager gives operating system control over the purchasing process, simplifying application design and enforcing communication standards and security standards. The module handle and dispatch table architecture makes it easy to upgrade the functionality of purchase devices. The dispatch table stores branch instructions referencing or branching to the executable instructions associated with the functions performed by the purchase device. These branch instructions can be readily changed to support new functionality.

For a more complete understanding of the invention, its objects and advantages, refer to the following specification and to the accompanying drawings.

Brief Description of the Drawings

Figure 1 is a hardware diagram of an exemplary digital set-top box; Figure 2 is a block diagram of the operating system, showing the purchase manager as one component thereof; Figure 3 is a detailed block diagram showing the components of the purchase manager of the invention;

Figure 4 is a further detailed block diagram of the internal components of the purchase manager module;

Figure 5 is a sequence diagram showing purchase manager initialization; and

Figure 6 (comprising Fig. a - Fig. d) is a sequence diagram showing use of selected operations by the purchase manager.

Detailed Description of the Preferred Embodiment The purchase manager of the invention is preferably embedded as a component in a computer operating system, as will be described more fully below. Although the purchase manager is not limited to the set-top box environment, it is useful in that environment. Accordingly, Figure 1 illustrates the basic components of a digital set-top box. A basic understanding of the set-top box may be helpful in understanding the purchase manager of the invention.

Referring to Figure 1 , the set-top box 10 is coupled to the cable and telecommunications infrastructure 12 through a suitable cable 14. The set-top box is also coupled through a second cable 16 to the television set 18.

The incoming cable 14 may support a plurality of different channels. For purposes of illustration, cable 14 has been shown as supplying three different logical channels: (a) a set of analog TV channels, (b) a set of digital TV channels and (c) a set of data communication channels. It will be appreciated that these are logical channel constructs; all three sets of channels are typically carried on the same physical wire or fiber-optic cable. Thus the three separate channels shown in Figure 1 are for illustration purposes only. Conventionally, the analog and digital TV channels support one-way communication, from the cable and telecommunications infrastructure 12 to the digital tuner 20. The data communication channels are two-way channels, supporting bi-directional communication between the infrastructure 12 and the tuner 20.

The various sets of channels supplied via cable 14 are distinguished by frequency. Digital tuner 20 selects which frequency, and thus to which channel, the set-top box is tuned. Analog TV channels are sent directly from tuner 20 to the multimedia compositor circuit 22. The compositor circuit formulates the RF signal supplied through cable 16 to the television 18. Typically the television is tuned to a pre-assigned channel to properly receive the RF signal from compositor 22.

Digital TV channels are also sent to compositor 22, although they are first processed through the additional circuitry illustrated at 24. Specifically, the digital TV signal is first processed through the quadrature amplitude modulated (QAM) data link processor 26 and then by the MPEG transport circuitry 28. The transport circuitry extracts the desired digital TV program from the transport stream. It then separates the audio, video and data components, which are routed to the video and audio decoders 30 and to the CPU ram 36. MPEG video and MPEG audio are then separately processed by the circuitry 30. Data communication, including control signals for messaging are separately processed through the quaternary phase shift keying (QPSK) modem 32. The modem is coupled to the central processing unit (CPU) 34, which has associated CPU RAM 36.

The multimedia compositor 22 generates a display image from video and audio input streams and from CPU-generated media. It combines graphics and text, generated by applications running in the digital set-top box, with full motion MPEG-2 or analog video. The composition of graphics and video includes translucent alpha-blending of the two, scaling of motion video into a window, and the overlay of graphics and video. Similarly, the multimedia compositor combines application audio with MPEG and analog broadcast audio, mixing simultaneously networked and local sounds (either sampled or synthesized) into a single signal.

In an interactive digital environment, QPSK channels provide transparent two-way communications between the user and the content provider. Database queries to content providers travel over these channels to provide users with a choice of interactive entertainment options. While applications are running, these channels transmit user commands, such as play video, pause, or fast- forward, to the content source. They also allow for the request and delivery of graphics, fonts and other data and support purchasing of goods and services.

The presently preferred set-top box is bundled with an operating system whose architecture is illustrated in Figure 2. Specifically, Figure 2 provides a high-level view of the operating system components. Pertinent to the present invention is the purchase manager component 40 that serves as an interface between the purchase devices and the set of applications 44 running on the operating system. The applications 44 are launched by the application manager 46 and thereafter provide various user interactivity functions. Examples of applications 44 include on-screen TV guide services, interactive advertising services, goods and services purchasing services, internet web browsing and e- mail services, and the like. The operating system also includes a kernel, an event handler and a memory manager residing in the core layer 42 to provide the base functionality needed to support an application. In addition, each hardware device associated with the set-top box is abstracted into a software device module that resides in the hardware abstraction layer 43.

The purchase manager 40 is designed primarily to serve as an interface or indirection mechanism between applications 44 and purchase devices. In a purchasing system, the application 44 could be a simple application designed to order pay-per-view materials or a more complex application designed to display detailed information about available products and to process an order to purchase selected items, including handling the financial transactions involved. Referring to Figure 1 , a purchase device may include a smart card 52 and a card interface port 50. In this regard, the set-top box is provided with a suitable card interface port 50 for receiving the smartcard 52. The purchase manager 40 also interfaces the application 44 with the communications capabilities of the operating system needed to send messages to the service provider (e.g., via the QPSK modem 32). While the above description references a smartcard and a card interface port, it is readily understood that other types of purchase devices are envisioned within the scope of the present invention.

The presently preferred purchase manager architecture is shown in Figure 3. The purchase manager shown generally at 40 interfaces between application 44 and a purchase device 54. Associated with each purchase device 54 is a purchase device module 56 that includes a module dispatch table 58. The purchase device module 56 includes executable instructions that comprise a set of predefined functions depicted diagrammatically at 60. These predefined functions relate to various operations that may be performed by the purchase device 54.

The module dispatch table 58 of the preferred embodiment is a lookup table that contains branch instructions into the executable instructions that make up the predefined functions 60. Directing the CPU's program counter to any entry in the module dispatch table will cause CPU operation to branch to a series of executable instructions within the purchase device module to perform one of a plurality of functions. Although populating the module dispatch table with direct branch instructions is the presently preferred configuration, other techniques are also envisioned, such as referencing instructions.

One advantage of the module dispatch table is that the contents of the table can be changed, at load time for example, to substitute a different series of instructions for one or more of the predefined functions. This allows the system to be easily modified without requiring shipment back to the factory.

The purchase manager 40 further comprises a purchase manager module 62 that includes an associated purchase manager application program interface or API 64. The purchase manager API 64 defines a plurality of predefined API functions designated at 66. These comprise all of the functions or commands that application 44 may invoke with respect to the purchase manager 40. These API functions 66 map onto the predefined functions 60 of the purchase device module. In the preferred embodiment there is a one-to-one relationship between API functions 66 and the predefined functions 60.

The purchase manager module includes an indirection mechanism depicted diagrammatically at 68. The indirection mechanism accepts commands issued by application 44 through the purchase manager API 64 and maps these commands for execution by the purchase device module 56 through the module dispatch table 58. In the presently preferred embodiment the indirection mechanism uses a function call that converts commands entered through the purchase manager API 64 into actual callable functions, complete with proper operands as defined within the purchase device module. This indirection mechanism thus allows an application 44 to effect actual function calls within the purchase device module, without interacting directly with the purchase device module. Indeed, the application 44 does not need to know where the purchase device module may be found within memory. These details are handled by the purchase manager module through a module handle that the purchase manager module 62 assigns to the purchase device module 56 during initialization.

More specifically, the purchase manager module 62 includes procedures, described more fully below, that seek out and identify purchase device modules that have been installed within the operating system. The purchase manager module assigns module handles to each of the purchase device modules identified, and these handles are then used to access the module dispatch table 58. When the application wishes to perform one of the predefined functions of a purchase device module, it merely issues commands to the purchase manager API 64, and the purchase manager module 62 handles all details regarding locating the selected purchase device module and causing program control to branch to the appropriate executable instructions within the purchase device module.

Further details of the presently preferred purchase manager will now be reviewed with reference to Figure 4. In Figure 4 a single application 44 and a plurality of purchase device modules 56a and 56b have been illustrated. To more fully demonstrate the presently preferred architecture, an additional module 70 has been illustrated. The module 70 provides functionality not directly related to supporting a purchase device. It has been illustrated here to show that the purchase manager module will discriminate between modules that function as purchase device modules and those that do not. (The details on how this discrimination is performed will be discussed in connection with Figure 5 below.)

Figure 4 illustrates at 72 a set of individual functions or functional blocks that comprise an exemplary purchase manager module. Each of these blocks is labeled with a descriptive name denoting the function of that block. Some of the blocks represent executable code that defines the purchase manager itself. These include the GetDevice block 74, the FindDevice block 76 and the ShutDown block 78. The remaining blocks correspond to indirection mechanism operations whereby API functions (issued by an application 44) are converted into predefined functions associated with the selected purchase device module.

When an application 44 wishes to perform one of the predefined functions associated with a purchase device module, the application enters into a dialog with the purchase manager, giving the purchase manager the device name associated with the desired purchase device. The purchase manager then performs its GetDevice function 74 to return a module handle that is then associated with the designated device name. Thereafter, the application merely issues commands corresponding to one of the indirection functions illustrated at 72 and the purchase manager module accesses the module dispatch table of the identified purchase device module to construct the appropriate branching instruction. Once the GetDevice function has been called, all future communication with that application is assumed to correspond to the given device name.

In Figure 4 the designation [B] has been used to denote that all of the functions at 72 labeled [B] are mapped through the module dispatch table [B] of purchase device module 56b. Thus in Figure 4 all blocks labeled [B] represent indirection functions associated with a given purchase device module. The unlabeled blocks represent functions associated with the purchase manager module itself.

In Figure 4 the following convention has been adopted. Input parameters supplied by application 44 when calling an associated function are shown on the left-hand side of the corresponding block. Output parameters issued by the corresponding block when accessing the module dispatch table are shown along the bottom side of each block.

For example, the VerifyPassword block receives as input: the purchase device module i.d., the password number, the password and a pointer identifying where reply messages may be sent. The presently preferred embodiment uses a messaging system for communicating with the purchase device module to effect a switch between synchronous mode and asynchronous mode. These two modes are discussed more fully below. The VerifyPassword block returns as its output: the password number, the password and a reply message.

In the preferred implementation the password number corresponds to a particular user or a particular instance of the application program. The password number is analogous to a user name of an e-mail system. The password is the secret string of characters known to the application program and to the Purchase device module. This password is analogous to a password in an e- mail program.

The purchase device modules of the preferred embodiment are designed to run as threads in a multi-threaded operating system environment. Threads can run asynchronously, that is independent of one another. Threads can also run synchronously, that is in synchronism with one another. To operate in synchronous mode, the thread will typically employ a blocking instruction that causes operation of that thread to be suspended or blocked until a message is received from another thread. In this way, one thread can be programmed to wait for another thread to catch up before it proceeds to complete its operation. In the asynchronous mode a thread will run to completion without blocking instruction regardless of the operating state of other running threads.

The presently preferred embodiment uses a messaging system for communicating between threads. This messaging system can also be used to switch a module between the synchronous and asynchronous modes. As illustrated in Figure 4, a program block (such as the VerifyPassword block) is supplied with a reply pointer that may be de-referenced (*r) to determine where that block should send reply messages (r).

Interaction among the application, the purchase manager and the purchase device module involves a sequence of exchanges illustrated in the sequence diagrams of Figures 5 and 6. Figure 5 illustrates the initialization sequence performed by the purchase manager. The initialization sequence is perfomed during startup of each purchase device (e.g., when a smartcard is plugged in the interface port). Figure 6 illustrates a series of exchanges that occur when certain program functions are performed. In these sequence diagrams the application, purchase manager and purchase device modules are each represented in side-by-side vertically arranged columns. Communication between these three entities is from left to right and from right to left in the diagram. Time progresses from top to bottom.

Referring to Figure 5 the purchase manager initialization sequence begins with the purchase manager performing its GetDevice function, a procedure that identifies the purchase device modules installed in this system and assigns module handles to those purchase device modules. The purchase manager does this by sequentially interrogating each of the modules installed in the system. The presently preferred embodiment defines a data structure called an infostring with which all modules are classified. The presently preferred infostring structure defines a module type, a module group and a module device name. A purchase device module is one of the type: "device driver" and of the group: "purchase." The device name is an ASCII string corresponding to the name of the device as specified by the designer of the purchase device module.

The purchase manager acquires the requested device name from the application and then interrogates the infostring of all device modules to determine which are purchase device modules and whether any match the device name requested. If so then a module handle is generated to represent that purchase device. The module handle (mh) is returned to the application that specified the device name. The module handle is thereafter used by the application to invoke functions within the purchase device module. The system will walk through all modules loaded, to discover any that are purchase device modules, and will assign module handles to those that match device names used by applications within the system. In the presently preferred embodiment the GetDevice block 74 calls the FindDevice block 76 to perform the actual infostring analysis. Naturally, these functions can be combined into a single entity, if desired.

Once the applications have been provided with module handles to represent the purchase device modules, the system can be used to interface between the application and a purchase device. Figure 6 shows an exemplary sequence that would be performed to verify a password, request a list of available items for purchase, obtain a description of one of the items and make a purchase of that item.

As will be seen by studying Figure 6, the purchase manager of the invention interfaces between the application and the purchase device, effecting an indirection mechanism whereby the application issues commands through the application program interface and these commands are mapped for execution through the dispatch table onto one of a plurality of predefined functions within the purchase device module.

While the invention has been described in its presently preferred embodiment, it will be understood that the purchase manager of the invention can be implemented in different ways without departing from the spirit of the invention as set forth in the appended claims.

Claims

1. A computer-implemented purchase manager for interfacing between an application and a purchase device, comprising: a purchase device module associated with said purchase device and having a dispatch table that provides access to a plurality of predefined functions within said purchase device module; a purchase manager module and having a mechanism to identify said purchase device module and to assign a module handle to said purchase device module such that said purchase manager module has access to said dispatch table; an application program interface (API) defined by said purchase manager for interfacing with said application, said application program interface having a plurality of predefined API functions that map onto said plurality of predefined functions within said purchase device module; said purchase manager module defining an indirection mechanism whereby said application issues commands through said application program interface that are mapped for execution through said dispatch table onto said plurality of predefined functions within said purchase device module.

2. The purchase manager of claim 1 wherein said purchase device module includes executable instructions associated with said predefined functions and wherein said dispatch table comprises a set of branch instructions into said executable instructions.

3. The purchase manager of claim 1 wherein said purchase device module is supported by an operating system and wherein said dispatch table is loaded by said operating system.

4. The purchase manager of claim 1 wherein said dispatch table supports user configuration through selective loading of different instructions at startup.

5. The purchase manager of claim 1 wherein the API functions provided by said application program interface include open and close functions for establishing and terminating communication between said application and said purchase device.

6. The purchase manager of claim 1 wherein the API functions provided by said application program interface include get and set functions for interrogating and changing parameters within said purchase device.

7. The purchase manager of claim 1 wherein the API functions provided by said application program interface include password authentication functions.

8. The purchase manager of claim 7 wherein said password authentication functions include verify and change password functions.

9. The purchase manager of claim 1 wherein the API functions provided by said application program interface include purchase query functions to ascertain information about offered goods, offered services, purchased goods or purchased services.

10. The purchase manager of claim 9 wherein said query functions include a get list function to ascertain a list of offered goods, offered services, purchased goods or purchased services and a get description function to ascertain additional detail about at least one offered good, offered service, purchased good or purchased service.

11. The purchase manager of claim 1 wherein the API functions provided by said application program interface include make purchase and cancel purchase functions.

12. The purchase manager of claim 1 wherein the API functions provided by said application program interface include a credit function to ascertain the status of authorized purchase credits.

13. The purchase manager of claim 1 wherein said at least one of said predefined functions is switchable between synchronous and asynchronous modes.

14. The purchase manager of claim 13 wherein said purchase manager includes messaging system for communicating with said purchase device module to effect a switch between said synchronous and asynchronous modes.

15. The purchase manager of claim 14 wherein said application program interface further defines said messaging system to allow said application to effect said switch between said synchronous and asynchronous modes.