JP2003527645A - Method and apparatus for securely delivering content over a broadband access network - Google Patents

Abstract

(57) Abstract: A method for securely delivering content on demand over a broadband access network is a method that allows a client process to obtain and execute content without authorization without a set of servers. Use multiple safety features. A plurality of encrypted titles are stored on a content server connected to this network. Similarly, the access server connected to the network contains the network address and various keying and authorization data required to decrypt and execute the title. A client application running on the user's local computer system needs to retrieve the address, keying and authorization data from the access server before retrieving the title from the content server and making the title executable on the user's local computer system.

Description

Detailed Description of the Invention

RELATED APPLICATION This application is entitled “Methods and Devices for Safely Delivering Content over a Broadband Access Network,” by Jonner Schmidler et al., 199.
Claims priority under US Provisional Patent Application No. 60/108602, filed September 16,8.

Further, the present application claims priority based on three co-owned US patent applications filed by the same inventor, Jonner Schmidler et al. In the above application,

The name is “method and device for safely delivering contents via a broadband access network”, and Jonner Schmeidler et al., May 1, 1999.
US Application No. 09/310294, Attorney Docket No. A002, filed on the 2nd
8/7000,

The name is “method and device for installation abstract in secure delivery system of contents”, and Jonner Schmeidler et al., May 1, 1999.
U.S. Application No. 09/311923, filed on 2nd, Attorney Docket No. A002
8/7001,

US patent application Ser. No. 09/310299 filed May 12, 1999 by Jonner Schmeidler et al., Entitled “Method and apparatus for content protection in safe delivery of content” Number No. A0028 / 700
2 and

[0006] The name is "method and apparatus for on-demand distribution on a broadband access network", and US application No. XX / XXXXXXX filed on May 12, 1999 by Jonner Schmidler et al. Number No. A0028 / 700
3 and 3.

The subject matter of the above-identified copending patent application is incorporated herein by reference.

FIELD OF THE INVENTION The present invention relates generally to methods and systems for distributing data over a network, and more particularly to executing software content on demand subscription or subscription (subscription). The present invention relates to a system for delivering via a broadband access network in a manner that enables the original language (subscription).

Background of the Invention Software applications and on-demand delivery of multimedia data types such as audio, video, animation, etc. have not been practical until recently, mainly due to their transmission speed over networks. The transmission rate of data formatted into a series of bits is called bps. In the early days, the information transmission capacity of the modem was about 300 bits per second, but thereafter the data transmission / reception speed of the modem increased. With this increase in modem speed, the nature of the topology of the network as well as the type of data transmitted over the network has begun to evolve. At 9600 bps and 1200 bps modem speeds, computer networks such as the Internet were predominantly ASCII text environments with specific protocols and text messages. The continued increase in modem speed has made more complex information accessible over the Internet and other computer networks. Although the ASCII text paradigm still exists in the World Wide Web portion of the Internet today, the more recent increase in bandwidth environments has enabled more complex content and multimedia data type communications.

Recently, high performance broadband technologies and cable modems with connection speeds in excess of 1 million bps are being deployed and offered worldwide by cable, telephony, mobile telephony and satellite communications companies. Current broadband access networks include media sharing hybrid fiber coaxial cable (HFC) networks in the cable communications industry and digital subscriber lines (xDSL) in the telecommunications industry.

With the advent of broadband technology and broadband access networks, complex multimedia data types and previously available only on compact disc read-only memory (CD-ROM) and digital versatile disc (DVD). Software titles (hereinafter "titles") are now accessible to subscribers of broadband access network services from remote locations.

However, in addition to the data transmission speed, there are other factors that have hindered the practical application of on-demand delivery of titles. One such obstacle that has prevented the on-demand delivery of content, including software and multimedia titles, to date is the need to have the subscriber's local computer system load the title in order to execute. It was In addition, on-demand distribution is due to the security risks associated with the widespread distribution or "pirated production" of content, and the distribution of full-featured title copies. Was not attractive to.

Thus, there is a need for a method and system for delivering on-demand executable software content that does not need to be installed on the subscriber's local computer system.

Furthermore, there is a need for a method and system for on-demand delivery of content to a system of a subscriber's local computer that provides security that protects the value of the content and prevents its unauthorized use and copying. Exists.

Further, there is a need for a method and system that can deliver content over a broadband access network in a manner that satisfies latency requirements during content execution.

SUMMARY OF THE INVENTION The secure content delivery platform (SCDP) of the present invention delivers high bandwidth executable content on demand and over a broadband access network. Using this SCDP platform, broadband subscribers, such as subscribers of cable modem and xDSL services, can access titles over a broadband network.

The user selects a title to be executed from the virtual store show window on the World Wide Web displaying a virtual catalog of available titles, for example. For negotiation, user registration in a third-party electronic commerce system (e-commerce), when a title is selected, the user negotiates to actually purchase the title. Providing user billing information and selecting one of the purchase types presented with the selected title. Examples of possible purchase types are: 1) time-limited trial of a particular title, 2) “single use” of any title.
There is one payment for each time, 3) There is one payment for allowing unlimited “multiple usage” of the title over a certain specific period such as weekly or monthly.

Once the purchase negotiation is complete, the SCDP running on the user's personal computer
Client software obtains the authorization token and keying data from the conditional access server (CAS). This token allows the client process to execute a selected title from a network file server accessible over the broadband network. The data retrieved from the file server is encrypted. The SCDP client process uses the keying data provided by the conditional access server to decrypt the data from the file server. In the present invention, the title runs on the user's personal computer, but the entire title is not downloaded to this personal computer. The title is formatted in an electronic package that contains the title file in a compressed and encrypted form (hereinafter referred to as briq). This briq is actually a portable, independent language file system that contains all the files needed to perform a particular title. The briq is stored in a network file server (hereinafter referred to as RAFT server) accessible via a broadband network. The SCDP client treats briq like a local file system on the user's personal computer. When executing a title, an operating system such as Windows® requests a read from such a local file system. In the illustrated embodiment, a SCDP client, including a Windows® virtual device driver (VxD), responds to such a request by retrieving the requested block of briq data from the RAFT server. After searching the requested block of data, V
The xD compresses and encrypts the briq data and sends the data to the operating system of the user's personal computer.

According to one aspect of the invention, the software title is never “installed” on the target computer. The SCDP client software creates an installation abstraction, maintaining the illusion to the operating system that the currently running title is installed on the host computer. Therefore, when the title has finished executing, there is no evidence that the title has been executed on the system. No files associated with the title remain on the hard disk of the personal computer, and no operating system status information such as registry variables associated with the title remains. The user of the title has the option to save some state information that it may be desirable to maintain throughout play, such as "levels" earned in games and the like. Such status information can be stored in a write-through file described later.

According to another aspect of the invention, the SCDP client software retrieves briq data over a broadband network using the proprietary random access file transfer (RAFT) protocol of the invention. This protocol provides SCDP clients with read-only access to files and directories stored on RAFT servers. Since the briq is treated as one local file system, the RAFT client does not need to be recognized as one operating system drive, and the operating system file system manager, ie Windows® in the illustrated embodiment. No need to interface to an Instroub File System (IFS) manager. Thus, the RAFT client file system driver, VxD in the illustrated embodiment, is smaller and simpler than the remote or network file system driver. Furthermore, RAFT
The protocol supports dynamic bandwidth limitations such as "bandwidth throttling" and also supports access control through the use of RAFT authorization tokens.

According to another aspect of the invention, SCDP uses various security features to protect content from unauthorized access and replay. The authorization token and decryption key are obtained from the conditional access server. Network communication between the SCDP client and the CAS is protected via a secure remote procedure call (RPC) interface. Once the secure channel is established between SCDP and CAS, SCD
The P-Client requests RAFT authorization token and keying data for the selected title. This authorization token is an encoded message from the CAS that allows the requesting user to be clarified to a particular briq, a particular RAFT file server, and a negotiated payment type. Indicates that access is possible for a period of time.

The RAFT authorization token allows the SCDP client to
Access to the title, the SCDP client must still unpack the briq to access the title's file data, eg decompression and decryption. Although CAS provides the user with the keying data needed to decrypt the briq data, CAS does not provide the keying data directly to the SCDP client. Instead of providing it directly, CAS hides the keying data from the user by embedding the key in an obfuscated bytecode that implements a decryption algorithm. Instead of passing orphaned keying data to the SCDP client, the CAS passes obfuscated bytecodes (hereinafter activators). The virtual device driver of the SCDP client executes the activator with the bytecode interpretation program to decrypt the briq data. Code obfuscation makes retrograde analysis of an activator difficult, and hackers must spend significant time and resources retrieving the keying data from this activator, typically The cost is more than the value of the protected content. For the purposes of this invention, there is only one activator per client, per briq, and per run, ie, CA.
The activators obtained from S are different from each other and can be used only once. By doing so, users who use it multiple times will not be motivated to carry out costly retrograde analysis.

According to the present invention, both the RAFT authentication token and the activator have a limited lifetime. The authentication token contains the expiration period and is no longer valid. The running activator will at some point C
Start exchange with AS. If that exchange fails, the activator becomes inoperable and thus the title. Update of the activator is hereinafter referred to as activator retention. The result of this retention function is that the currently executing activator is handed the latest version, which may also include new keys, data or even code.
When the authentication token is updated, the activator is also updated. The new authentication token is embedded in this new activator, along with the decryption keying data. At start-up, the update activator causes RAFT in the SCDP client to
• Hand over a new RAFT authentication token to VxD.

The SCDP system is medium independent, and if there is sufficient bandwidth between the user and the network server to meet the time requirements of the currently running CD title, the HFC network and the telephone company It will work with any broadband network technology in general, including digital subscriber lines. The SCDP system has 1
It can also be implemented using 0 Mbps and 100 Mbps Ethernet local area networks, for example within a corporate network for delivering executable content as well over an intranet.

According to a first embodiment of the invention, a method for delivering content over a network comprises: (a) executing at least one title on a content server functionally connected to said network. Storing in an impossible format, (b)
Storing, in an access server functionally connected to the network, a location identifier of the title and data necessary to process the title into an executable format; and (c) the content server to the title. Requesting a client process functionally connected to the network to obtain the location identifier of the title from the access server prior to retrieving at least a portion of the title; Requesting the client process to obtain from the access server the data needed to process a portion into an executable form.

According to a second embodiment of the present invention, a device for securely delivering content over a network is (a) functionally connected to said network and executing at least one title. A content server stored in an impossible format, and (b) an access server functionally connected to the network, required to process the location identifier of the title and the title into an executable format An access server for storing various data, and (c) a client system functionally connected to the network for processing the location identifier of the title and the portion of the title into an executable format. A client including program logic configured to obtain the data required for the access server from the access server. And the system.

According to the third embodiment of the present invention, the device for delivering the content via the network is (A) a content server system connectable to the network, and (A.1) time is required. Authentication logic including data specifying an interval and responding to a token received from a client process, the authentication logic determining whether the client process is authorized to access memory at a particular time; A.2) An access program logic responsive to the token including data uniquely identifying one of the titles received from the client process and stored in the memory, the access program logic being unique to the memory and the token. The access that enables access to the specified title. Content server system including a process program logic,
(B) An access server system connectable to the network, comprising:
1) A conversion program logic responsive to a unique identifier of a title provided by a client process, configured to convert the unique identifier of the title into a location identifier on the network indicating an address accessible to the title (B.2) Activator generation logic that responds to a request from a client process, the activator generation logic that generates an activator in response to the request. A server system, and (C) a client system connectable to the network, and (C.1) a token, an activator, and a location identifier of the content server that can access the specified title from the access server system. And get (C.2) program logic configured to retrieve at least a portion of the identified title from the content server; and (C.3) the title retrieved from the content server. And a client system that includes program logic configured to execute the portion of.

According to a fourth embodiment of the present invention, there is provided a method of executing an application on a local computer system even if the application is not installed on the local computer system, comprising: (a) a network mountable file. Accessing a system and a set of registry entries associated with the application; (b) mounting the network file system; and (c) storing the registry entry on the local computer system. d) retrieving at least a portion of the application from a remote source; (e) executing the application under control of the operating system of the local computer system; and (f) the operation. Intercepting a request from a remote system, and (g) forwarding the selected portion of the intercepted request to a registry entry stored on the local computer system.

According to a fifth embodiment of the present invention, a system for executing an application without installing it on a computer system mounts a network file system and stores a plurality of registry entries associated with the application. A program logic configured to store at least a portion of the application from a remote source, the program logic responsive to a request from the operating system, the operating system comprising: Program logic configured to intercept a request from a system and forward a selected portion of the intercepted request to the registry entry.

According to the sixth embodiment of the present invention, a method for enabling on-demand delivery of titles includes (a) a token, an activator, and a source from which the specified title can be accessed from the access server. And (b) sending the token to the source, the token data defining a time interval during which the source is accessible, and (c)
) Retrieving at least a portion of the title from the source; (d) Performing the portion of the title retrieved from the source; (e) Obtaining an updated token from the access server. Includes and.

According to a seventh embodiment of the present invention, a method for enabling a requesting process to access a title comprises: (a) authenticating a launch string from the requesting process; and (b) from the requesting process. Converting the received unique identifier of the title into a location identifier indicating an address on the computer network that can access the title; (c) generating an activator; Sending to the requesting process via a network.

According to an eighth embodiment of the present invention, there is provided a method of using a server device comprising a processor, a memory, and a network interface and connectable to one or more client processes of a computer network (a ) Receiving a token containing data specifying a certain time and data uniquely specifying a title from the client process via the network interface, and (b) the client process accessing the title at a specific time. (C) accessing the title uniquely identified by the memory and the token if the client is authorized in step (d), (c) d) specified by the token At least part of the serial title and a supplying to the client.

According to a ninth embodiment of the present invention, a method for enabling the selective delivery of titles to one or more requestor processes via a computer network includes: Providing access to a selected portion of a title stored in an inexecutable form at an address on the computer network under predetermined conditions, and (b) providing the requestor process with an inexecutable title. Providing data useful for processing from format to executable format, and (c) preventing the title from being installed on the computer while selecting a portion of the title in the computer system. And allowing the execution of.

According to the tenth embodiment of the present invention, a method for delivering a title to one or more requester processes via a computer network is as follows: (a) data for specifying a title from the requester process And (c) providing the requester process with data identifying a location on the computer network that has access to the title and authorization data necessary to access the title; Receiving payment information from the requestor process.

According to an eleventh embodiment of the present invention, 1 via a computer network
A computer program product for use in a computer system operably connected to one or more requestor processes is configured to: (a) retrieve data identifying a selected title from the network-connected requester processes. Program code, (b) program code configured to receive payment information from the requester process, and (c)
Program code configured to enable the requestor process to access and download selected portions of the title; and (d) the title allows execution on a computer system while the title Is installed on the computer system, and the program code is configured to prevent the installation.

Detailed Description of Examples FIG. 1 shows both Sun Spark Station 5 Workstation commercially available from Sun Microsystems, Inc. of Palo Alto, Calif. Or International Business Machines Inc. of Ammok, NY. A system architecture for a computer system 100, such as an IBM RS / 6000 workstation or an IBM Attiva personal computer, in which the present invention may be implemented. The computer system of FIG. 1 is for illustration purposes only. Although this description may refer to terms commonly used in describing a particular computer system, the present description and concepts are equally applicable to other systems, including systems having different architectures than FIG. Applicable

The computer system 100 includes a central processing unit (CPU) 105 that can be executed using a conventional microprocessor, a random access memory (RAM) 110 for temporary storage of information, and a read-only storage for permanent storage of information. Element (ROM) 1
Includes 15. The memory control device 120 is arranged to control the RAM 110.

Bus 130 interconnects the components of computer system 100. The bus controller 125 is arranged to control the bus 130. Interrupt controller 135 is used to receive and process various interrupt signals from system components.

The mass storage device may be a diskette 142, a CD-ROM 147 or a hard drive 152. Data and software can be exchanged with computer system 100 via removable media such as diskette 142 and CD-ROM 147. The diskette 142 is insertable into the diskette drive 141, which drive is via the controller 140 and further into the bus 3.
Connected to 0. Similarly, the CD-ROM 147 is the CD-ROM drive 14
6 and its drive is connected via the controller 145 to the bus 130.
Connected to. The hard disk 152 is connected to the bus 130 via the control device 150.
It forms part of the fixed disk drive 151 connected to the.

User input to the computer 100 can be multiple devices. For example, a keyboard 156 and a mouse 157 are connected to the bus 130 via the control device 155. An audio transducer 196, which can operate both as a microphone and as a speaker, is connected to the bus 130 via an audio controller 197, as shown. It will be apparent to those of ordinary skill in the art that other input devices such as pens and / or tabloids can be connected to the bus 130 and appropriate control devices and software if desired. DMA controller
Arranged to perform direct store calls to RAM. The visual display is generated by the video controller 165 which controls the video display 170.
Computer system 100 also includes a communication adapter 190 that enables the computer system to interconnect with a local area network (LAN) or wide area network (WAN), as indicated schematically by bus 191 and network 195. Is included.

The operation of computer system 100 operates with Windows® 95 or Windows® NT commercially available from Microsoft Corporation of Redmond, Washington.
It is entirely controlled and coordinated by operating system software such as. The operating system controls the allocation of system resources and also performs tasks such as processing schedules, storage management, networking and input / output services, among others. In particular, the CPU 10 is resident in the system storage device.
The operating system running 5 coordinates the operation of the other components of computer system 100. The present invention is OS / 2 (registered trademark), UNIX (R)
, Linux and Solaris® may be used to run with any number of commercially available operating systems. One or more browser applications, such as Netscape Navigator, version 2.0 or higher, available from Netscape Communications, Inc., and Internet Explorer, version 1.0 or higher, available from Microsoft, Inc., Redmond, Wash. Can be run under control.

SCDP System Overview Illustrated schematically in FIG. 2A is a secure content delivery platform (SCDP) system 200 in accordance with the present invention and other elements in a broadband network environment, such environment being illustrated. It is intended for purposes only and not intended to be limiting. The elements shown in FIG. 2A should simplify and understand the present invention. Not all of the elements shown in FIG. 2A or described herein are necessary for the practice or operation of the invention. As shown in FIG. 2A, the SCDP system 200 includes a conditional access server (CAS) 210.
, An attached CAS database 212, a random access file transfer server (R
AFT) 206, RAFT database 208 and SCDP client 216
Includes.

The CAS server 210, RAFT server 206 and SCDP client 216
In addition to the virtual store show window 215 and the e-commerce server 2,
02 is intended for use. The e-commerce server 202 has an associated billing database 204. The store show window 215 is associated with the database 2
Have 13. In the illustrated embodiment, servers 202, 210 and 215 are connected via a dedicated, secure local area network (LAN), such as a local Ethernet network. The LAN is further connected to a wide area computer network topology, shown as an internet cloud 240 in FIG. 2A, via an internet service provider (ISP) 230. Any commercially available Internet access service provider such as MCI / WorldCom, AT & T, America Online, etc.
It may be used as SP230. In the illustrated embodiment, the servers 202, 210 and 215 are shown as being connected via a dedicated local area network, but such servers may be connected via other non-dedicated networks such as the Internet. It will be apparent to those skilled in the art that they may be functionally connected. In addition, the e-commerce server 202 is connected to a credit handling server of a financial or banking institution (not shown) to facilitate handling of credit cards and / or other types of transactions.

Referring again to FIG. 2A, one or more client personal computers having an architecture similar to that of FIG. 1 are connected to the SCDP system 200 via a broadband access network 203 and a cable provider 207. In the illustrated embodiment, a cable modem (CM) connects to a host computer running a SCDP client. A plurality of cable modems are then coupled to the cable node via radio frequency connections. Generally, 1
As many as 000 host personal computers can connect to one cable node via a suitable cable modem and high frequency connection. Each cable node is further connected to a terminating headend via a cable modem termination system (CMTS). Multiple cable modems are connected to one terminating headend. Multiple interconnected headends form the backbone of a broadband access network. These cable headends are typically located at the cable company's premises and also include host data terminal equipment connected to the Internet Protocol (IP) network via a T1 line or another connection. May be included. This T1 line is further connected to the Internet service provider (ISP) 230.
Can be connected to the Internet via. The RAFT server 206 and its associated database 208 are connected to the broadband access network 203 between the internet service provider 230 and the host data termination facility or headend provided by the cable company. In this way, the RAFT server 206, which forms a part of the SCDP system 200, is located remotely from the CAS 210, the e-commerce server 202, and the virtual shop show window 215. The cable modem termination system 209 uses the high frequency data from the cable communication facility to
The published data over cable service industry standard (DOCSIS) is applied to convert to the Internet protocol format.

Alternatively, as shown in FIG. 2A, a client personal computer may be connected to the SCDP system 200 via a digital subscriber line (DSL). In such a configuration, the host computer running the SCDP client is connected to the telephone company switch via the DSL modem and existing common switched telephone line facilities.

The structure of DSL subscriber networks and broadband access networks is well known in the field of the invention and is currently widely used by cable companies and telephone companies, and is therefore described in more detail here for the sake of brevity. I want to refrain from that.
Thus, not all elements of the system described above are shown in FIG. 2A.

Subscription Procedure FIG. 2B conceptually illustrates the interaction of the components within the SCDP system 200. The flow charts of FIGS. 4A-4B, in combination with the conceptual block diagram of FIG. 2B, show the processing steps according to the present invention performed by the SCDP system 200 during a join process and a launch process.

SCDP running an HTML browser such as Netscape Navigator or Microsoft Internet Explorer on a personal computer
The user using the client 216 selects a title from the virtual store show window 215 as shown in step 401. In the store show window 215, each available title is displayed as a digital offer embedded within a universal resource locator (URL). This digital offer contains information identifying the selected title and purchase type. As shown in step 402, selecting the digital offer sends the subscriber's browser to the HTTP front end 202A of the e-commerce server 202. As shown in step 403, the user negotiates a purchase with the e-commerce server 202 based on the information in the digital offer URL. This negotiation usually involves user registration and provision of credit information.

As shown in step 404A, the e-commerce server generates a launch string containing information identifying and authorizing the purchase. This information includes a universal resource name (URN) that uniquely identifies the desired content. The format and description of this URN and launch string will be described later. The launch string is digitally signed by the CAS 210 and sent to the e-commerce server 202 for delivery to the SCDP client 216, as shown in step 404B.

The lunch string is MIME (multipurpose Internet message extension specification)
Packed with headers. As shown in step 405, when the launch string is received by the browser 224 of the SCDP client, it looks up the MIME type associated with the launch string in the registry entry, which results in the launcher module 220 within the SCDP client 216 being invoked. It will be. As shown in step 406A, launcher 220 uses CAS2.
It establishes a secure connection with 10 and requests that the CAS provide the URL of the specified URN, ie, the conversion of the URN to the URL. The URL specifies the position of the corresponding briq data. The CAS 210 sends the corresponding URL to the launcher 220. Once the launcher locates the corresponding briq data, as shown in step 406B, it sends a purchase request containing the launch string to the CAS.

As shown in step 407, the CAS verifies the launch string signature and returns the RAFT authorization token and activator to the launcher. The activator and authorization token will be described in detail later. The authorization token may be embedded inside the activator. Next, as shown in step 408, the launcher launches the title by passing the activator to the ARFSD VxD 218.
ARFSD / VxD executes the activator and issues the RAFT authorization token to RAF
Turn to T-VxD222. RAFT VxD is U as shown in step 409.
Open RL and read the header. The RAFT VxD 222 sends the initial authorization token to the RAFT server as shown in step 410. As shown in step 411, RAFT VxD 222 begins reading the content from RAFT server 206 and returns the received content to ARFSD VxD 218. Step 4
As shown in 12, ARFSD VxD uses bridging with an activator.
The contents of the data format are decrypted, decompressed and decompressed, and the blocks of decrypted data are integrity checked.

Thereafter, as shown in step 413, the operating system is ARF.
The title is executed via the local file system provided by SD VxD. The activator periodically requests the launcher 220 to cause the CAS 210 to update the activator and RAFT authorization token. As shown in step 414, when the first request is made, the CAS notifies the e-commerce server 202 of the purchase and the transaction is closed or complete. The life of the first activator may be several minutes. If the activator is updated properly after the first timeout, this indicates that this title has been successfully executed.

Having thus described the outline of the system components and their interaction,
The secure content delivery system 200 of the present invention and the processing performed therein will be described with reference to FIGS. 3A-14.

SCDP Client Referring to FIG. 3A, there is shown a conceptual block diagram of a SCDP client 216 according to the present invention. The SCDP client 216 allows a user to run a briq encoded title on the host personal computer. As shown in FIG. 3A, the SCDP client includes a launcher 220, an arepa file system driver VxD (ARFSD / VxD) 218, and a RAFT client V.
xD222 is included. The SCDP client 216 may be realized as an application that can be executed on the operating system 219 (for example, a Windows (R) application in this embodiment). As described with reference to FIG. 1, operating system 219 can execute on a personal computer architecture such as an IBM PC or other computer architecture. In addition to the SCDP client 216, a browser 217 (typically an HTML such as Netscape Navigator or Microsoft Explorer)
Browser) may run under the control of operating system 219. Launcher 220, ARFSD VxD 218 and RAFT VxD 222 will be described in more detail below with reference to FIGS. 3B-3D, respectively.

FIG. 3B conceptually illustrates a block diagram of a program logic module that includes the launcher 220 of the SCDP client 216. Specifically, the launcher 22
0 is the control module 300, CAS / RPC library 302, ARFSD /
It includes a VxD communication library 304 and a user interface 306.
In the illustrated embodiment, the launcher 220 may be implemented as a Windows application that includes logic that coordinates all communication between the SCDP client and the CAS 204. When the purchase negotiation with the e-commerce system 202 is completed, the launcher 220 is called by the web browser 217 of the client.
The e-commerce system is a MI related to the launcher for the client / web server.
Send a lunch string with ME type. Furthermore, the launcher manages all communication with the CAS, but for that communication 1) obtains the address of the RAFT server from CAS and the briq path name corresponding to the selected title, and 2) retrieves the briq data from the RAFT server. Then, the RAFT authorization token and the activator necessary for decrypting the retrieved data are obtained from the CAS, and 3) the RAFT authorization token and the activator are requested to be updated to the CAS.

The launcher 220 includes a CAS / PRC library 302 to facilitate communication between the CAS server 206 and the ARFSD / VxD module 218. This library is the CAS server 2 via the remote procedure call (RPC) library.
It can be realized as a series of objects or program code that communicates with 06. A suitable RPC library for module 302 is the Noblenet Secure RPC product marketed by Noblenet. As an option, a network transport product conforming to the Secure Socket Library (SSL) standard issued by Netscape Communications, Inc. is used to transport RPC calls on the network to ensure communication safety with the SCDP client in the system of the present invention. May be improved. The communication library may be used for communication between the launcher module 220 and the ARFSD VxD module 218 and between the ARFSD VxD module 218 and the RAFT client VxD 222. Such a library may include the code or objects required for data communication between launcher 220 and VxD 218. For example, as will be described in detail later, the briq header 1202 of the briq 1200 is read by the control module 300 during execution of the title as shown in FIG.
To VxD 218 via.

When the launcher 220 is called, the graphic user interface (GU
I) is displayed to the user via the user interface 306. In the illustrated embodiment, the user interface 306 creates a window, displays graphical information within such window, and receives a Windows operating system to receive commands from the user via a keyboard, mouse, or other positioning device. It includes appropriate program logic and / or objects to interface with operating system interfaces and application program interfaces (APIs) included in the system. Also, such a user interface is well within the comprehension of one of ordinary skill in the art. Through this GUI, the user can make user-preferred settings such as the disk cache size and the error status is also notified.

The control module 300 may be implemented with code or objects suitable for launching titles and executing the algorithms necessary to continue communication between the SCDP client 200, CAS 210 and RAFT server 206. More specifically, the algorithms executed by the control module 300 are described in more detail in Figures 4A-6 and the related portions of this specification.

FIG. 3C is a conceptual block diagram of the ARFSD VxD 304 of FIG. 3B. V
The xD 304 includes a bytecode interpreter 308, a control module 304, and an ARFSD VxD communication library 312. ARFSD ・ VxD3
A virtual device driver 04 allows the operating system to read the briq data as a local file system. ARFSD ・ VxD3
04 decompresses and decrypts the briq data. Furthermore, ARFSD / VxD
It holds the installation abstract (language: abstract), for example by providing Windows registry entries. ARFSD VxD implements dynamic registry entries by simulating registry entries related to titles that are intercepting all operating system access calls and executing but not being saved to disk.

Activator and Bytecode Interpreter As described above, the activator 228 executes on the bytecode interpreter 308 implemented within the ARFSD VxD 304. The activator is a part of the SCDP client software which is obtained from CAS 210 and used for deciphering briq data by ARFSD / VxD304. The format and contents of the activator will be described in detail with reference to FIG. Activator is CAS21
Implements a holding function that asks the activator to periodically request a new activator to replace 0. Therefore, communication with the CAS must be maintained in order to continue title execution. In the illustrated embodiment, the activator 228
The retention mechanism within may be implemented as a numeric string or as described with reference to FIG.

The activator is implemented as a dynamic bytecode object that can be executed within the ARFSD VxD 304. As previously described with reference to activator factory module 710 in FIG. 7, CAS creates an activator by calling an activator creation routine that may reside in an external library. The RAFT token is packaged with the activator as described above. The activator will eventually time out, and then the SCDP client 21
6 must call CAS and request a new activator. The life of the activator is determined by the start and end time values contained in the token portion of the activator.

The SCDP system 200 uses the activator to activate the SCDP client 2
The encrypted data passed to 16 is protected. Activator is ARFSD / VxD
It can be implemented as a piece of obfuscated bytecode that runs inside 304 and allows the decryption of briq. Once the activator is downloaded, CA the additional RPC
The transmission of the keying data may be completed by performing S210. Key extraction can be prevented by code ambiguity in the activator.

The illustrated implementation of the activator uses remote execution to protect the keys in the activator. Remote execution makes the activator incomplete. That is, remote execution provides enough information for the activator to operate continuously, but the activator needs to request new code or data. ARFSD ・ VxD304
A bytecode interpreter 308 within contains the program logic, code, or object that extracts the cryptographic key data from the activator. In the illustrated embodiment, the activator may have the form and content as described with reference to FIG.

Another embodiment uses a more sophisticated implementation of the activator where the activator includes an obfuscated bytecode, but the bytecode in ARFSD VxD304
Interpreter 308 may be implemented with a rich instruction set to increase the chances of simplifying ambiguity. Many bits can be used for addressing schemes and instruction formats without the conventional limitations of hardware-implemented microprocessor instruction sets. Due to the complexity and confidentiality of these instruction sets, SCD
Ensure the safety of content delivery within the P system. Bytecode is VxD
To run in, the bytecode interpreter 308 may call interfaces exported from other VxDs, but does not need to call WIN32 functions from the operating system or handle DLLs.

In the illustrated embodiment, the bytecode interpreter 308 is a CAS
It is implemented as a virtual machine with the appropriate code and / or program logic necessary to interpret and execute the bytecodes in the activator received from 210. Such virtual machines have appropriate paths for translating bytecodes, storing all temporary data from the bytecode stream, and performing the operations specified by the bytecodes. How specifically the bytecode interpreter 308 is implemented therefore depends on the bytecode set executable by the interpreter. For example, the bytecode interpreter 308 can perform certain functions, including some of the following to accommodate the type of code the activator contains. Bitwise Operators-Fixed digit, rotate, and "bit extract" functions useful for encryption and sequencing routines. Evaluation-Causes the bytecode interpreter to interpret the downloaded or modified bytecode, thus preventing the code and data from being separated from the corresponding flags and data protection. • Interface primitives (language) -The SCDP client bytecode interpreter directly calls functions in other VxDs, including argument arraying and internalization of certain predefined datasets of C type. SCDP
The client and CAS use secure stream interface primitives.
For example, a hook that extracts connection data (especially authentication data) from the stream in which the activator or method was generated.

Those of ordinary skill in the art will appreciate that bytecode interpreter 308 may be implemented as a physical computer. In the simplest activator described here, bytecode is optional. Therefore, the bytecode interpreter 308 may also be an option.

The communication library 312 includes an ARFSD / VxD module 218 and a RAFT / VFT module.
Used for communication with the VxD module 222. Such a library is similar to the communication library 304 of FIG. 3B and facilitates communication between VxD218 and VxD220.

The control module 310 executes the installation abstract, executes the title,
And it contains the program logic or code necessary to execute the algorithms needed to update the RAFT token. More specifically, the control module 31
The algorithm executed by 0 is described in more detail in FIGS. 4A-6 and the associated description.

FIG. 3D shows the RAFT client VxD 222 of the SCDP client 216.
FIG. 3 is a conceptual block diagram of a component including a. For details, VxD222 is RA
It includes the FT / RPC library 316, cache logic 318, and control module 320. The RPC library 316, which is described in more detail herein, contains appropriate code and / or objects that implement the client-side RPC layer of the RAFT protocol. Such program logic is
Used to communicate with RAFT server 206 using any of the T messages. Specifically, the module 316 attaches the RAFT packet header to each RAFT protocol message, as described with reference to FIG.
Contains the logic necessary to respond with an FT protocol message. The cache logic 318 includes suitable code for caching the briq snooped from the RAFT server 206, or a portion thereof, using the RAFT protocol. The portion of briq cached by module 218 may be stored in a portion of the temporary memory of the host personal computer running SCDP client 216. Specific cache techniques and associated logic are
It can be implemented according to a number of well known cache algorithms, which will be readily apparent to one of ordinary skill in the art. The control module 320 is the module 3
16 and 318 are implemented to include the program logic, code and / or objects necessary to manage the functions described above with respect to 16, 318 and to perform the method steps described in connection with FIGS. 4A-6.

Title Execution The flowcharts of FIGS. 5A-5C show the processing steps performed by the SCDP client 216 during an exemplary title execution in accordance with the present invention. As described above, when the SCDP client browser 224 receives the launch string, it launches a multi-purpose Internet message extension specification (MI) associated with the launch string.
ME) type is found in the registry entry, which results in the launcher module 220 in the SCDP client 216 being invoked. As shown in step 6, when a call occurs, the launcher 220 extracts the Universal Resource Name (URN) from the launch string and requests the CAS 210 to convert the URN to the URL. The URN of the present invention is the unique identifier of the title within the briq. The standard URN format is as follows: urn: arepa: // vendor / path / titlename [#version]

In URN, the path to the title does not have to exactly match the title's current location in the vendor's storage server. This path is for convenience of classification and is not necessary. The title version number is optional and may be separated from the title name by a pound sign. Vendor names may be registered with a central authority to ensure uniqueness.

The Universal Resource Locator (URL) identifies the current location of the briq within the RAFT storage server. The standard URL format is as follows. raft: //hostname/path/briqname.brq

In the URL, the path must exactly match the current location of briq in the RAFT storage server.

5A-5C show the processing steps performed by the SCDP client and internal modules during subscription and title execution according to the present invention. Referring also to the elements of FIG. 2B, the user of the host computer running the SCDP client uses the web browser 224 to select the desired title from the virtual store show window 215. The store show window 215 returns the digital offer to the web browser, and the user uses this offer to negotiate a purchase with the e-commerce server 202. The e-commerce server sends the unsigned launch string to the web browser over the network. The lunch string is packed with a MIME header. As shown in step 502, when the launch string is received by the browser, the MIME type associated with the launch string is located in the file system registry entry, which results in the SCDP client launcher module 220 being invoked. become. The launcher module 220 extracts the URN value from the launch string and sends the URN value to the CAS server 210, as shown in process step 504. Communication between the launcher 220 and the CAS 210 is established via a secure RPC connection. The CAS 210 converts the URN into a URL and sends the URL to the SCDP client. When the URL is received, launcher 220 passes the request to read the URL header to ARFSD VxD module 218, which passes the request to RAFT client VxD 222, as shown in decision step 506. VxD222 is RAFT
Send the request to RAFT server 206 using the protocol. The RAFT server 206 opens the URL and reads the header information. The header information is then
To RAFT client VxD222 and to ARFSD VxD module 2
18 and launcher 220. This entire process is the processing step 50 of FIG. 5A.
8 is shown. Next, as shown in process step 510, the launcher module 220 uses the contents of the header to execute the application inspection request of the host system.

After completing the system inspection request, the launcher module 220 sends a purchase authorization request to the CAS 210 via the secure RPC connection, as shown in process step 512.
Send to. In response to the purchase authorization request, the CAS 210 creates an activator containing the RAFT token, and the activator sends S over the secure RPC connection.
It is sent to the CDP client 216. Upon receiving the activator as shown in decision step 514, launcher module 220 installs the RAFT token and activator as shown in step 516. As shown in process steps 516 and 518, respectively, the activator is the ARFSD.
Installed in the VxD module 218, the VxD module 218
Load the AFT token into RAFTVxD. The RAFT VxD 222 then sends the RAFT token to the RAFT server 206 using any of the appropriate instructions from the RAFT protocol, as shown in process step 520. Next, as indicated by process step 522, the ARFSD VxD 218 returns the VxD
The superblock field is read from the briq at RAFT server 206 via communication with 222 and the magic number in the superblock is checked, as indicated in process step 524. The magic number in the briq is a fixed character string (original: constant sequence of charact) such as "ARFS".
ers).

At this point, launcher module 220, as shown in process step 526.
Starts executing the title executable. In the illustrated embodiment, the executable file is ARFSD using data obtained via RAFTVxD222.
It is in the form of a Windows (R) executable file located in the file system realized by VxD218.

As shown in process step 528, RAFT VxD 222 initiates a search of the title directory and files from RAFT server 206. The data blocks containing the title directories and files are obtained from the RAFT server 206 using the RAFT protocol and the commands described herein. Specifically, the VxD 222 obtains a data block from the RAFT server 206 in a read-ahead manner, and caches the data block to facilitate efficient decoding and execution.

As shown in process step 530, the ARFSD VxD 218 decrypts the data block obtained from the RAFT server 206 using the activator retrieved from the CAS activator 210, in particular the decryption key data, and an integrity check. I do. As mentioned above, the activator contains a cipher or information that helps to decrypt the data in the briq prior to execution. As shown in process step 532, the ARFSD VxD 218 holds an installation abstract for the operating system to create the illusion that the file system needed to execute the title is installed on the local host personal computer. . The process in which the VxD 218 holds the installation abstract will be described in detail with reference to FIG.

The RAFT token received from CAS 210 includes an end time field as described with reference to FIG. Decision step 534 and processing step 53
As shown in FIG. 6, the launcher module 220 requests the update activator and RAFT token pair from the CAS server 206 via a secure RPC connection before the activator and RAFT token expires or becomes invalid. As shown in process step 538, this new activator and RAFT token pair is installed and used in the same manner as described above.

Installation Abstract According to the present invention, titles are never “installed” on the SCDP client host system. The SCDP client software creates an installation abstract, maintaining the illusion to the local operating system that the running title is installed on the host computer. Therefore, when the title execution ends, there is no evidence that the title has been executed on the host personal computer. No files associated with the title will remain on the host system's hard disk, nor will operating system state information, such as registry variables associated with the title. The status of the SCDP client after the title appears or after the system crash is the same as before. The only unlikely exception is due to changes made by the user to the application, such as, for example, processing done by other applications, persistent state and saved documents or data. The installation abstract is accomplished by loading the expected application state before running the application, which is unloaded when the application exits without affecting the persistence parameters. To be done.

As described in connection with FIG. 12, each briq according to the present invention includes a file system for one or more titles. As explained below, briq
The author uses the author utility program to extract the selected files from the application and application installation directory. The briq author also extracts other information such as registry entries that may be needed to run the application correctly. The author program combines the selected file with other information and produces a file system in the database entry set and briq format as output. This briq is R
It is stored in the AFT server. The database entry is stored on the CAS server,
It includes information such as keying information and header checksum value.

FIG. 6 is a flow chart showing the processing steps performed by the SCDP client 216 and the embedded modules 218-220 to retain the installation abstract during title execution according to the present invention. As shown in step 600, following a title selection and purchase negotiation, launcher 220 and A
The RFSD VxD 218 mounts the file system and stores the associated registry entry in the host system's local drive, as shown in step 602. The functionality within the file managers of Windows® 95, Windows® 98, and Windows® NT and the equivalent functions of the UNIX® operating system “mount” the contents of file directories and remote location files. , Or access them via a computer network and create a “virtual drive” to access the data. In the present invention,
Mounting the file system involves using the techniques described above to access the RAFT server via the SCDP client operating system interface. Mounting the file system may result in caching all or part of the data block from the briq containing title content and registry entries associated with that title. This set of registry entries is stored locally in the SCDP client's host system memory and may include information such as the directory where the title file was installed. The ARFSD VxD 218 also extracts the appropriate database item from the CAS database 212.

Using the keying information from the activator sent by the CAS server to the SCDP client, as shown in step 604, the data block from briq is decrypted and executed as an operating system file system. During title execution, data blocks are cached locally at the SCDP client as needed. During program execution, operating system device drivers, such as those contained within the virtual memory manager portion of the operating system, request registry entries stored on a local physical drive. When the application is executed, the ARFSD VxD 218 begins interpreting these processing requests, as shown in decision step 606. If so, the call is satisfied with an entry from the list of locally stored registry entries, as shown in step 608. However, some information is written directly to the operating system using the write-through method described below.

As shown in decision step 610, interception of operating system calls and satisfaction of these requests with locally stored registry entries continues until application execution is complete. At this point, the launcher instructs the ARFSD VxD 218 to unmount or disconnect the file system, as shown in step 612. As a result, operating system requests will not be forwarded to locally stored registry entries. Locally stored registry entries and locally cached data blocks may be erased or overwritten. As a result, the title, that is, S before executing the application
The state of the CDP client is returned to the current state without any trace of installation of that title, except for the limited write-through data that the user consciously desires to hold.

Write-Through Local Storage Files and directories can be tagged with the “write-through” attribute when the briq is created by the author using the creator program. A briq containing a write-through file or directory may contain a container with a LOCL tag. This container contains the complete path of all write-through directories and the path of any directory (except the root directory) that contains a write-through file, as indicated by the LDIR tag. The user can specify the pathname of the root directory for local storage files. The new pathname includes a vendor field from the URN to ensure uniqueness. This information is stored in the ROOT tag in the title's LOCL container. By default, ARFSD VxD will report 0 bytes free on the local drive. A briq that does not include a write-through file or directory will always report 0 bytes free. The presence of the tag in the title's LOCL container indicates that ARFSD VxD should report the amount of free space on the drive containing the local storage directory. Titles need a LOCL container only if they need to specify something other than a fault value for ROOT.

A briq containing a write-through file or directory (in other words,
When briq) including the LOCL container in the header is loaded, the launcher in the SCDP client creates a directory for local storage under the SCDP installation directory. This directory is derived from the URN unless another directory is specified by the ROOT tag in the title's LOCL container. The launcher creates a subdirectory in the local storage directory for each directory specified with the LDIR tag in the header. Pass the root path name of the local storage path and whether to report free disk space to ARFSD VxD during briq load. When the launcher software is uninstalled and optionally the title appears, all files in local storage are erased. These locally stored files are persistent by default. The launcher needs to create directories in local storage for all write-through directories in briq.

When a write-through file is started, the information is retrieved from the file in a local storage area with a naming convention similar to the directories mentioned above. If the file does not exist in local storage, the file is first copied from briq. The original file in the briq may not be compressed or encrypted, except for all briq encryption. Opening a write-through file also opens a copy of the local disk, and all requests on the ARFSD VxD file handle are performed on the real file handle.

Conditional Access Server (CAS) FIG. 7A is a conceptual block diagram of a conditional access server (CAS) 700 and associated database 750. In the illustrated embodiment, CAS is POSIX.
． 1 (IEEE Standard 1003.1, 1998) compatible applications that can be run on platforms (eg, Sun Solaris ™ from Sun Microsystems, Inc. of Palo Alto, Calif.)
Operating system or the Linux operating system commercially available from Red Hat Software, Inc., and such a platform can run on a computer architecture similar to that shown in FIG.
The CAS application 702 includes a database interface module 704, a remote procedure call interface 706, a URN-URL conversion module 708, an activator factory 710, and a URL verification module 71.
2 is further included.

The database interface module 704 uses the CAS database 750.
It may be implemented using a commercially available database product.
The database 750 is used to store short-term stay data, such as stay data for tokens requesting renewal, or long-term stay data, such as title name, cryptographic key information, and other information about the title available via the SCDP system. You can If there are multiple CAS servers on the network, the database 750 may be shared by multiple CAS servers 700. Database interface 704 and database 750 communicate in the SQL standard database query language. The SQL standard is published by the American National Standards Institute (ANSI). The database interface 704 contains a set of objects that filter the queries received by the server 700. These filters help narrow and customize database queries.

The CAS server 700 is connected to the rest of the SCDP system via a network 205, which in the illustrated embodiment is a network based on the Internet protocol implemented as a local area network or a wide area network. The server 700 is a remote procedure call module 706.
Interface with the network 205 via. Module 706
Open network computing remote procedure call standard issued by Sun Microsystems, Inc. (R published by the Internet Engineering Project Team)
It may include a code or an object conforming to FC1057). These RPC standards define code that controls the flow and function calls between two entities attempting telecommunications over a network. Module 706 may be implemented using any commercially available tool that makes remote procedure calls look like subroutine function calls. One example of a product that may be useful in implementing module 706 is the Noblenet Secure RPC sold by Noblenet, Inc. of Southborough, Mass. Noblenet Secure RPC provides an additional safety layer over the regular RPC interface.

The URN-URL conversion module 708 stores the URN inquiry in the database 75.
Contains a code or set of objects that returns a corresponding URL when it receives 0.
Such a URN is received via the network 205 from the launcher module of the SCDP client. The database 750 in which the URN is stored may be a sequential database with multiple records. The module 708 sends the appropriate query to the database interface 704 and sends the appropriate URL from the database.
To receive. The module 708 then sends the corresponding URL to the SCDP client via the RPC module 706 over the network. Alternatively, in an environment where the number of titles and / or content servers is limited, the URL
May be stored on a disk associated with the server, and further module 708 may include program logic to perform lookup table translation of the received URN.

The translation module 708 translates the abstract URN data structure into an absolute URL data structure and may be implemented by a series of translation tables and associated comparison logic. The URL verification module 712 includes code or an equivalent object that receives the launch string from the e-commerce server 202 and the time stamp that the launch string digitally signs with the hash code and the encryption key. Specifically, the message authentication code may be added to the launch string received from the CAS server 700. The message authentication code may include a hash code generated based on the MD5 hash algorithm, and may further include an encryption key generated according to a plurality of encryption standards including a data encryption standard (DES). . As described herein, the digitally signed launch string is then sent to the e-commerce server 202 and further returned to the client host system's web browser.

In the SCDP system, the activator serves to send keying information to potentially insecure client processes. Activator generation module 710 of server 700 contains code or a suitable object that generates a sequence of bytecodes and attaches an encryption key to the sequence of bytecodes. In one implementation, this key is retrieved from database 750. The implementation of the activator generation module depends in part on the sophistication of the activator used in the SCDP system. Activator generation module 710 is implemented as described above for activators that include a series of bytecodes and keys appended or integrated therein. In another embodiment, the key is integrated with the activator in a more secure manner (eg, folding the key into a bytecode sequence), and additional logic and / or objects implement such functionality within module 710. Needed for. For example, instead of appending a key to a series of bytecodes, a bytecode sequence that performs certain functions such as generating numbers or performing other logical operations may be inserted within the activator. In such an embodiment, module 710 may include a logic or code ambiguity technique described herein as a random selection of any of a plurality of bytecode sequences. In these illustrative examples, module 710 provides the ability to randomly generate activators in a highly secure manner. Alternatively, in a more sophisticated activator implementation, activator module 710 can call an activator generation routine that can also reside in an external library to generate the activator.

The CAS module described above contains five main functions within the SCDP system. First, CAS provides a cryptographic activator that allows users to use encrypted briq content only once. Secondly, by CAS, SCDP
The system reliably and accurately tracks the use of titles, and also reliably supports a safety model where it is extremely difficult to develop a hacked client designed for abuse. Third, CAS provides a limited life RAFT authorization token signed with a CAS private key and attached to the activator. The RAFT client includes the RAFT request in the authorization token. The RAFT server uses this token to verify that the client has the right to access the requested content. Fourth, CAS interacts with the e-commerce server software and billing system to complete the transaction. The transaction does not complete during the purchase negotiation and does not occur until CAS confirms that the end user successfully executed the content. First
The end of the activator update indicates that the title has been successfully executed. 5
As a second function, CAS maintains a database for title usage reporting and activator tracking.

Three types of progress records are associated with CAS. First, CAS activities are standard UN
Recorded in the IX (R) Text Progress Record. This log is intended for diagnostic purposes only. Second, CAS will be able to trade transactions for reporting and activator tracking purposes.
Record in AS database table. These records are separate from the records by the e-commerce server system used for actual billing purposes. Third, the CAS database itself keeps track of internal processing and its function is to ensure that database processing is completed and rolled back. Such functionality may be internalized in the CAS database. In the illustrated embodiment, CA
S uses commercially available database maintenance software, such as that available from Oracle Software, to verify whether the purchase process was done or rolled back. Database processing is different from the financial processing described above. The financial process may be a database process, but many other processes such as updating a user name can be a database process.

In the illustrated embodiment, the CAS indicates to the system administrator the status of the CAS (eg, the number of database connection threads currently in use and the current number of user connections, ie, the connection threads in use). Supports a management interface that can be monitored. Furthermore, statistical information such as the number of users and the peak number of database connections since the start of operation, and the number of times a user or database connection has reached a predetermined limit since the start of operation can also be used.

The SCDP client uses the client library to interact with the CAS.
The client library may be specific to each client platform because it uses a platform specific method of communicating with the SCDP client GUI. In the illustrated embodiment, that is, on the WIN32 platform, the client library is referred to as CASLIB32. The client library is a CAS interface class CC that indicates the transfer to CAS.
Export AS and CCasSession indicating a specific client session. The application program interface (API) allows CASLIB 32 clients to simultaneously negotiate multiple titles over multiple sessions. The API also exports additional classes that indicate information to interact with the CAS that serves to isolate the CAS interface from the details of the transport protocol. Such methods include CAActivator, CUr
It can be realized as l or the like. CCAS also sends a Windows message and responds asynchronously to the client.

Activator Support with CAS The simplest implementation of an activator is a bytecode routine that compiles the key of a given briq into an activator. In this activator implementation, the CAS authenticates the client, identifies the purchased briq, builds the activator bytecode, and downloads the activator. SCD
The P-Client then closes the connection and executes the title. Such activators may be generated in advance and retrieved directly from the database by the CAS activator factory 710 and interface 704.

In a more advanced activator implementation, the activator recognizes the cryptographic algorithm and requests the key from the CAS. The CAS has received authentication information and security data from the existing stream and can provide a given RPC response to the "request key" with any required arguments.

In another implementation, the activator may comprise arbitrary code for a novel mechanism that may require multiple stages. As described below, the activator CAs remote procedure calls with opaque arguments and with "technique" specified.
You may call S. The CAS then sends this opaque data to this technique, which returns the opec data to the client or makes another call or call to another service. If CAS Confidence has an interpreter,
The CAS can retrieve the activator and technique codes from the database. There can be many activators for any technique, provided all activators are pre-generated. Alternatively, the CAS may maintain a database of rule sets on how to combine obfuscation and many obfuscation examples.

The CAS selects the appropriate activator for a given client, product or purchase. The CAS delivers the activator and "supports" the activator via an additional RPC. Many CAS RPCs can be pre-defined, for example a simple "request key" for a given briq. Such RPCs can be limited based on the activator selected. For example, most clients use the simple "
It is not allowed to make "request key" calls, but it is necessary to make any calls the technique expects to be used by the activator.

Referring to FIG. 7B, the process steps performed by the CAS server 700 during the subscription and title execution process are shown. Specifically, the CAS server 700 is shown in FIG.
And the description associated therewith, the launch string is received, but the source is an e-commerce server, as shown in step 720. next,
The CAS signs the launch string, as shown in step 722. CAS
"Signs" this launch string with a private encryption key. Processing step 724
The signed launch string is then sent from the CAS server 700 to the SCDP running on the host system connected to the broadband network, as shown in FIG.
Sent to client. As described in connection with FIGS. 5A-5C, SCDP
The client extracts the URN from the launchstring and uses this URN to CAS70.
Send to 0. The CAS 700 sets this URN to S as shown in step 726.
Received from the CDP client and, as indicated in process step 728, the URN
To URL is converted. As described above, the CAS 700 includes the module 70.
8 is used to perform this URN-URL conversion. Such conversion is done in database 750
, Or use a table lookup algorithm, depending on how module 708 is implemented. As shown in process step 728, CAS
700 sends the URL list to the SCDP client. The CAS 700 then receives an authorization request from the SCDP client, as shown in process step 730. This purchase authorization request from the SCDP client includes a launch string. Then, as shown in process step 732, the CAS 700 validates the launch string to see if this launch string was previously signed by itself.
In the case of an implementation including a plurality of conditional access servers, it is determined whether another authorized server has signed. Activators are generated according to how the CAS server module 710 is implemented, as described herein.

As shown in process step 736, the CAS 700 then sends the RAFT token and activator to the SCDP client. The CAS 700 retrieves the RAFT token from the database 750. This RAFT token has the format described herein and shown in FIG. As described herein,
The activator and RAFT token allow the SCDP client to access the desired title and begin executing title data. At this stage, as shown in decision step 738, no action is taken on the SCDP client until an activator token update request is sent from the SCDP client. Upon receiving the first update request from the SCDP client, the CAS 700 notifies the e-commerce server of the title purchase, as shown in process step 740. The notification to the e-commerce server for this transaction includes the actual response record indicating that the user has paid for this particular title. Title is SCDP
No such notification is made until the first update request is made on the client indicating that it is executing correctly. The timeout mechanism in the activator originally sent by the CAS to the SCDP client expires or expires after a predetermined period of time, indicating that the title is performing properly. The CAS issues a new token and sends this pair to the requesting SCDP client, as shown in process step 742. The life of the RAFT token may be longer than the life of the token originally sent to the SCDP client with the activator, as indicated in the RAFT token start and stop time fields. Even if there is a subsequent activator / token update request from the SCDP client, the CAS
Does not notify the e-commerce server of the title purchase. As mentioned above, S
Since all communication between the CDP client and the CAS is over a secure RPC connection, such a connection may be established using commercial products that comply with the RPC standard.

As will be appreciated by those of ordinary skill in the art, the process outlined in FIG.
CAS in a relationship with the SCDP client that ends with the end of title execution
It focuses on the steps performed by. It will be apparent to one of ordinary skill in the art that the CAS can be implemented as a multitasking application in which several different threads concurrently execute various steps of the illustrated process. Therefore, the CAS satisfies the demands of a particular SCDP client, while at the same time other SDP clients
The request from the CDP client can also be dealt with.

RPC Transport CAS and CASLIB 32 communicate via a remote procedure call library based on standards such as Noblenet Secure RPC. SCDP client is CA
Multiple calls to S are made synchronously, and CAS assigns these calls to threads for processing. CASLIB 32 is a G with an asynchronous interface
It provides to the UI, which queues these synchronous RPC requests and retrieves them from the background thread. To provide high processing power, CAS prepares and pools threads that can be used for task execution. This thread pool is a reusable C ++ class. Incoming tasks are captured at the RPC layer,
It is put in the queue of the thread pool, and eventually it is processed by the thread instead of the inclusion process. The thread pool allows CAS to handle concurrency more efficiently and improve performance under short load spikes. RPC calls need to allocate thread-safe memory that can be released after tagging, because buffers cannot be released until the RPC transport has sent them. CAS uses a reusable C ++ memory pool class that can erase memory by thread ID.

The CAS may be implemented as a stateless server such as a web server. Stateless servers have the advantage that more server machines can be deployed and incoming connections can be easily expanded with "brute force" software that distributes to these servers. This is because the request after the SCDP client does not have to go to the server to which it originally connected. CAS
Maintains a connection socket TCP stream between requests so that information such as transport session keys can be attached. When this connection is cut, CASLIB32
Will attempt to reconnect to another CAS process, so it is preferable to push the state to CASLIB 32 or into the database.

To increase throughput, CAS is designed to use a pool of active multiple database connections. Server threads request connections from the pool, reconnecting dead connections in the background as necessary to minimize database connection latency. The database connection pool is implemented as a reusable C ++ class. CAS uses an abstract database interface called DBOject, which is implemented as a reusable C ++ class to facilitate porting CAS to other databases.

RAFT Token To improve the overall safety model of the SCDP system, the CAS
Give the PClient a signed RAFT authorization token. This RAFT token allows a particular SCDP client to access a particular URN for a predetermined time. The CAS digitally signs the RAFT token using a standardized public key digital signature algorithm. In order to access the executable content of a RAFT server, RAFT VxD must pass its token to that server. The RAFT server verifies the CAS digital signature and then verifies the content of the token. The RAFT token 800 is valid for any number of RAFT servers within the CAS administrative domain, in other words,
Broadband service providers can install multiple servers on their network, and RAFT tokens will be accepted by any of them.

In the illustrated embodiment, the RAFT token is implemented in a data structure with the format shown in FIG. The RAFT token 800 is a URN, a URN length 804,
Start time 806, end time 808, IP address 810, and CAS signature 812
Includes. The URN 802 and associated length 804 define the particular title that the RAFT token unlocks. Start time 806 and end time 808 define the life of the token. The format of this URN has already been described. The RAFT authorization token contains the IP address of the RAFT client 32 in network byte order.
Include as bit value. This token also contains the requested URN and 32-bit start and end times. These times can be found in POSIX 1003.1-1988, "Seconds from the beginning of the new era," or roughly January 1, 1970, Greenwich Mean Time 0.
It is defined as the number of seconds since 0:00:00. The CAS signs the token with the private key of the CAS group so that the RAFT server can verify the authenticity. RAF
The T server denies access if the current time of the server is not within the token time zone. The IP address defines the network address of the SCDP client requesting the activator / token. If the SCDP client that submitted the token does not have the same IP address, the RAFT server denies access to prevent the token from being used illegally by other clients.

The RAFT token is sent to the client as part of the activator.
The RAFT token is updated with the activator. The activator is constructed based on a life-limiting mechanism. The SCDP client issues a CAS request via the RPC mechanism to update the activator-token pair before the current activator becomes invalid or expires.

Random Access File Transfer Protocol and Server FIG. 10 conceptually illustrates a block diagram of RAFT server 1000 and associated database 1050. In the illustrated embodiment, the RAFT server 1000 is a POS.
IX. 1 (American Institute of Electrical and Electronics Engineers Standard 1003.1, 1988) as an application that can be run on a platform (eg, Sun Solas, available from Sun Microsystems, Inc. of Palo Alto, Calif.).
laris ™ operating system or the Linux operating system marketed by Red Hat Software, Inc.), and such a platform can run on a computer architecture similar to that shown in FIG.

The RAFT server can be implemented as a RAFT application 1002 and a simple network management protocol (SNMP) master agent 1004 running on the operating system. SNMP master agent 10
A suitable commercial product for achieving 04 is Emmanate available from SNMP Research, Inc. The master agent 1004 communicates with the network 205 using a published application program according to the SNMP standard.

The RAFT application 1002 is a POSIX (Portable Operating System Interface Standard) file input / output module 1006,
File system interface 1008, SNMP instrumentation module 1010
(Ie RAFT / SNMP subagent) and network / RPC / R
It includes an AFT protocol interface module 1012.

The SNMP instrumentation module 1010 contains objects or corresponding code that collects statistical and logistic information that is useful for system administrators to reduce network bandwidth and improve network performance. Module 1
Reference numeral 010 is an optional device of the RAFT server 1000.

The RPC RAFT protocol 1012 interfaces with an IP-based network 205 using the proprietary RPC protocol as described herein. Module 1012 contains the coats and / or objects necessary to implement this protocol and verify the contents of RAFT tokens.

The file input / output module 1006 may be realized in an object-oriented manner according to the POSIX standard 1003.1 published by the Institute of Electrical and Electronics Engineers (IEEE). The POSIX I / O module 1006 provides a local file system interface abstract to the memory disk 1050. The memory 1050 conceptually shown in FIG. 10 is used to store a plurality of titles in the briq format. In the present embodiment, the decoded briq header part and the encoded bri are
The body part of q is stored together. However, in these parts, the module 10
06 and 1008 are used to access each other independently. File system
The interface 1008 receives a request for a particular briq and
Contains program logic that maps briq into directories and files in memory 1050 where is stored. In this way, the file system interface 1008 uses the network requests and memory 1 from the SCDP system.
Functions as an interface with 050. In the illustrated embodiment,
The memory 1050 may be implemented as one or more disks such as a RAID disk array or disk farm. File system interface 10
08 functions as an interface between the file I / O module 1006 and the network protocol module 1012, and implements program logic for accessing files and briqs as described herein.

The SNMP master agent 1004 provides the SNMP protocol service on behalf of the RAFT / SNMP subagent embedded in the RAFT application. The RAFT application uses the SNMP subagent to make its management accessible to the remote SNMP manager.

The next few steps describe the interaction between the SCDP client and the RAFT server, where the launcher launches the title. Launcher is CAS
Contact the server to get the list of URLs corresponding to the requested URN. U
The RL determines the location of a particular briq (including the RAFT server where this briq resides). For each RAFT URL, weights may be returned to assist in the most appropriate URL selection. The higher the weight value of the URL, the more preferable.

Following the URN-URL translation by CAS, the SCDP client sends a purchase request to CAS as described in the CAS exchange description. In response to the purchase request, the CAS server provides the SCDP client with an activator containing the RAFT authorization token of the selected URN. The authorization token is valid for any of the multiple URLs associated with the selected URN.

The launcher then inspects the list of URLs to determine if RAFT URLs exist. If RAFT / URL exists, launcher is RAFT / URL
Send only the list of ARFSD and VxD along with RAFT access token to A
RFSD VxD sends this information to the RAFT client, the SCDP client RAFT VxD. The launcher also weights each of RAFT and URL. These weights may be different than those given by CAS in the URN-URL conversion. The RAFT client then establishes a connection with any of the RAFT servers specified in the URL list. RAFT client is URL
The client itself may include appropriate program logic to determine which RAFT server to contact first using the weights attached to the client.

After that, the RAFT client tries to open the briq on the RAFT server 1000. This client specifies the protocol version, pathname (from URL), and RAFT access token. The protocol version is RA
A 32-bit value used by the FT client and RAFT server to verify protocol compatibility. To confirm the legitimacy of access, RA
The FT server checks if the URN in the token is the one in the list in the briq header. The RAFT server 1000 checks the start and end times of the RAFT token when opening. If RAFT_OPEN is successful, the RAFT server returns the RAFT file handle and the unique ID of the briq used for caching, such as the hash of the briq tag.

In order for the RAFT server to check the expiration time, the RAFT server time is synchronized with CAS up to a predetermined interval. Therefore, the RAFT server will allow a start time earlier than the current time and will not deny access until the end of that interval. The token expiry time proposes the activator hold time plus varying network and server latencies.

When a subsequent RAFT read request is issued, RA is issued for each such request.
The FT server checks if the access token has expired. The RAFT server ignores the request unless there is a valid access token for that client.

The RAFT access token will eventually expire. The activator retention function of the SCDP client is responsible for obtaining a new RAFT token before the current token expires. This ensures that the RAFT token is updated in a timely manner and access failures do not occur under normal operating conditions. RAFT
When the client sends a token to RAFT server during RAFT_OPEN,
The RAFT client must calculate the token validity period from the start time to the expiration time. Since the RAFT client cannot confirm the validity of the contents of the token without the CAS public key, the RAFT client waits for RAFT_OPEN to succeed before setting the update time to confirm whether this token is valid. There is a need. However, the update time is based on the time the RAFT client received the token, not the RAFT_OPEN completion time. To ensure that the connection to the server continues, the RAFT client
Request a new RAFT access token from CAS prior to token expiration time. Upon receiving the new RAFT access token, the RAFT client
Send the RAFT_REFRESH process to the RAFT server along with the token you obtained.

When the RAFT client completes access to the briq, the RAFT client sends a RAFT_CLOSE message on the RAFT file handle.
If the connection between the RAFT server and RAFT client is broken, RA
The FT server will automatically close all open files corresponding to that connection.

RAFT Packet Header Definition For all communication according to the RAFT protocol, RAFT is used as shown in FIG.
A packet header 1100 is included. The RAFT packet header 1100 is
Procedure number data field 1102, sequence number data field 1104
, A packet length field 1106 and a status data field 1108. The procedure number data field 1102 is RAFT.
It can be realized in integer format by specifying the protocol message type. The sequence number field 1104 is used to match the response to the request and can be implemented in integer form. The sequence number is unique only for one connection. The packet length field 1106 indicates the size of packet data that does not include the size of the header, and can be realized in an integer format. The status field 1108 indicates the status from the RAFT request and can be realized in an integer format. A non-zero state indicates that the request has failed.
Different status codes are returned for different protocol messages. However, the zero state indicates that the request was completely successful. In the non-zero state, the packet length field is set to zero, which indicates that no packet data will be returned if the request fails. RAFT packet data follows the packet header according to the RAFT protocol.

RAFT Protocol Message The RAFT protocol consists of four different protocol messages that enable briq access and RAFT token management. Upon establishing a TPC connection, the initial RAFT protocol message includes this protocol version as one of its arguments to identify the requestor's protocol version. The list and description of RAFT protocol messages is as follows. RAF
The T_OPEN function is called with the protocol version, token length, RAFT access token, path length, and full pathname ending in NUL. If successful, R
It is the maximum read length supported by the AFT file handle, RAFT ID, and RAFT server. A SCDP client cache tag can be created using the RAFT ID. In case of failure, RAFT ID is multiple R
It may be a briq ID to achieve a consistent cache at the AFT server. The maximum read length is intended to inform the RAFT client of the amount of data that can be requested during RAFT_READ processing.

The RAFT_REFRESH_TOKEN function allows the RAFT client to update the RAFT server with a new RAFT access token. This function is called with the token length, RAFT access token, and RAFT file handle. Upon success, the new RAFT access token replaces the current token associated with the specified handle, prolonging the maturity time of the token.
If the new token is not valid, the current token is retained. This function returns no data, but the state in the header is updated to reflect success or failure.

The RAFT_READ function returns the RAF returned from the RAFT_OPEN call.
Called with T file handle, 64 bit offset and length. To access the requested data, the RAFT file handle must be associated with a valid access token.

The RAFT_CLOSE function is used to close an open RAFT file handle. This call takes a RAFT file handle and returns no data. However, the status of the header is updated to reflect success or failure.

Launch String FIG. 9 shows a launch string 900 according to the present invention. As shown in FIG. 9, the launch string 900 can be realized as a data structure including a URN data field 902, a store ID data field 904, a product type data field 906, a subscription domain data field 908, and an amount data field 910. The URN 902 uniquely identifies the desired content and can be further implemented as described herein. The store ID data field 904 identifies the particular store show window to the e-commerce system and may be implemented in a numeric string, alphanumeric string, or integer format. The store ID is used to separate transactions from different store show windows for reporting. If multiple stores really belong to the same organization, a single store ID may be shared. The product type 906 indicates whether the transaction is a subscription purchase or a micro transaction purchase, and may be realized in a numeric string, an alphanumeric string, or an integer format. The subscription process is for one-time payment and unlimited use of a title or set of multiple titles for a specified period. A micro-transaction is the amount charged to the user's debit account and is used to support the "pay-on-use" model. The subscription domain 908 indicates whether the transaction is eligible for purchasing a particular subscription offer such as "This Week's Hot Game Pack" or "Personal Business Application Package". Subscribed domain is a number string, alphanumeric string,
Alternatively, it may be realized in an integer format. Amount field 910 indicates the purchase amount of the micro-transaction and may be implemented in integer format.

As shown in FIG. 14, the contents of the launch string 900 are generated by the e-commerce server front end module 1408. The CAS uses the launch string 900 using, for example, a standardized public key digital signature algorithm.
Digitally sign the. Thereafter, the launch string 900 includes an additional CAS signature field 912 that identifies the private key of the CAS group. The launch string is sent to the SCDP client via the e-commerce system as a part of service work. The SCDP client sends the launch string back to the CAS during the pre-lunch negotiation with the CAS as described above.

E-Commerce System An electronic commerce software application suitable for use with the present invention (hereinafter E-Commerce System) is Transact 4.0, commercially available from Open Market, Inc. of Cambridge, Mass. E-commerce software is used to manage user accounts and execute financial transactions, eg 1) manage user account information, 2) manage purchases and payments, 3).
Used to collect and verify credit card information and 4) complete transactions.

Referring again to FIG. 2, the e-commerce server 202 contains a server application running on a computer architecture similar to that described with reference to FIG. This application is designed to run on operating systems such as Sun Solaris or other operating systems designed to run server-type applications. Referring to FIG. 14, the e-commerce server 14 includes a hardware platform 1402 running an operating system 1404. The actual e-commerce server application 1406 presents the front-end module 1408 and back-end module 1410 to various other components of the SCDP system 200.
Specifically, the front end module 1408 of the server 1400 can be implemented to present the web server front end to the SCDP system 200 via the network 205. These front ends are similar to other web servers currently on the Internet. The back end 410 of the server 1400 interfaces with the billing database 204,
It implements the logic and / or objects required to query the database and perform transactions and micro-transactions related to negotiations and title purchases. As described above, the e-commerce server 1400 can be connected to a bank or a third-party credit lending processing server that provides services such as credit card research and electronic credit filling via a wide area network such as a dedicated LAN or the Internet. The front-end module 1404 and back-end module 1410 of the server 1400 communicate via a series of scripts written according to the Common Gateway Interface (CGI) standard. It will be apparent to one of ordinary skill in the art that other commercially available e-commerce server applications can be used with the SCDP system other than those described herein.

Database 204 is associated with server 202 and may include a conventional serial database and is used to store credit and billing information necessary to proceed with a transaction.

The front end module 1408 of the server 1400 further includes code or objects to generate the launch string as described in more detail with reference to FIG. Once generated, the launch string is sent to the CAS server for digital signature.

In the illustrated embodiment, the e-commerce system includes a server and a store show window that work together to allow the user to navigate the catalog and accept and approve purchase information. E-commerce systems use an open web-based architecture to interact with external components. The SCDP system software module of the present invention communicates with the e-commerce software by notifying the web server front end of the e-commerce software with the URL. In response to this notification, Transact calls the CGI program with the particular arguments encoded in the URL. Evaluating a URL via a CGI call causes Transact software to change the state of the database. The entire processing sequence ends by simply evaluating a set of URLs. E-commerce systems capture and hold client data such as user billing or credit card information.

If the e-commerce system is a system equipped with a function that gives a commercial transaction capability to the store show window and can execute a credit card transaction via the web, the interaction between the CAS and the e-commerce system is mainly. It will take place in three different places. When a user purchases a title, the user receives a page called a "digital receipt" with a link called the service work URL included on it. This service business URL is actually a CGI program whose purpose is to obtain a launch string from CAS. As discussed in more detail below, the launch string is a collection of all the information that the CAS later needs to verify the user's rights to the software and terminate the process with the e-commerce system. This information is CA
Returned in a format that only S can understand, the CAS later inspects its own launch string. When the launch string is returned to the client browser, the browser
Launch the launcher inside the CDP client and pass the launchstring to the launcher. Later, the launcher can send the launchstring to the CAS to request the activator. The CAS will request the e-commerce server to inspect the launch string and, if the purchase is determined, to confirm success. But CA
S has not closed this deal yet. At this point, the CAS returns the activator to the launcher and the title execution is started. The life of the first activator is set to be short. For example, just before the first activator expires, the SCDP
The client VxD notifies the launcher and requests the CAS to update the activator. When the first update of the activator is executed, CASLIB
32 again provides the launch string, this time CAS completes the transaction with the e-commerce server. By postponing the completion of the transaction, the SCDP system can be sure that the title is running correctly on the SCDP client calculator before billing.

The SCDP system supports five different purchasing models. The first purchase model, "Title Subscription," allows unlimited access to a particular title for a given amount of time. The second purchase model, which is a package subscription such as "Arcade Game Pack", provides unlimited access to a set of multiple titles within a limited time. The title set included in these package subscriptions may change over time. For example, if a user purchases a "hot new game pack" subscription, the titles available in this package may change a week or two after the original subscription purchase. The third purchase model of "Payment per use" is
Provides one-time access for unlimited time. In the fourth "time-based billing" purchase model, the user is either billed according to title run time or can buy a particular block of time. In the 5th model of "monthly payment", SC
The DP system is integrated into the existing Multi-Server Operations (MSO) or telephone company billing system to add charges to the customer's monthly bill. Other purchase models can be added, including minor changes.

Virtual Store Show Window The virtual store show window server 215 and associated database 213
Present the virtual catalog to clients of the CDP system 200 and future clients. In the illustrated embodiment, the server 215 may be implemented as a conventional web server, such as a server application running on an operating system running on server hardware, as described in connection with the e-commerce server 202. It may be similar. The store show window application is
It includes a graphical user interface that displays a set of assortments that the client can search with a conventional network browser. Such an assortment may include a specific title name, a brief description of the title, cost or purchase options, and in the case of multimedia titles such as movies and audio clips, may include short samples of title content. Further, each title selection target is associated with a corresponding URN. The store show window implements the appropriate database query engine to interact with the database 213. Database 2
13 includes the title, description, fee, digital offerer, and URN information in SC.
It can be stored for a large number of titles within the DP system 200. In response to the selection of the particular title, the store show window application logic queries the database 213 for the appropriate URN and sends the appropriate information to the e-commerce server 202 in the manner described herein.

In the illustrated embodiment, as described above, the virtual store show window server 21
5 and database 213 is a dedicated secure local area network 205.
It is connected to the cache server 210 via. However, the SCDP system 200 may include one or more virtual store shows connected in a manner understandable to those skilled in the art to the cache server 210 and the e-commerce server 202 via a wide area network such as the Internet, rather than via a local area network. What can be accomplished with windows will be apparent to those of ordinary skill in the art. In these implementations, the store show window server is located on a public network, but various subsets of information may be visible to future clients. For example, a client paying a subscription fee may receive a greater amount of information and / or title data than the general public accessing a store show window server on a public network that may provide minimal information regarding titles and related purchase options. You may access a store show window server on a dedicated network that provides samples.

Briq Format FIG. 12 conceptually illustrates a block diagram of a briq and its components according to the present invention. As shown, the briq 1200 includes a briq header 1202, a cipher block 1204, a super block 1206, and one or more titles 12.
08A to 1208N are included. The briq header 1202 includes information used by the launcher module in the SCDP client, such as system registration information, resolution, application title, and URL. Cryptographic block 1204 is used by the ARFSD VxD in the SCDP client to identify whether the title is encoded and, if so, the cryptographic key version used for that encoding. The superblock 1206 can include general information about the briq, such as the briq size, the created data, the entry where the root directory exists. Titles 1208A-1208N may each include a directory and one or more files associated with a particular title. As explained herein, briq stores on the RAFT server and
It is remotely accessed by the SCDP client using the T protocol and presented to the host operating system as a local file system.

According to the present invention, one or more titles are processed and packaged in briq format, as described with reference to FIG. The process of converting the title to the briq format is as follows. First, a utility tool such as the Viewer utility in the Windows® operating system is used to extract the registry information from the title. These registry entries can contain the minimum set of information needed to perform a particular title, such as file names, directory names, and configuration citations. The extracted registry entries are put in a file. Then provide the author program with a file containing these registry entries. In this embodiment, the author program has the ability to take data containing titles and registry entries and encrypt such information according to any of the many encryption algorithms currently available. The resulting encrypted files are directories 1208A through 12 of FIG.
No. 08N is stored in the conventional directory hierarchy. Next, additional meta information including the root directory of this file system and the size of this file system is stored in the super block 1206 of the briq 1200 as shown in FIG. Information about the cryptographic key needed to decrypt the encrypted information in briq is then stored in cipher block 1204. The information in cipher block 1204 may include data identifying the key version and a description of the cipher type used. Information such as the briq URL and system requirements are placed in the briq header 1202 along with the name of the executable and title, a map of network drives and additional tags. As shown in FIG. 12, bri
The information contained in the q header 1202 is not encrypted.

Activator The activator has a format as shown in FIG. Specifically, the activator 1300 has a token 1302, permission data 1304, and an encryption key 1306.
, And optionally one or more bytecodes 1308-1312. In the illustrated embodiment, token 1302 is the RA described in connection with FIG.
It may be similar to FT token 800. The authorization data 1304 includes "hold" data used by the SCDP client when requesting a new activator from the CAS server. Such authorization data may be implemented as a simple sequence of numbers or code, or may be a more sophisticated and sophisticated implementation such as a hash of the data previously associated with the client. The key 306 contains cryptographic data useful for decrypting the data contained within the briq prior to execution. The decryption key 306 containing the encrypted data may include a string of bits extracted by the bytecode interpreter 308 and sent to RAFT VxD, which aids in decrypting the briq data.

In a simple example, activator 1300 contains only token 1302, authorization data 1304, and key 1306. In a more advanced embodiment, one or more bytecodes 1308-1312 are included. In the illustrated embodiment, the bytecode is essentially a group of instructions that can be executed by either a physical or virtual computer implemented as a bytecode interpreter 308. In the illustrated embodiment, the bytecode interpreter 308 comprises a virtual machine capable of executing such bytecodes sent by the activator. The types and properties of the byte codes 1 to N usable in the activator 1300 will be described later. Bytecode interpreter 308 has been described with reference to Figure 3C.

Code ambiguity The heart of a program can be broken down into flows and primitives. Normally, the flow is
It also includes building higher level abstracts from basic instructions. Optimizations include combining redundant primitives, reordering flows to combine and remove similar structures, and recognizing patterns and exchanging them for more efficient patterns. Be done. Optimization keeps the program running as specified in the original specification. The ambiguity process may also give one or more correct results. Generating all or a subset of the correct variants in parallel, rather than randomly selecting, is more costly but more efficient for individual generation.

In general, optimization involves finding solutions to problems and refining those solutions to obtain better solutions. In actual compilation, it means converting a simply generated correct expression of high level code into more efficient code while maintaining its correctness. The worst case can retain this accuracy, but at the cost of efficiency because it is difficult to decompile the obfuscated form.

Separation of the front end and assembler stage allows the insertion of worstifiers (pessimizers) at different levels and provides a high degree of flexibility in worst-case other high-end such as Lisp / Scheme. You can use the language later. Many worstification techniques can be used in the present invention, including 1) assembler-level peephole worstifiers that locally reorder and obfuscate the bytecode stream, and 2) are more natural for certain structural worstifications. A middle-level language worstifier that exposes a translation layer between a high-level language and an assembler that provides various interfaces, and 3) a plurality of functions that express a certain function instead of actually performing generic (generic) processing on the high-level language code. Is included in the coder, and then the coder causes the compiler to directly generate a form with combinatorial extensions of the alternatives already started.

Theoretically, someone could single step the activator and watch for changes made by the activator to find out how to break briq, or more simply, bri
It is also possible to stop once q is decrypted and dump the cleartext from memory. By using different bytecode sequences, written in a hard-to-translate "fuzzy" approach, and avoiding re-use of the same thing like a secret key, the present invention makes the work of a human decompiler difficult, Disable automatic analysis. The bytecode makes the work of one download of an unauthorized cracker arbitrarily time-consuming and makes it unavailable for other downloads.

Examples of ambiguity techniques useful for the activator of the present invention include:・ Choose from a large number of algorithms for each process, and select 2 for the same object
Make the code significantly different for the second request. Applying operation maintenance processing directly to bytecodes, for example using compiler optimization techniques. • Have the SCDP client support multiple bytecode sets or have the bytecode list itself as an encryption key. -Self-modifying bytecode. A “trapdoor” bytecode stream (eg, to generate a bytecode sequence) and a map function that picks a subset and maps the bytecode subject to a useful algorithm. You may need to define constraints and then look for useful sequences in space. "Dead code" bytecode as a distractor that may be related by pattern to existing code. -Do not use fixed bytecode. For example, the code has a different meaning in subsequent runs. (High-level tools can interrupt the work algorithm to generate them. This extension includes not using any instruction that refers to a particular position or register.) "Unary" operations used in cryptographic examples Child. Optimize the mapping of the code based on the parameters of the bytecode (eg frequency of use, decorrelation factor, etc.). Passing a partial key / schedule or code sequence to generate a non-standard form of key when directly embodying the cipher into bytecode. • Have a later callback download the additional bytecode into the bytecode, or let the server send the bytecode change asynchronously. Use the current environment data as a source of bytecode, data, keying data, weak entropy such as briq itself or any other binary number in the environment, or downloaded bytecode.

Ideally, the ambiguities could ideally be generated in a framework that gives information about how they combine with each other or how they are processed.

Techniques Another way to increase the strength of an activator is to make it incomplete so that it cannot continue to operate without additional contact with the CAS. A "technique" is a piece of code that runs inside a CAS and is customized to support the request. Multiple techniques may be used, but are sufficient for multiple activators of a single technique type.
Simple techniques can be implemented hard coded inside the CAS, dynamically loaded bytecodes or shared objects. The activator for the technique protocol is the existing RP for transport from the SCDP client.
As a layer on C, the technique can save the trouble of having a defined message. In the present invention, activator bytecode and technique bytecode can be treated as different languages. The technique code need only comprise a single byte code for the entire cryptographic routine.

The following components are used to implement the obfuscated bytecode in the activator of the present invention. 1) Bytecode Interpreter, 2) Bytecode Assembler, 3) Cryptographic Bytecode Routine, 4) Interface to ARFS / VxD to call into Activator at useful point, 5) Activator is CAS
6) CAS Activator Manufacturing Capabilities (Activator Factory 710) that allow communication with the embodied techniques in 6).
.

It will be appreciated that the system described herein facilitates secure delivery of content on demand over broadband networks as well as dedicated intranets.

The invention thus described may be implemented in software only, hardware only, or a combination of hardware and software including program code stored in the form of firmware to support dedicated hardware. Good. One software implementation of the above embodiment is the diskette 142, CD- in FIG.
A set of computer instructions fixed on a tangible medium, such as ROM 147, ROM 115, or a computer-readable medium such as a fixed disk 152, or a modem or other interface device (eg, network 195 via medium 191).
Can include a set of computer instructions that can be communicated to a computer system on a carrier wave via a communication adapter 190) connected to the. The medium 191 may be a tangible medium, including but not limited to optical communication or analog communication lines, microwaves,
It may be implemented using wireless techniques, including but not limited to infrared, or other communication techniques. These sequences of computer instructions, whether contained on a tangible medium or on a carrier wave, embody all or part of the functionality previously described in connection with the present invention. A person of ordinary skill in the art would understand that such computer instructions can be written in many programming languages used in computer architectures or operating systems and can exist in machine-executable form. Will. Furthermore, these instructions are
Current or future memory technology may be used to store, including, but not limited to, magnetic, optical, or other memory devices, or current or future including, but not limited to, microwave, infrared, or other communication techniques. It may be transmitted using future communication technology. Such computer programs may be printed or electronic documents (eg shrink-wrapped software pre-loaded with a computer system on a system ROM or fixed disk, or sold over a network such as the Internet or WWW via servers or electronic bulletin boards. Is also considered for sale as removable media.

While various exemplary embodiments of this invention have been disclosed, a worker of ordinary skill can provide some of the advantages of this invention without departing from the spirit and scope of this invention. It will be appreciated that various changes and modifications are possible. It will be apparent to those of ordinary skill in the art that other components having the same function may be used as appropriate. Furthermore, the method of the present invention can be embodied entirely in software using suitable processor instructions, or embodied as a hybrid using a combination of hardware logic and software logic to achieve similar effects. You can

[0157]   The claims will be described below.

BRIEF DESCRIPTION OF THE DRAWINGS The above and other features, objects and advantages of the present invention will be better understood with reference to the following detailed description in conjunction with the accompanying drawings.

[Figure 1]   FIG. 6 is a block diagram of a computer system suitable for use with the present invention.

FIG. 2A is a conceptual block diagram of a broadband network capable of implementing the content secure delivery system of the present invention. (B) is a conceptual block diagram showing the elements of the system of the present invention and the interaction with elements of other networks according to the present invention.

FIG. 3A is a conceptual block diagram of SCDP according to the present invention. 3B is a conceptual block diagram of a launcher module of the SCDP client of FIG. 3A. (C) is a conceptual block diagram of the ARFS VxD module of the SCDP client of FIG. 3A. 3D is a conceptual block diagram of the RAFT VxD module of the SCDP client of FIG. 3D.

4A and 4B together show a flowchart showing a procedure for joining a content and a procedure for launching a title according to the present invention.

5A to 5C together with a flowchart showing stepwise a procedure performed by a SCDP client according to the present invention.

FIG. 6 is a flow chart illustrating a procedure performed by a SCDP client component according to the present invention.

FIG. 7A is a conceptual diagram of the CAS server of FIG. 2 according to the present invention. (B) is a flowchart showing a procedure executed by a CAS server according to the present invention.

[Figure 8]   FIG. 3 is a conceptual diagram of a RAFT token according to the present invention.

[Figure 9]   It is a conceptual diagram of the launch string by this invention.

[Figure 10]   FIG. 3 is a conceptual diagram of the RAFT server of FIG. 2 according to the present invention.

FIG. 11   FIG. 3 is a conceptual diagram of a RAFT packet header according to the present invention.

[Fig. 12]   FIG. 3 is a conceptual block diagram of a briq data package according to the present invention.

[Fig. 13]   FIG. 3 is a conceptual block diagram of an activator according to the present invention.

FIG. 14   FIG. 14 is a conceptual block diagram of e-commerce according to the present invention.

─────────────────────────────────────────────────── ─── Continuation of front page (51) Int.Cl. ⁷ Identification code FI theme code (reference) G06F 17/30 120 G06F 9/06 660C 660G (31) Priority claim number 09 / 311,923 (32) Priority Date May 12, 1999 (May 12, 1999) (33) Priority claiming country United States (US) (31) Priority claim number 09 / 310,229 (32) Priority date May 12, 1999 (May 12, 1999) (33) Priority claiming country United States (US) (31) Priority claim number 09 / 439,906 (32) Priority date November 12, 1999 (November 11, 1999) ( 33) Priority claiming countries United States (US) (81) Designated countries EP (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, IT, LU, MC, NL, (PT, SE), AU, CA, CN, J , KR, SG, ZA (72) Inventor Eightin Mark W02 Massachusetts, United States 02144 Somerville Sharp 331 Highland Avenue 411 A (72) Inventor Lost Check David Jay United States Massachusetts 02474 Arlington Brookdale Road 9 F Term (reference) 5B017 AA03 BA07 BB10 CA15 5B075 KK43 KK54 NK04 PQ05 5B076 FB01 5B082 EA12 GA11 HA05

Claims (21)

[Claims] 1. A method for delivering content over a network, comprising: (a) storing at least one title in a non-executable format on a content server functionally connected to the network. (B) storing, in an access server functionally connected to the network, a position identifier of the title and data required to process the title into an executable format; (c) the Requesting a client process functionally connected to the network to obtain the location identifier of the title from the access server before retrieving at least a portion of the title from a content server; ) The data required to process the portion of the title into an executable format As obtained from the server, the method comprising the steps of requesting the client process, the. 2. (e) Requesting the client process to obtain the signature of the access server and present the signature to the content server before retrieving at least a portion of the title from the content server. The method of claim 1, further comprising a step. 3. (e) requesting the client process to obtain from the access server time data defining the time at which the client process can retrieve at least a portion of the title from the content server. The method of claim 1, further comprising: 4. (f) The client to obtain new time data from the access server at the time the time expires and before retrieving at least a portion of the title from the content server. The method of claim 3, further comprising the steps required of the process. 5. A device for securely delivering content via a network, comprising: (a) being functionally connected to said network and storing at least one title in an inexecutable form. A content server, and (b) an access server functionally connected to the network, the access server storing a location identifier of the title and data necessary for processing the title into an executable format. And (c) a client system functionally connected to the network, the location identifier of the title and the data required to process the portion of the title into an executable format, A client system including program logic configured to obtain from the access server. apparatus. 6. The apparatus of claim 5, wherein the client system further comprises program logic configured to execute a portion of the title. 7. The access server further comprises program logic configured to generate time data defining a time at which at least a portion of the title can be retrieved from the content server. Equipment. 8. The apparatus of claim 7, wherein the client system further comprises program logic configured to request new time data from the access server when the time expires. . 9. The network comprises a broadband access network,
The device according to claim 5. 10. An apparatus for delivering content via a network, comprising: (A) a content server system connectable to the network, (A.1) including data specifying a time interval, and a client. Authenticator logic responsive to a token received from a process, the authenticator logic configured to determine if the client process is authorized to access memory at a particular time; and (A.2). Access program logic responsive to the token received from the client process and containing data uniquely identifying one of the titles stored in the memory, the access program logic uniquely identified by the memory and the token. Access to titles A content server system including an access program logic configured to: (B) an access server system connectable to the network, (B.1) responding to a unique identifier of a title provided by a client process A conversion program logic for converting the unique identifier of the title into a location identifier on the network indicating an address accessible to the title; and (B.2). An access server system that includes an activator generation program logic that responds to a request from a client process, the activator generation program logic that generates an activator in response to the request, and (C) the content server and The a A client system connectable to an access server system via the network, (C.1) a token, an activator, and a location identifier of the content server that can access a specified title from the access server system. (C.2) program logic configured to retrieve at least a portion of the identified title from the content server, and (C.3) retrieve from the content server. A client system including: program logic configured to execute the portion of the identified title identified by the client system; 11. The client system further comprises an operating system executable on the system, the client process further comprising: (C.4) mounting a network file system associated with the identified title. And (C.5) intercepting multiple requests from the operating system during title execution, and (C.5) programming logic configured to store multiple registry entries associated with the title in memory of the client system. 11. Program logic configured to forward a selected portion of the intercepted request to the registry entry.
The device according to. 12. The apparatus of claim 10, wherein the activator comprises cryptographic data. 13. The activator includes at least one bytecode, and the client system further comprises: (C.4) program logic for interpreting and executing the bytecode contained within the activator. 11. The device of claim 10, which comprises. 14. A method for executing an application on a local computer system even if the application is not installed on the local computer system, comprising: (a) a network mountable file system and one associated with the application. Accessing a set of registry entries; (b) mounting the network file system; (c) storing the registry entry on the local computer system; (d) the application from a remote source. Retrieving at least a portion, (e) executing the application under control of an operating system of the local computer system, and (f) from the operating system. A method of executing an application, comprising: intercepting a request; and (g) forwarding a selected portion of the intercepted request to a registry entry stored on the local computer system. 15. A computer system comprising a processor, memory, and an operating system capable of executing one or more applications, the system for executing the applications without being installed on the computer system. And a program logic configured to mount a network file system and store a plurality of registry entries associated with the application in memory, and configured to retrieve at least a portion of the application from a remote source. And a program logic that responds to a request from the operating system, intercepting a request from the operating system and selecting a selected portion of the intercepted request. A system for executing an application including program logic configured to transfer to the registry entry. 16. On-demand delivery of titles is enabled in a client process executing on a local computer system operably connected to an access server and one or more title data sources via a computer network. A method comprising: (a) obtaining a token, an activator, and a network address of a source from which the identified title is accessible from the access server; and (b) sending the token to the source. Where the token data defines a time interval during which the source is accessible, (c) retrieving at least a portion of the title from the source, and (d) retrieving from the source. Performing the portion of the title Access includes the steps of obtaining a token that is updated from the server, the method. 17. The title includes a network mountable file system and a set of registry entries, wherein step (d) further comprises d1. Mounting the network file system and storing the registry entry; d2. Intercepting a request from an operating system executing on the local computer system and forwarding a selected portion of the intercepted request to the registry entry. 18. A server device, comprising a processor, a memory, and a network interface, which is connectable to a computer network,
A method of enabling access to a title by a requesting process, the method comprising: (a) authenticating a launch string from the requesting process; and (b) accessing the title with a unique identifier of the title received from the requesting process. A location identifier indicating an address on the computer network, (c) generating an activator, and (d) sending the activator to the requesting process via the computer network. how to. 19. A method of using a server device, comprising a processor, a memory, and a network interface, which is connectable to one or more client processes of a computer network, comprising: (a) a fixed time from the client process. Receiving a token containing the identifying data and the data uniquely identifying the title via the network interface, and (b) determining whether the client process is authorized to access the title at a particular time. (C) accessing the title uniquely identified by the memory and the token if the client is authorized in step (d), and (d) identifying the title by the token. There are less of the above titles Also containing and supplying part to the client, method. 20. A method for enabling selective delivery of a title to one or more requestor processes via a computer network, the method comprising: (a) providing the requester process with an address on the computer network. Providing access to a selected portion of a title stored in an unexecutable form under certain conditions, (b) providing the requestor process with the title from an inexecutable form to an executable form. And (c) preventing the title from being installed on the computer while allowing execution of a selected portion of the title on the computer system. Inclusive, method. 21. A method of delivering a title to one or more requester processes via a computer network, comprising: (a) receiving data identifying a title from a requester process; and (b) said requestor process. And (c) receiving payment information from the requester process, providing data identifying the location on the computer network that has access to the title and authorization data necessary to access the title. A method including and.