WO2000041117A2 - Purchase manager - Google Patents
Purchase manager Download PDFInfo
- Publication number
- WO2000041117A2 WO2000041117A2 PCT/US2000/000479 US0000479W WO0041117A2 WO 2000041117 A2 WO2000041117 A2 WO 2000041117A2 US 0000479 W US0000479 W US 0000479W WO 0041117 A2 WO0041117 A2 WO 0041117A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- purchase
- manager
- functions
- module
- application
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
Definitions
- 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.
- 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.
- 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.
- 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.
- API application program interface
- 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.
- 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
- FIG. 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
- Figure 6 (comprising Fig. a - Fig. d) is a sequence diagram showing use of selected operations by the purchase manager.
- the purchase manager of the invention is preferably embedded as a component in a computer operating system, as will be described more fully below.
- 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.
- 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.
- 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.
- 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.
- 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.
- CPU central processing unit
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- a purchase device may include a smart card 52 and a card interface port 50.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- the GetDevice function has been called, all future communication with that application is assumed to correspond to the given device name.
- 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.
- 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.
- 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).
- FIG. 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.
- 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.
- 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.
- 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.
- 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.
- 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.
Abstract
Description
Claims
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
KR1020017008602A KR20010103735A (en) | 1999-01-07 | 2000-01-07 | Purchase manager |
EP00906885A EP1141870A2 (en) | 1999-01-07 | 2000-01-07 | Purchase manager |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US22685899A | 1999-01-07 | 1999-01-07 | |
US09/226,858 | 1999-01-07 |
Publications (2)
Publication Number | Publication Date |
---|---|
WO2000041117A2 true WO2000041117A2 (en) | 2000-07-13 |
WO2000041117A3 WO2000041117A3 (en) | 2000-12-28 |
Family
ID=22850703
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2000/000479 WO2000041117A2 (en) | 1999-01-07 | 2000-01-07 | Purchase manager |
Country Status (3)
Country | Link |
---|---|
EP (1) | EP1141870A2 (en) |
KR (1) | KR20010103735A (en) |
WO (1) | WO2000041117A2 (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2006003424A1 (en) * | 2004-07-02 | 2006-01-12 | Symbian Software Limited | Command interaction mapping in a computing device |
US20100169898A1 (en) * | 2008-12-30 | 2010-07-01 | Stmicroelectronics R&D (Shanghai) Co., Ltd. | Unified driving method and unified driver apparatus |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4677565A (en) * | 1985-02-15 | 1987-06-30 | Brother Kogyo Kabushiki Kaisha | Automatic vending system |
EP0519071A1 (en) * | 1990-03-06 | 1992-12-23 | Omron Corporation | Programming system and method, and programming device and terminals constituting the system |
EP0690399A2 (en) * | 1994-06-30 | 1996-01-03 | Tandem Computers Incorporated | Remote financial transaction system |
-
2000
- 2000-01-07 WO PCT/US2000/000479 patent/WO2000041117A2/en not_active Application Discontinuation
- 2000-01-07 EP EP00906885A patent/EP1141870A2/en not_active Withdrawn
- 2000-01-07 KR KR1020017008602A patent/KR20010103735A/en not_active Application Discontinuation
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4677565A (en) * | 1985-02-15 | 1987-06-30 | Brother Kogyo Kabushiki Kaisha | Automatic vending system |
EP0519071A1 (en) * | 1990-03-06 | 1992-12-23 | Omron Corporation | Programming system and method, and programming device and terminals constituting the system |
EP0690399A2 (en) * | 1994-06-30 | 1996-01-03 | Tandem Computers Incorporated | Remote financial transaction system |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2006003424A1 (en) * | 2004-07-02 | 2006-01-12 | Symbian Software Limited | Command interaction mapping in a computing device |
US20100169898A1 (en) * | 2008-12-30 | 2010-07-01 | Stmicroelectronics R&D (Shanghai) Co., Ltd. | Unified driving method and unified driver apparatus |
US8732729B2 (en) * | 2008-12-30 | 2014-05-20 | Stmicroelectronics R&D (Shanghai) Co., Ltd. | Unified driving method and unified driver apparatus |
US8813099B2 (en) | 2008-12-30 | 2014-08-19 | Stmicroelectronics R&D (Shanghai) Co., Ltd. | Unified driving method and unified driver apparatus |
Also Published As
Publication number | Publication date |
---|---|
KR20010103735A (en) | 2001-11-23 |
EP1141870A2 (en) | 2001-10-10 |
WO2000041117A3 (en) | 2000-12-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
AU2003234144B2 (en) | Supporting common interactive television functionality through presentation engine syntax | |
CN100518267C (en) | Contextual web page system and method | |
US5724492A (en) | Systems and method for displaying control objects including a plurality of panels | |
US6981042B1 (en) | Multimedia terminal adapted for multiple users | |
US7984478B2 (en) | Method and apparatus for a receiver/decoder | |
AU766861B2 (en) | Television set-top box with configurable functionality | |
US7039245B1 (en) | Processing of digital picture data in a decoder | |
Peng | Digital television applications | |
US7614013B2 (en) | Remote media detection and presentation | |
CN104363503A (en) | Display apparatus and method for controlling the display apparatus | |
US20020073218A1 (en) | Stream device management system for multimedia clients in a broadcast network architecture | |
AU740740B2 (en) | Data processing system | |
EP1166560B1 (en) | Tv manager | |
UA61944C2 (en) | Method for storing sets of transmitted data (variants) and the device for the realization of the method | |
CN100399811C (en) | Receiver/decoder and method of processing video data | |
US6721949B1 (en) | Kernel abstraction layer for digital television set-top box firmware | |
WO2000041117A2 (en) | Purchase manager | |
US9681178B2 (en) | Distributed presentation software for multiple instantiations in home network | |
KR20020035561A (en) | Apparatus for and method of testing applications | |
NZ500205A (en) | Common interface between applications and computer components | |
EP1286549A2 (en) | Receiver/decoder and module for use with a receiver/decoder | |
KR101181607B1 (en) | Method for processing the display of application for data broadcasting service | |
KR20000076405A (en) | Acess control system | |
Gordon et al. | The OpenCable application platform | |
MXPA00000776A (en) | Ieee set top box device driver |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AK | Designated states |
Kind code of ref document: A2 Designated state(s): KR |
|
AL | Designated countries for regional patents |
Kind code of ref document: A2 Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
DFPE | Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101) | ||
AK | Designated states |
Kind code of ref document: A3 Designated state(s): KR |
|
AL | Designated countries for regional patents |
Kind code of ref document: A3 Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2000906885 Country of ref document: EP |
|
WWE | Wipo information: entry into national phase |
Ref document number: 1020017008602 Country of ref document: KR |
|
WWP | Wipo information: published in national office |
Ref document number: 2000906885 Country of ref document: EP |
|
WWP | Wipo information: published in national office |
Ref document number: 1020017008602 Country of ref document: KR |
|
WWW | Wipo information: withdrawn in national office |
Ref document number: 2000906885 Country of ref document: EP |
|
WWW | Wipo information: withdrawn in national office |
Ref document number: 1020017008602 Country of ref document: KR |