Method and system for securely incorporating electronic information into an online purchasing application

Abstract

A method and system for facilitating digital commerce using a secure digital commerce system is provided. The secure digital commerce system is arranged according to a client/server architecture and includes a modularized DCS client and DCS server. The DCS client and the DCS server are incorporated into an online purchasing system, such as a virtual store, to perform the purchase and online delivery of electronic content. The DCS client includes a set of components which include a secured copy of the merchandise and various components needed to license and purchase the merchandise and to unsecure and process (e.g., execute) the licensed merchandise. The DCS client communicates with the DCS server to download the components onto a customer's computer system and to license and purchase a requested item of merchandise. The DCS server, which includes a content supplier server, a licensing and purchasing broker, and a payment processing function, supplies merchandise-specific components and licenses the requested item of merchandise by generating an electronic certificate. The electronic certificate contains license parameters that are specific to the requested merchandise and an indicated purchasing option. Once a valid electronic license certificate for the requested merchandise is received by the DCS client, the merchandise is made available to the customer for use in accordance with the licensing parameters contained in the electronic license certificate.

Claims

What is claimed is:

1. A computer system for conducting electronic commerce, including:

a store computer that receives requests for electronic data from a client computer and that, in response to receiving the request, sends to the client computer a download component that coordinates the download of the electronic data;

a supplier computer that receives a request from the download component of the client computer to download the electronic data and that, in response to receiving the request, sends the electronic data and a licensing component to the client computer, the licensing component for coordinating the licensing of the electronic data; and

a licensing computer that receives a request from the licensing component of the client computer to license electronic data and that, in response to receiving the request, determines whether access to the electronic data is to be allowed at the client computer, and when access is allowed, sends a notification that access is allowed to the client computer.

2. The system of claim 1 wherein the licensing computer is for receiving a request from the licensing component for merchandise that is not transmitted online and for transmitting an order for physical shipment of the merchandise that is not transmitted online.

3. The system of claim 1 including a payment processing computer for processing payments for the electronic data.

4. The system of claim 1 wherein the store computer, the supplier computer, and the licensing computer are separate computers.

5. The system of claim 1 wherein the store computer, the supplier computer, and the licensing computer are separate web servers.

6. The system of claim 1 wherein the virtual store computer, the supplier computer, and the licensing computer are separate web sites.

7. A method in a computer system for conducting electronic commerce, including:

requesting a first web server to order electronic data;

receiving in response to the request a download component for coordinating the download of the electronic data; and

under control of the download component, downloading from a second web server the electronic data.

8. The method of claim 7 wherein the download component also downloads a licensing component and including:

under control of the licensing component, requesting and receiving from a third web server a license for using the electronic data; and

using the electronic data in accordance with the received license.

9. The method of claim 8 including:

under control of a payment component, authorizing payment for the electronic data.

10. The method of claim 7 wherein the downloaded electronic data is encrypted.

11. A method in a store computer for coordinating electronic commerce, the method including:

receiving from a client computer a request to purchase electronic data; and

in response to receiving the request, sending to the client computer a download component, the download component for coordinating the download of the electronic data from a supplier computer to the client computer, the supplier computer for downloading to the client computer the electronic data when requested by the download component.

12. The method of claim 11 wherein the supplier computer downloads a licensing component that requests a licensing computer for a license to use the electronic data.

13. The method of claim 11 wherein the store computer, the client computer, and the supplier computer communicate via the Internet.

14. A first computer for coordinating electronic commerce, including:

means for receiving from a second computer a request to purchase electronic data; and

means for, in response to receiving the request, sending to the second computer a download component, the download component for coordinating the download of the electronic data from a third computer to the second computer, the third computer for downloading to the second computer the electronic data when requested by the download component.

15. The first computer of claim 14 wherein the third computer downloads a licensing component that requests a fourth computer for a license to use the electronic data.

16. The first computer of claim 14 wherein the computers communicate via the Internet.

Description

TECHNICAL FIELD

The present invention relates to facilitating the purchase of electronic information using digital commerce and, in particular, to providing a component-based architecture that facilitates online licensing and purchase of digital content and software.

BACKGROUND OF THE INVENTION

Today's computer networking environments, such as the Internet, offer an unprecedented medium for facilitating the purchase of software and digital content online. Electronic software distribution (ESD) provides an online alternative (using computers) for a customer to purchase software and other types of digital content from publishers, resellers, and distributors without the physical distribution of a shrink-wrapped product. This online process is referred to as digital commerce. The customer purchases and downloads the software or other digital content directly from the network. In the context of this specification, software is generally a computer program, which is self-executing, whereas digital content that is not software is data that serves as input to another computer program. For example, audio content is digital content (an audio script) that is played and heard by executing an audio player (a computer program) to process the audio script. This act of processing is referred to as "executing" the digital content. For the purposes of this specification, self-executing content and other digital content, as well as any other type of electronic information that can be licensed or purchased, including combinations of content and a player for that content, will be referred to generically as electronic information, electronic data, or electronic content.

One of the major problems that authors of electronic content face using digital commerce is a reliable mechanism for obtaining payment for their electronic content. One reason is that it has become increasingly easy, without the use of secure licensing code, to copy and widely distribute electronic content. To limit the use of illegal copies of electronic content, current systems have incorporated licensing code into existing application programs to be electronically distributed using various solutions. According to one technique, which will be referred to herein as "wrapping," a second application program (a wrapper program) is distributed on the network, which includes an encrypted version of the original application program. The wrapper program, when installed, decrypts the encrypted original application program and then proceeds to execute the original application program. To successfully decrypt the program, a legitimate end user must provide the proper licensing information to enable the decryption to operate. A security hole exists, however, in that, while the wrapping program is in the process of decrypting the original application executable file, temporary files are created to hold the decrypted program code. Once the entire original application program has been decrypted and stored in the temporary file, a "software pirate" can then make multiple copies of the original unencrypted application program in the temporary file and can distribute them illegally.

Further, use of the wrapping technique to incorporate licensing provides only limited additional security to a vendor who implements what is known as a "try and buy" licensing model. A try and buy licensing model typically distributes an application program with either limited functionality or for a limited time of use to enable a potential customer to explore the application. Functionality may be limited, for example, by disabling a set of features. Once the potential customer is satisfied, the customer can pay for and license the application program for more permanent use. If an application program is distributed using the wrapping technique to potential customers for the purpose of try and buy licensing, then, when the application program is decrypted and stored in a temporary file, a software pirate can determine how to enable the disabled features or how to remove the license expiration data. These security problems can result in the distribution of illegal copies, which are hard to detect and monitor in a global network environment.

A second technique for incorporating licensing code into an existing application program directly inserts the licensing code into the executable file. Using the direct insertion method, an application developer determines where in the executable file the licensing code should be placed and inserts the new code into the executable. After inserting the licensing code into the existing executable file, the application developer adjusts addresses that reference any relocatable code or data that follows the inserted code to account for the newly added code. However, it is very difficult for an application developer to determine where to insert the licensing code and to then test the entire application to ensure it works correctly. An application developer would typically need to disassemble the executable file and study the disassembled code to determine where to insert the licensing code. Such disassembling and studying is a very time-consuming process. Furthermore, the process must be repeated for each application program, and for each version of each application program in which the code is to be inserted.

In addition to problems relating to obtaining payment due to illegal distribution, the current methods for incorporating licensing code and for supporting digital commerce present scalability problems. For example, it is difficult for these systems to handle large volumes and numerous types of electronic content because any change to the licensing or purchasing model requires re-encryption and perhaps re-wrapping of the electronic content. In addition, it is difficult to distribute such content online when the content is large in size because the network connection may be prone to failures. A failure in a network connection when downloading the electronic content would require starting the download operation again.

To perform digital commerce, today's computer networking environments utilize a client/server architecture and a standard protocol for communicating between various network sites. One such network, the World Wide WEB network, which comprises a subset of Internet sites, supports a standard protocol for requesting and for receiving documents known as WEB pages. This protocol is known as the Hypertext Transfer Protocol, or "HTTP." HTTP defines a high-level message passing protocol for sending and receiving packets of information between diverse applications. Details of HTTP can be found in various documents including T. Berners-Lee et al., Hypertext Transfer Protocol--HTTP 1.0, Request for Comments (RFC) 1945, MIT/LCS, May, 1996, which is incorporated herein by reference. Each HTTP message follows a specific layout, which includes among other information a header, which contains information specific to the request or response. Further, each HTTP message that is a request (an HTTP request message) contains a universal resource identifier (a "URI"), which specifics a target network resource for the request. A URI is either a Uniform Resource Locator ("URL") or Uniform Resource Name ("URN"), or any other formatted string that identifies a network resource. The URI contained in a request message, in effect, identifies the destination machine for a message. URIs, as an example of URls, are discussed in detail in T. Berners-Lee, et al., Uniform Resource Locators (URL), RFC 1738, CERN, Xerox PARC, Univ. of Minn., December, 1994, which is incorporated herein by reference.

FIG. 1 illustrates how a browser application, using the client/server model of the World Wide WEB network, enables users to navigate among network nodes by requesting and receiving WEB pages. For the purposes of this specification, a WEB page is any type of document that abides by the HTML format. That is, the document includes an "<HTML>" statement. Thus, a WEB page can also be referred to as an HTML document or an HTML page. HTML is a document mark-up language, defined by the Hypertext Markup Language ("HTML") specification. HTML defines tags for specifying how to interpret the text and images stored in an HTML page. For example, there are HTML tags for defining paragraph formats and text attributes such as boldface and underlining. In addition, the HTML format defines tags for adding images to documents and for formatting and aligning text with respect to images. HTML tags appear between angle brackets, for example, <HTML>. Further details of HTML arc discussed in T. Berners-Lee and D. Connolly, Hypertext Markup Language-2.0, RFC 1866, MIT/W3C, November, 1995, which is incorporated herein by reference.

In FIG. 1, a WEB browser application 101 is shown executing on a client computer system 102, which communicates with a server computer system 103 by sending and receiving HTTP packets (messages). The WEB browser application 101 requests WEB pages from other locations on the network to browse (display) what is available at these locations. This process is known as "navigating" to sites on the WEB network. In particular, when the WEB browser application 101 "navigates" to a new location, it requests a new page from the new location (e.g., server computer system 103) by sending an HTTP-request message 104 using any well-known underlying communications wire protocol. HTTP-request message 104 follows the specific layout discussed above, which includes a header 105 and a URI field 106, which specifies the target network location for the request. When the server computer system machine specified by URI 106 (e.g., the server computer system 103) receives the HTTP-request message, it decomposes the message packet and processes the request. When appropriate, the server computer system constructs a return message packet to send to the source location that originated the message (e.g., the client computer system 102) in the form of an HTTP-response message 107. In addition to the standard features of an HTTP message, such as the header 108, the HTTP-response message 107 contains the requested WEB page 109. When the HTTP-response message 107 reaches the client computer system 102, the WEB browser application 101 extracts the WEB page 109 from the message, and parses and interprets the HTML code in the page (executes the WEB page) in order to display the document on a display screen of the client computer system 102 in accordance with the HTML tags.

SUMMARY OF THE INVENTION

The present invention provides methods and systems for facilitating the purchase and delivery of electronic content using a secure digital commerce system. The secure digital commerce system interacts with an online purchasing system to purchase and distribute merchandise over a network. The secure digital commerce system is comprised of a plurality of modularized components, which communicate with each other to download, license, and potentially purchase a requested item of merchandise. Each component is customizable.

Exemplary embodiments of the secure digital commerce system ("DCS") include a DCS client and a DCS server. The DCS client includes a plurality of client components, which are downloaded by a boot program onto a customer computer system in response to requesting an item of merchandise to be licensed or purchased. The downloaded client components include a secured (e.g., encrypted) content file that corresponds to the content of the requested item and licensing code that is automatically executed to ensure that the item of merchandise is properly licensed before a customer is permitted to operate it. The DCS server includes a content supplier server, which provides the DCS client components that are specific to the requested item, and a licensing and purchasing broker, which generates and returns a secure electronic licensing certificate in response to a request to license the requested item of merchandise. The generated electronic license certificate contains licensing parameters that dictate whether the merchandise is permitted to be executed. Thus, once properly licensed, the downloaded client components in conjunction with the electronic license certificate permit a legitimate customer to execute (process) purchased content in a manner that helps prevent illegitimate piracy.

In one embodiment, the electronic license certificate is generated from tables stored in a password generation data repository. Each table contains fields that are used to generate the license parameters. Each electronic license certificate is generated specifically for a particular item of merchandise and for a specific customer request. Also, the electronic license certificate is secured, such as by encryption, to prevent a user from accessing the corresponding item of merchandise without proper authorization. One technique for securing the electronic license certificate uses a symmetric cryptographic algorithm.

The secure digital commerce system also supports the ability to generate emergency electronic license certificates in cases where an electronic license certificate would not normally be authorized. To accomplish this objective, a separate emergency password generation table is provided by the password generation data repository. In addition, the secure digital commerce system reliably downloads the client components even when a failure is encountered during the download procedure. Further, a minimum number of components are downloaded.

In addition to generating electronic license certificates, the licensing and purchasing broker may also include access to a payment processing function, which is invoked to authorize a particular method of payment for a particular transaction. The licensing and purchasing broker may also include access to a clearinghouse function used to track and audit purchases.

Digital commerce is performed using the secure digital commerce system as follows. A customer invokes an online purchasing system to request an item of merchandise and to indicate a purchasing option (such as "try" or "buy"). The DCS client then downloads onto a customer computer system the client components that are associated with the requested item. Included in these components is a secured content component. The secured content component is then installed and executed (processed) in a manner that automatically invokes licensing code. The licensing code, when the requested item is not yet licensed properly, causes the requested item to be licensed by the licensing and purchasing broker in accordance with the indicated purchasing option before the content component becomes operable. Specifically, the licensing and purchasing broker generates a secure electronic license certificate and completes an actual purchase when appropriate. The broker then returns the electronic license certificate to the licensing code, which unsecures (e.g., unencrypts) and deconstructs the electronic license certificate to determine the licensing parameters. The licensing code then executes (processes) the content component in accordance with the license parameters.

In some embodiments, the secure digital commerce system supports the licensing and purchasing of both merchandise that is deliverable online and merchandise that requires physical shipment of a product or service (e.g., non-ESD merchandise).

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates how a browser application, using the client/server model of the World Wide WEB network, enables users to navigate among network nodes by requesting and receiving WEB pages.

FIG. 2 is an example display screen of an online virtual store that operates with the secure digital commerce system.

FIG. 3 is an overview block diagram of the secure digital commerce system.

FIG. 4 is an overview flowchart of the example steps performed by the secure digital commerce system components to perform the licensing and purchase of electronic data.

FIG. 5 is a block diagram of a general purpose computer system for practicing embodiments of the DCS client.

FIG. 6 is an example flow diagram of the steps performed to generate the components of the DCS client.

FIG. 7 is an example WEB page of a virtual store used to purchase electronic data, which is executing on a customer computer system.

FIG. 8 is an example flow diagram of the steps performed by a boot program executed on a customer computer system to download client components when licensing a selected item of merchandise.

FIG. 9 is an example flow diagram of licensing code that has been incorporated into an encrypted content file.

FIG. 10 is an example display screen presented by a virtual store to determine whether a customer desires to license a product for trial use or for purchase.

FIG. 11 is an example flow diagram of the steps performed by licensing code to determine whether a valid electronic licensing certificate is available.

FIG. 12 is an example flow diagram of the steps performed by a licensing and purchasing broker of the secure digital commerce system.

FIG. 13 is an example display screen of the WinZip 6.2 program, which was selected for purchase in FIG. 7, when it executes after completing the licensing procedures.

FIG. 14 is an example display screen for selecting a particular credit card.

FIG. 15 is an example display screen for entering a password for a selected credit card.

FIG. 16 is an example display screen for adding a new credit card.

FIG. 17 is an example display screen for allowing a customer to verify an intent to purchase after supplying a method of payment.

FIG. 18 is an example display screen for indicating that a purchasing transaction has been authorized.

FIG. 19 is an example block diagram that illustrates one technique for ensuring secure communications between a DCS client component and a licensing and purchasing broker.

FIG. 20 is an example encrypted message protocol for sending encrypted messages between a DCS client component and a licensing and purchasing broker.

FIG. 21 is an example flow diagram of the additional steps performed by a licensing and purchasing broker of the secure digital commerce system to support non-ESD transactions.

DETAILED DESCRIPTION OF THE INVENTION

Exemplary embodiments of the present invention provide methods and systems for facilitating secure digital commerce of electronic content. The secure digital commerce system interacts with an online purchasing system, such as a virtual store, to facilitate the purchase and distribution of merchandise over a network, such as the Internet or the World Wide WEB network (the WEB). For the purposes of this specification, a virtual store is any executable file, data, or document (for example, a WEB page) that enables a user to electronically purchase merchandise over a network.

FIG. 2 is an example display screen of an online virtual store that operates with the secure digital commerce system. Although the secure digital commerce system is described with reference to a virtual store, one skilled in the art will recognize that any type of electronic purchasing system or application, including a standalone application, is operable with embodiments of the present invention. A browser application window 201 is shown currently displaying (and executing) a WEB page 202 retrieved from the location specified by the URI "www.buysoftware.com." WEB page 202 provides a set of user interface elements, for example, pushbuttons 204 and 205 and icon 203 which display information or which can be used to navigate to additional information. A virtual store typically provides a set of icons, which each describe an item of merchandise that can be purchased. For example, graphical icon 203 is an example icon that is linked to the functionality needed to purchase a Microsoft Corp. software game entitled "RETURN OF ARCADE."

Each icon is typically linked to a server site on the network, which is responsible for supplying the content of the item when purchased if the item is capable of electronic delivery. When the user selects one of the icons, the browser application, as a result of processing the link, sends a request for the selected item to the server site. Thus, when a customer selects the icon 203, an HTTP request message is sent to an appropriate server site to locate and download the software modules that correspond to "RETURN OF ARCADE."

For the purposes of this specification, the merchandise that can be licensed and distributed online includes any type of digital or electronic, information or data that can be transmitted using any means for communicating and delivering such data over a network, including data transmitted by electronics, sound, laser, or other similar technique. Similarly, although the present application refers generically to "electronic data" or "electronic content," it will be understood that embodiments of the present invention can be utilized with any type of data that can be stored and transmitted over a network.

The secure digital commerce system is arranged according to a client/server architecture and provides a modularized DCS client and a modularized DCS server that interact with the online purchasing system to perform a purchase. The DCS client includes a set of client components; support for downloading the client components onto a customer computer system; and support for communicating with the DCS server to license an item of merchandise. The client components contain a secured (e.g., encrypted) copy of the content and various components needed to license and purchase the merchandise and to unsecure (e.g., decrypt) and execute the licensed merchandise. The DCS client communicates with the DCS server to download the client components onto a customer's computer system in response to a request for merchandise from the online purchasing system. The DCS client also communicates with the DCS server to license and purchase the requested merchandise. The DCS server generates an electronic license certificate, which contains license parameters (e.g., terms) that are specific to the requested merchandise and to a desired purchasing option (such as trial use, permanent purchase, or rental). The DCS server then sends the generated electronic license certificate to the DCS client. Once a valid electronic license certificate for the requested merchandise is received by the DCS client, the merchandise is made available to the customer for use in accordance with the license parameters contained in the electronic license certificate.

The DCS client includes a download file, a user interface library, a purchasing library, a secured content file, a DCS security information file, and licensing code. There is a download file for each item of merchandise that can be distributed electronically, which contains an executable boot program. The boot program is responsible for determining what components need to be downloaded for a requested item of merchandise. The secured content file contains the content that corresponds to the requested item of merchandise. The content may be a computer program, data, or a combination of both. For the purposes of this specification, "secure" or "secured" implies the use of cryptography or other types of security, including the use of hardware. One or more of the remaining components can be shared by several items of merchandise. For example, the user interface library, which defines a user interface used to purchase and license merchandise, may be specific to an item of merchandise or may be uniform for an entire online purchasing system. The purchasing library, licensing code, and DCS security information file are used to interact with the DCS server to properly license requested merchandise. In particular, the licensing code ensures that the requested merchandise is not operable by the customer until it has been properly licensed by the DCS server.

The DCS server includes a content supplier server, a licensing and purchasing broker, and a payment processing function. The content supplier server provides the merchandise-specific DCS client components. The licensing and purchasing broker generates electronic license certificates and manages purchases. The payment processing function authorizes payment for a particular transaction. One or more of each of these entities may be available in a DCS server.

One of the advantages of the modularized nature of exemplary embodiments of the present invention is that it provides a natural mechanism for replacing individual components and for customizing the system. For example, by replacing only the licensing code and a portion of the licensing and purchasing broker, an entirely new cryptographic algorithm may be used to secure the content. Embodiments of the invention also support the secure execution of requested merchandise and minimize the number of components needed to securely download, license, and execute the requested merchandise.

For the purposes of this specification, any client/server communication architecture and communication protocol that supports communication between the DCS client and the DCS server could be used.

However, in an exemplary embodiment, the secure digital commerce system utilizes the HTTP request communication model provided by the World Wide WEB network. A detailed description of this architecture and of WEB page communication is provided in J. O'Donnell et al., Special Edition Using Microsoft Internet Explorer 3, QUE Corp., 1996, which is incorporated herein by reference.

FIG. 3 is an overview block diagram of the secure digital commerce system. FIG. 3 includes a DCS client 301 and a DCS server 302, which are used with an online purchasing application, such as a WEB browser application 303, to provide a purchasing interface for a potential customer. The DCS client 301 includes a virtual store 304 and a data repository 305. The virtual store 304 provides a customer front end 312 and stores in the data repository 305 merchandise-specific download files 313. The customer front end 312 includes WEB pages and associated processing support, which are downloaded onto a customer computer system 311 to enable a user to purchase merchandise. The download files 313, which each contain an executable boot program and a component list, are used to download the merchandise-specific client components (for example, a secured content file and licensing code). When an item of merchandise is requested, the associated download file is processed to extract the executable boot program and the component list. The executable boot program downloads the needed components from the content supplier server 306 using the component list, which specifies the components that are needed to successfully license and operate the corresponding item of merchandise. In an alternate embodiment, download files are generated dynamically from component lists, which lists are stored in the data repository 305.

The DCS server 302 includes a content supplier server 306, a licensing and purchasing broker (server) 307, a password generation data repository 308, and a payment processing function 309. The licensing and purchasing broker 307 includes a separate licensing library 310 (passgen.dll), which contains the code for generating an appropriate license in response to a request from the virtual store. The licensing library 310 uses the password generation data repository 308 to generate an electronic license certificate ("ELC") with licensing parameters that correspond to a particular item of merchandise. An electronic license certificate is encrypted electronic data that provides information that can be utilized to determine whether a particular customer is authorized to execute the merchandise. Such information may include, for example, the specification of a period of time that a particular customer is allowed to execute the merchandise for trial use. The data repository 308 contains tables and fields that are used to create the license parameters of a license. The data repository 308 may contain information that is supplied by the source companies of the available merchandise. The payment processing functions 309 are used by the licensing and purchasing broker 307 to charge the customer and to properly credit the appropriate supplier when the customer requests an actual purchase (rather than trial use or another form of licensing). In addition, clearinghouse functions may be invoked by the licensing and purchasing broker 307 to audit and track an online purchase. Clearinghouse functions may be as provided by well-known commercial sources, such as Litlenet and Cybersource. Similarly, payment processing functions may be provided using well-known commercial credit card authorization services.

FIG. 4 is an overview flowchart of the example steps performed by the secure digital commerce system components to perform the licensing and purchase of electronic data. This figure briefly describes the interactions between the components shown in FIG. 3 to accomplish the downloading, licensing, and purchasing of a requested item of merchandise when it can be delivered online. In step 401, the potential customer downloads a WEB page (part of the customer front end 312) from the virtual store 304 that includes the item to be requested (see, for example, FIG. 2). In step 402, the customer requests an item of merchandise, for example, by selecting an icon that is linked to a download file that corresponds to the desired item. In response to the selection, in step 403, the virtual store 304 downloads and installs the download file, which extracts the executable boot program and component list and causes execution (preferably as a background task) of the executable boot program on the customer computer system 311. In step 404, the boot program reads the component list to determine what DCS client components to download and requests the determined components from the appropriate contents supplier server 306. The component list, as further described below with reference to Table 2, indicates source and target locations for each component to be downloaded. In step 405, the boot program installs a downloaded (secured) content file that is associated with the desired item of merchandise and causes the content file to be processed (executed). When the content file is a computer program, then the downloaded content file has been previously configured to automatically cause licensing code to be executed before the content file is executed. When instead the content file is data to be input to a computer program, then the content player is previously configured to automatically cause the licensing code to be executed first before the content file data is processed. More specifically, the downloaded content player is installed by the boot program to process the secured (e.g., encrypted) content file data. The boot program then starts the execution of the content player, which invokes and causes execution of the downloaded licensing code. Thus, in step 406, the licensing code, which is incorporated into either the content file or the content player, is executed. In step 407, if the licensing code determines that a valid ELC already exists, then the content file continues to be processed in step 412, else the licensing code continues in step 408. In step 408, the licensing code requests a valid ELC from the licensing and purchasing broker 307. In step 409, the licensing and purchasing broker 307 determines whether a purchase is requested and, if so, continues in step 410, else continues in step 411. In step 410, the licensing and purchasing broker 307 obtains a method for payment and authorizes the payment method using the payment processing function 309. In step 411, the licensing and purchasing broker 307 generates an appropriate ELC using the licensing library 310 and the password generation data repository 308 and returns the generated EL-C to the licensing code. In step 412, if portions of the content file are encrypted as will be further described, then the content file is decrypted and processed.

As indicated above, when the downloaded (secured) content file is a computer program, licensing code is automatically invoked to verify the existence of, or obtain, a valid electronic license certificate for a requested item and to decrypt and execute the content file. One mechanism for incorporating licensing code into a content file such that it is automatically invoked is discussed in detail with reference to related U.S. patent application Ser. No. 08/792,719, entitled "Method and System for Injecting New Code Into Existing Application Code," filed on Jan. 29, 1997. That patent application describes a technique for inserting licensing code into an existing application and for inserted security code that securely executes the application code. The security code uses an incremental decryption process to ensure that a complete version of the unmodified application code is never visible at any one time (to avoid illegitimate copying). Thus the security code mechanism described therein makes it impossible for someone to create an unmodified version of the application in a reasonable amount of time. The insertion technique described therein can be used to insert into a content file the licensing code component of the DCS client, which communicates with the licensing and purchasing broker to generate an ELC. Further, the encryption/decryption technique described therein may be used in the current context to incorporate security code that securely decrypts and executes the downloaded content file.

In addition, when the content file is data to be used as input to a computer program (such as a content player), then the licensing code can be incorporated into the computer program by invoking licensing code and security code routines. For example, an application programming interface ("API") to the licensing code and to the incremental decryption security code can be provided. The content player is programmed (or configured via the insertion technique described in the related patent application) to include calls to the API routines to validate or obtain an ELC and to unsecure (e.g., decrypt) the associated content file. One skilled in the art will recognize that any mechanism that automatically causes the execution of licensing code (and security code) before the secured content is processed is operable with embodiments of the present invention.

In exemplary embodiments, the DCS client is implemented on a computer system comprising a central processing unit, a display, a memory, and other input/output devices. Exemplary embodiments of the DCS client are designed to operate in a globally networked environment, such as a computer system that is connected to the Internet. FIG. 5 is a block diagram of a general purpose computer system for practicing embodiments of the DCS client. The computer system 501 contains a central processing unit (CPU) 502, a display 503, a computer memory (memory) 505, or other computer-readable memory medium, and other input/output devices 504. Downloaded components of the DCS client preferably reside in the memory 505 and execute on the CPU 502. The components of the DCS client are shown after they have been downloaded and installed on the computer system 501 by an executable boot program and after an appropriate electronic license certificate has been generated and installed. Specifically, the components of the DCS client include the executable boot program 507 (SAFEboot); a user interface library 508 (SAFEUI.dll); a purchasing request library 509 (SAFEBuy.dll); an encrypted content file 510, which is shown with incorporated licensing code 511 (SAFE.dll); an encrypted DCS security information file 512, which is associated with the encrypted content file 510; and an electronic licensing certificate 514 (ELC). As shown, each library is typically implemented as a dynamic link library (a "DLL"). In addition to these components, when the encrypted content file contains data that is not a computer program, the memory 505 contains a content player 513 for processing the content file 510, which has incorporated licensing code 511. Also, WEB browser application code 506 is shown residing in the memory 505. Other programs 515 also reside in the memory 505. One skilled in the art will recognize that exemplary DCS client components can also be implemented in a distributed environment where the various programs shown as currently residing in the memory 505 are instead distributed among several computer systems. For example, the encrypted content file 510 may reside on a different computer system than the boot program 507.

In exemplary embodiments, the DCS server is implemented on one or more computer systems, each comprising a central processing unit, a memory and other input/output devices. Each of these computer systems may be a general purpose computer system, similar to that described in FIG. 5, which is connected to a network. The server systems that comprise the server portion may or may not include displays. The password generation data repository may be implemented using any well-known technique for implementing a database or any other type of data repository. Although shown as a separate facility, one skilled in the art will recognize that the data repository may be incorporated as a component of the computer system that is used to implement the licensing and purchasing broker. Further, one skilled in the art will also recognize that a variety of architectures are possible and can be used to implement exemplary embodiments of the DCS server.

FIG. 6 is an example flow diagram of the steps performed to generate the components of the DCS client. In an exemplary embodiment, these steps are performed by a utility program referred to as the SAFEmaker utility. The SAFEmaker utility is responsible for generating the downloadable components that correspond to an item to be supplied as online merchandise. In addition, the utility generates a secured content file that can only be processed when access is granted. This capability is referred to as making the file "SAFE" (hence, the SAFE-prefix in the component names). Making a content file "SAFE" implies that security code and licensing code are incorporated into the content file (or content player, in the case of digital content that is not a computer program) to ensure that the online merchandise is usable only when proper licensing has been performed. Typically, this process involves encrypting some portion of the content file. Some components generated by the SAFEmaker utility are stored on the content supplier server (e.g., content supplier server 306 in FIG. 3) and are downloaded in response to requests from the virtual store front end. Other components are stored on the virtual store, which may be located on a different computer system from the content supplier server. The SAFEmaker utility also updates the password generation data repository of the DCS server with merchandise-specific information.

Specifically, in step 601, the utility incorporates licensing and security code into the supplier specific electronic content or content player. As described above, an exemplary embodiment incorporates licensing and security code according to the techniques described in the related U.S. patent application Ser. No. 08/792,719, entitled "Method and System for Injecting New Code into Existing Application Code," filed on Jan. 29, 1997 or by calling routines of an API as appropriate (e.g., when a content player is needed). One skilled in the art, however, will recognize that any technique for ensuring that proper licensing code gets executed when the content is processed and for encrypting (and subsequently decrypting) the content file will operate with embodiments of the present invention. In step 602, the utility produces one or more files that contain the (partially or fully) encrypted content. In step 603, the utility produces an encrypted DCS security information file(s), which contain information that is used, for example, to decrypt the content and to produce a proper license. The contents of an encrypted DCS security information file are described in further detail below with reference to Table 1. In step 604, the utility creates a component list file (an ".ssc" file) and a download file for this particular online merchandise. Specifically, in an embodiment that statically generates download files, a self-extracting installation file is generated (the download file), which contains the component list file (an ".ssc" file) specific to the merchandise and the executable boot program. As described above, the download file, which contains the executable boot program and the component list, is typically stored on the virtual store computer system. The executable boot program uses the component list file to determine the components to download and to download them when particular electronic content is requested. An example component list file is described further below with reference to Table 2. In step 605, the utility stores the download file on the virtual store computer system (e.g., virtual store 304 in FIG. 3). When instead the download files are dynamically generated by the virtual store when needed for a particular WEB page, then in steps 604 and 605, the utility creates and stores only the component list file. In step 606, the utility stores the other components of the DCS client, for example, the encrypted content and DCS security information files, the licensing code, and the user interface library on the content supplier server system (e.g., content supplier server 306 in FIG. 3). In step 607, the utility updates the password generation data repository (e.g., password generation database 308 in FIG. 3) with the merchandise-specific licensing information, for example, the fields used to generate the license parameters of a valid electronic license certificate, and then returns. An example password generation data repository is discussed in further detail with reference to Tables 3, 4, and 5. One skilled in the art will recognize that the generation of these components and the password generation data may be performed at different times and by separate utilities.

                  TABLE 1
    ______________________________________
    Field Name:           Type:
    ______________________________________
    CommerceServer        String
    ProductSkuId          String
    ProductUUID           String
    UILibName             String
    EntryPoint            Integer
    ImageBase             Integer
    Ekey                  String
    Ecode                 BinaryObject
    DataSize              Integer
    NumberRelocations     Integer
    Relocations           String
    ContactCompany        String
    ContactAddress        String
    ContactSupportPhone   String
    ContactSupportFax     String
    ContactSupportEmail   String
    ContactOrderPhone     String
    ContactOrderFax       String
    ContactOrderEmail     String
    ProductName           String
    LicenseFilename       String
    LicenseAdminDir       String
    DeveloperId           String
    SecretKey             BinaryObject
    ActiveAssistants      Integer
    FeatureName           String
    FeatureNumber         Integer
    HostIdTypeList        String
    IntegrationType       Integer
    ______________________________________

                                      TABLE 2
    __________________________________________________________________________
    <Execute
    TRIGGER   = "<ProgramFilesDir>.backslash.winzip.backslash.winzip32.exe"
    URI       = "http://devserver/products/winzip32/winzipsetup.exe"
    MSGDIG    = "NDLsrKcS36YbugITP4yUjv8PSfk="
    ProductUUID
              = "WINZIP-demo-0000"
    NAME      = "WinZip 6.2"
    DESCRIPTION
              = "WinZip 6.2"
    LOCAL     = "<ProgramFilesDir>.backslash.winzip.backslash.setup.exe">
    __________________________________________________________________________

                  TABLE 3
    ______________________________________
    Password-Configuration Table
    Field                   Type
    ______________________________________
    pass-config-id          Varchar
    password-version        Int
    secret-key              Varchar
    developer-id            Varchar
    expire-password-in      Varchar
    start-date              Varchar
    password-output-scheme  Int
    developer-info          Varchar
    concurrent-code         Int
    Licenses                Int
    soft-licenses           Int
    program-executions      Int
    flex-nodelock-machines  Int
    maximum-usernames       Int
    release-number          Int
    minor-release-number    Int
    hostid-type             Int
    misc-info               Int
    min-hostids             Int
    max-hostids             Int
    instances               Int
    emergency-id            Varchar
    feature-type            Int
    feature-list            Varchar
    ______________________________________

                  TABLE 4
    ______________________________________
    Generated-Passwords Table
    Field                 Type
    ______________________________________
    pass-config-id        Varchar
    user-id               Varchar
    generation-type       Int
    date-generated        datetime
    password              Varchar
    ______________________________________

                  TABLE 5
    ______________________________________
    Emergency-Password Table
    Field                  Type
    ______________________________________
    emergency-id           Varchar
    user-id                Varchar
    pass-config-id         Varchar
    start-hour             Int
    end-hour               Int
    start-minute           Int
    end-minute             Int
    start-day-number       Int
    end-day-number         Int
    start-date             Int
    end-date               Int
    start-month            Int
    end-month              Int
    start-year             Int
    end-year               Int
    start-week-number      Int
    end-week number        Int
    ______________________________________

• Inventors
  Krishnan, Ganapathy; Guthrie, John; Oyler, Scott;
• Assignee
  ShopNow.com Inc. (Seattle, WA)
• Published
  Jun-6-2000
• Current US Classes:
  705/26
  705/51
  705/59
• Application #
  895221
• International Classes
  G06F 017/60
• Field of Search
  705/1 705/18 705/21 705/26 705/51 705/59 380/3 380/4 380/23 380/24 380/25 380/277
• Examiner
  Trammell; James P.
• Agent
  Perkins Coie LLP
• US Patent References:
  5005122
  5337357
  5390297
  5530752
  5553143
  5592549
  5708709
  5710887
  5724424
  5757908
  5758068
  5758069
  5778173
  5794259
  5805802
  5845070
  5895454
  5897622
  5898777
  5909492
  5918213
  5940807