ON-THE-FLY WRAPPING OF SOFTWARE FOR ELECTRONIC
DISTRIBUTION FIELD OF THE INVENTION The present invention pertains to the field of electronic software distribution (ESD). More particularly, the present invention relates to the packaging of software for electronic distribution.
BACKGROUND OF THE INVENTION Software products have traditionally been distributed to consumers on physical storage media, such as magnetic disks and tapes and optical media, such as CD-ROMs, DVDs, etc. However, this form of distribution is rapidly being replaced by electronic software distribution (ESD). With ESD, a consumer can use a computer to purchase software from an electronic point of sale (ePOS), or "store", via a network such as the Internet. The ePOS may be a conventional World Wide Web site, for example, and may represent a software reseller or publisher, such as Egghead or @Home. The software can be downloaded to the user and the user can make payment electronically via the network, without the need for any physical storage medium or physical remuneration to change hands.
Prior to being downloaded, the software generally undergoes certain preparation, which is referred to as "wrapping". Wrapping may include adding certain information to the software product to associated the product with a particular source
(i.e., reseller, distributor, etc.), such as a bitmap of the source's logo. A number of problems are associated with current wrapping technology. For example, most wrapping information is stored in offline data files that are difficult to manage and track. Data integrity tends to be a problem because consistency checks cannot be practically performed. Further, each time a new ePOS is deployed or price or bitmap changes, the product must be rewrapped from scratch. As a result, it becomes impractical to deploy increasing numbers of ESD software products to a greater variety of distribution customers and points of sale. What is needed, therefore, is a technology which overcomes these and other disadvantages of ESD technology. SUMMARY OF THE INVENTION
A method and apparatus are provided for quickly and easily distributing information electronically to a remote processing system. In one aspect of the invention, a request to download software is received. In response to the request, the
software is wrapped in an electronic package on-the-fly, and the electronic package is transmitted to a remote processing system.
According to another aspect of the invention, a request to download information is received. The request is associated with a particular source of the information. In response to the request, the information is wrapped on-the-fly in an electronic package customized for the particular source, and the electronic package is transmitted to a remote processing system.
Other features of the present invention will be apparent from the accompanying drawings and from the detailed description which follows. BRIEF DESCRIPTION OF THE DRAWINGS
The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:
Figure 1 illustrates a network configuration including a processing system of an end user coupled to a number of ePOS processing systems on the Internet.
Figure 2 illustrates the network configuration of Figure 1, further including a wrapping facility.
Figure 3 illustrates an example of the composition of any of the processing systems of Figure 2. Figure 4 illustrates a wrapping process generating a wrapped software package based upon source code and stored database information.
Figure 5 is a flow diagram illustrating a routine by which an ePOS may respond to a request for an electronic download from an end user.
Figure 6 is a flow diagram illustrating a routine by which the wrapping facility may respond to a request for an electronic download.
Figure 7 illustrates the components of a wrapping facility.
Figure 8A illustrates the components of a wrapped software package associated with a buy-only download.
Figure 8B illustrates the components for wrapped software package associated with a download other than buy-only.
Figure 9 illustrates a routine for preparing a pre-build wrapper for a buy-only download.
Figure 10 illustrates a routine for preparing a pre-build wrapper for a download other than buy-only.
Figure 11 illustrates the operation of generating a wrapped software package based on a pre-build wrapper.
Figure 12 illustrates a routine that may be performed by the processing system of an end user to "unwrap" a buy-only software package. Figure 13 illustrates a routine that may be performed by a processing system of an end user to "unwrap" a non buy-only downloaded software package.
DETAILED DESCRIPTION A method and apparatus for performing on-the-fly wrapping of information for electronic distribution in a customized manner are described. The on-the-fly wrapping technique is described herein in the context of wrapping software. However, the technique is also applicable to the electronic distribution of other types of digital information, such as fonts, images, etc.
As will be described in greater detail below, the electronic wrapping technique is as follows: An ePOS receives a request from an end user for a specific software product (e.g., a word processing application or an anti-virus utility) and passes a modified request including information identifying the ePOS and the requested product to a wrapping facility via the Internet. The wrapping facility maintains a wrap engine and a software product library containing a number of generic electronic wrappers, referred to as "pre-build" wrappers. The software product library includes one pre- build wrapper for each software product serviced by the wrapping facility. Upon receiving the request from the ePOS, the wrapping facility accesses a database to retrieve a bitmap and other parameters that are associated specifically with the requesting ePOS, and attaches the bitmap and other parameters to the appropriate pre- build wrapper for the requested product, to form a wrapped software package. The wrapped software package includes an executable module, the attached parameters, and the source code of the software product, some or all of which may be encrypted, depending upon the type of wrapping designed for that download. The on-the-fly wrapping technique requires no modifications to the software's source code, other than simple encryption. The software can be downloaded to the end user in any of various modes.
These modes include a "buy-only" mode, in which the encrypted software is not decrypted (and is therefore not useable to the end user) until after the user has submitted payment electronically. Payment is submitted by a sales agent in the downloaded wrapper package. When the user initially selects the downloaded software, the sales agent prompts the user to enter payment information, such as a credit card
number. The sales agent then transmits the payment information securely over the network to a clearing house using an appropriate protocol, such as Hypertext Transport Protocol (HTTP). The software wrapper decrypts the software only after a signal is received from the clearing house that the payment has been accepted (the charge to the credit card has been authorized by the card issuer).
Other download modes include a "try-before-buy" mode, in which the user can use the downloaded software for a limited time with the option to purchase it, subject to certain constraints, such as a time limitation or a limitation on the number of useable features; a "try only" mode, in which the user can use some or all of the features of the software for a limited period of time, after which the software is permanently disabled; and, a software rental mode.
In one embodiment, the software is downloaded from a third party (a party other than the ePOS). The fact that the software is downloaded from a third party rather than the ePOS can be made completely transparent to the end user. Unwrapping of the electronic package is performed on the end user's computer system in response to a user input, such as the user's double-clicking with a mouse on an icon representing the software product. In response to the user input, the executable component activates a sales agent user interface that is customized with text and/or images for the ePOS associated with the request, based on the attached parameters.
Referring now to Figure 1, a network configuration to which the on-the-fly wrapping and downloading technique can be applied is illustrated. A processing system 1 of an end user (the consumer) has access to a number of ePOS processing systems 2 via the Internet backbone 3. Each ePOS 2 is associated with a different source (reseller, distributor, etc) of software. As noted above, an ePOS may be a conventional
Web site.
The end user may wish to purchase a software product from a particular ePOS 2. Each ePOS 2 may provide a relatively large number of different software products. However, there may be significant overlap between the products maintained by the various ePOSs 2. It is very time consuming and burdensome, however, to electronically wrap a product for each ePOS from scratch using its own set of parameters (bitmap, price, etc.).
Hence, referring now to Figure 2, the on-the-fly wrapping and downloading technique is implemented, at least in part, in processing system 4, hereinafter referred to as the "wrapping facility" 4, which is also coupled to the Internet backbone 3. The
wrapping facility 4 may be a single processing system, such as a personal computer, or multiple processing systems coupled to each other on a network, such as a local area network (LAN), as is also the case with the end user processing system 1 and each ePOS 2. When the end user at processing system 1 requests a software product from an ePOS 2, that ePOS 2 directs a modified request to the wrapping facility 4. In response to receiving the modified request, the wrapping facility 4 wraps the software product on-the-fly in a manner that is customized for the proper ePOS, and downloads the wrapped software package to the end user processing system 1, as will be described in greater detail below.
Figure 3 illustrates one example of the composition of a processing system, that is representative of any of the processing systems illustrated in Figures 1 and 2. Note that Figure 3 represents only one of many possible embodiments; thus, in other embodiments, components may be omitted or replaced with other components. The processing system includes a central processing unit (CPU) 10, random access memory
(RAM) 11, read-only memory (ROM) 12, each connected to a bus system 19. The bus system 19 may include one or more buses connected to each other through various bridges, controllers and/or adapters, such as are well-known in the art. For example, the bus system 19 may include a system bus that is connected through an adapter to one or more expansion buses, such as a Peripheral Component Interconnect (PCI) bus.
Also coupled to the bus system 19 are a mass storage device 13, a keyboard 14, a pointing device 15, a display device 16, and a communication device 17. The pointing device 15 may be any suitable device for enabling a user to position a cursor or pointer on the display device 16, such as a mouse, trackball, touchpad, stylus with light pen, or the like. The display device 16 may be any suitable device for displaying alphanumeric, graphical and/or video data to a user, such as a cathode ray tube (CRT), a liquid crystal display (LCD), or the like, and associated controllers. Mass storage device 13 may include any suitable device for storing large volumes of data, such as a magnetic disk or tape, magneto-optical (MO) storage device, or any of various types of Digital Versatile Disk (DVD) or compact disk ROM (CD-ROM) storage. The communication device
17 may be any device suitable for or enabling the processing system to communicate data with a remote processing system over communication link 18, such as a conventional telephone modem, a cable television modem, an Integrated Services Digital Network (ISDN) adapter, a Digital Subscriber Line (xDSL) adapter, an Ethernet adapter, or the like.
Note that some or all aspects of the techniques described herein may be embodied in software. That is, the techniques may be carried out in a computer system in response to its CPU executing sequences of instructions contained in memory. The instructions may be executed from RAM, for example, and may be loaded from a persistent store, such as a mass storage device and/or from one or more other remote computer systems.
In various embodiments, hardwired circuitry may be used in place of, or in combination with, software instructions to implement the described techniques. Thus, the described techniques are not limited to any specific combination of hardware circuitry and software, nor to any particular source for the instructions executed by a computer system.
Referring now to Figure 4, the wrapping facility 4 implements a wrapping process 24. The wrapping process receives as input the source code 22 of a requested software product and data stored in a database 28, and outputs a wrapped software package 26, which may be downloaded to the requesting end user. The database 28 includes, for each product serviced by the wrapping facility 4, various parameters that are specific to each ePOS, that product. These parameters include, for example, the bitmap and price associated with each ePOS for each product. Hence, the wrapping facility 4 receives a request from an ePOS 2, including a store keeping unit (SKU) identifier (ID) that identifies the requested product and a store ID that identifies the ePOS. Accordingly, the wrapping process 24 can access the appropriate parameters in database 28 for the requesting ePOS and the requested product and generate a customized wrapped software package 26.
Figure 5 illustrates a process that may be implemented in an ePOS 2 in connection with an end user's request to download a software product. Assume that while viewing a hypertext web page generated by an ePOS 2, the end user selects a hypertext anchor representing a software product. Thus, at 501, the ePOS 2 receives a request for the software product from an end user, which may be in the form of a uniform resource locator (URL), for example. In response to receiving the request, the ePOS 2 transmits a modified request to the wrapping facility 4 at 502. The modified request may also be a URL. The request is modified to include the SKU ID of the requested software product and the store ID of that ePOS. At 503 the ePOS then waits for a notification from the wrapping facility 4 that the wrapped software package is ready for download. When the notification is received, then at 504, the ePOS transmits an HTTP redirect to the processing system 1 of the end user, signaling the
processing system 1 to connect directly to the wrapping facility 4 to receive the requested software product.
Figure 6 shows a routine that may be implemented in the wrapping process 24, by which the wrapping facility 4 may respond to a request for an electronic download. At 601, the wrapping facility 4 receives the request to download the software from an ePOS 2. At 602, in response to the request, the wrapping facility 4 generates a wrapped software package that is customized for the requesting ePOS. When the wrapping process is complete at 603, such that the wrapped electronic package is ready for download, then at 604 the wrapping facility 4 transmits a notification of this fact to the requesting ePOS using any appropriate signaling technique, such as an HTTP signal.
The wrapping facility 4 then waits at 605 for the end user processing system 1 to connect to it, which is done in response to the HTTP redirect mentioned above. Once the processing system 1 of the end user has connected, the wrapping facility 4 transmits the wrapped software package to the end user at 606. The wrapped software package may be streamed to the end user processing system 1, if desired. Alternatively, the wrapped software package may be cached as a file within the wrapping facility (or elsewhere) and the processing system 1 given the location of that file. In the latter case, the wrapped software package may then be reused for other end users requesting the same software product from the same ePOS, to further speed up the ESD process. Figure 7 illustrates the elements of the wrapping facility 4 in greater detail, according to one embodiment. The wrapping facility 4 includes a server component 32, a cache 33, a wrap engine 34, and, as mentioned above, the database 28. Database 28 includes a software product library 38 and a parameters database 36. Parameters database 36 stores the parameters specific to each ePOS, such as bitmap and store ID, including parameters specific to both a particular product and ePOS, such as price and/or custom text. Thus, the server 32 can access parameters in database 36 using the store ID and SKU ID provided in a request as indeces.
The software product library includes a number of pre-build wrappers 40. Each pre-build wrapper 40 is associated with a particular software product but is not associated with any particular ePOS (i.e., it is generic). In one embodiment, there is one pre-build wrapper for each software product serviced by the wrapping facility 4. In another embodiment, for each software product there is one pre-build wrapper that is used for buy-only downloads and another pre-build wrapper that is used for all other download modes. In yet another embodiment, each type of download mode (i.e. buy only and try-and-buy) has a distinct pre-build wrapper. Each pre-build wrapper
generally includes the source code of the software product, some or all of which may be encrypted, and an executable component, as will be described below.
Thus, in response to a request from an ePOS, the server 32 performs a lookup in the database 36 using the store ID of the requesting ePOS and SKU ID of the requested product, as provided in the request, to retrieve the appropriate parameters
(bitmap, price, custom text, etc.). These parameters are then incorporated by the server 32 into a plain text configuration file, such as a .INI file. The following is an example of an .INI file that may be used for this purpose:
BITMAP = macr_syn.bmp TEMPLATE_NAME = wrapper.exe
BOB_NAME = Marble.bob
PROGRAM_NAME =
PROGRAM D = 200000
PROGRAM_PASSWORD = sakjfdsklfjdskfsdf PROGRAM_SOUE.CE = 200000
ENCODE_KEY = jkfjdkfjsdfds
SERIAL_NUM_MODE = 0
CANADA_SAME_AS_US = 1
SHOW JCENSE - 0 LICENSE_TEXT = This software package is licensed to the user . . ..
WRAP_ORIG_FILENAME = Marble.exe
WRAP_ORIG_FILESIZE = 16444406
WRAP_SETUP_EXE - Marble.exe
WRAP_OUTPUT = mywrap.exe MAIN_TEXT =
Thank you for downloading Marble Software from Egghead Software! For more software titles, please visit us again at www.egghead.com.
UNWRAP_PATH = c:\
FΓNISH_TEXT = UNWRAP_FOLDER = Download
CHARGE_TAX = 0
ONLINE_ONLY - 0
NUM_PRODUCTS = 1
PRODUCT_NAME = Marble Software PRODUCT_CODE = 987654
MIN JPURCHASE - 1
MAX_PURCHASE = 1
PRICE = 90.95
SHΓPPΓNG_USA = 1.95 SHIPPING_FOREIGN = 5.95
PRE_PURCHASE - 0 REQUIRED_PURCHASE = 0 PREPURCH_QUANTITY = 1 The .INI file produced by the server 32 is provided to the wrap engine 34. The wrap engine 34 retrieves the appropriate pre-build wrapper 40 for the requested
product from title library 38 and attaches the retrieved parameters to the pre-build wrapper in an encoded format to form the wrapped software package 26.
As shown in Figure 7, the wrapping facility 4 includes a cache 33, which is used for caching wrapped software packages for frequently requested products. Use of the cache 33 helps to reduce the overall time required to deliver a wrapped product to the end user. After a product has been wrapped with a particular set of properties (ePOS, price, etc.) to form a wrapped software package 26, it becomes available for download. At the same time, a physical copy of the wrapped software package 26 is stored in the cache 33, and a time stamp for that build is stored in a database. When another download request is received for that product with the same set of properties, instead of performing another wrap, the cached package is retrieved from cache 33 and downloaded. The time stamp for that build is then updated to reflect the download time of the new request.
Garbage collection is performed at regular intervals, such as every 30 minutes. A background process scans all time stamps and removes all cached files that are more than, for example, 30 minutes old. The length of this time period can be increased to increase overall system response time, or it can be reduced to reduce disk storage requirements.
Figures 8A and 8B illustrate examples of wrapped electronic software packages that may be produced by the wrapping facility 4. As mentioned above, software can be downloaded using the techniques described herein using several different modes, including buy-only, try-before-buy, try-only, and rental. Figure 8A illustrates an example of the composition of a wrapped software package 26A associated with the buy-only mode. Figure 8B illustrates an example of the composition of a wrapped software package 26B associated with any of the other modes. In one embodiment, the wrapping facility 4 maintains in title library 38 two pre-build wrappers for each software product, such that one of the two is used for buy-only downloads and the other is used for all other types of downloads. The parameters associated with a particular ePOS may include an indication of which download mode the wrapping facility 4 is to support on behalf of that ePOS for each title.
As shown in Figure 8A, the pre-build wrapper 26A for the buy-only model includes an executable component 42, a bitmap 44, parameters other than the bitmap 46, the encrypted source code 48 of the requested software product, and a number of offsets 50. Note that a pre-build wrapper 40 consists essentially of these same elements, except for the bitmap 44 and other parameters 46. The bitmap 44 and other
parameters 46 are specific to a particular ePOS (and in some cases, to both a particular ePOS and product). The on-the-fly wrapping process includes attaching the appropriate bitmap 44 and other parameters 46 to the pre-build wrapper 40 and modifying the offsets 50 as appropriate to indicate the starting locations of the bitmap 44, other parameters 46, and encrypted software 48.
The executable component 42 is configured for execution by the end user processing system 1 to generate the sales agent interface by which the end user can enter user information and submit payment. In addition, the executable component 42 is configured to decrypt the encrypted software 48 in response to receiving an authorization signal from the wrapping facility 4. The offsets 50 are read by the executable 42 and indicate the starting locations of the bitmap 44, other parameters 46, and encrypted software 48 within the wrapped software package 26A.
Figure 8B illustrates an example of a complete wrapped software package 26B associated with download modes other than buy-only. As with the buy-only mode, the wrapped software package 26B includes an executable component 52, a bitmap 54, and other parameters 56, as well as offsets 60 indicating the starting locations of the nonexecutable components. However, instead of the encrypted source code 48, the software wrapper 26B includes an installation package 58. The installation package 58 includes a modified version of the original install program of the software product and several additional files as will be described below.
Generally, the modifications to the original install program involve minor adjustments to the install program's script files. This includes, for example, renaming the main executable module of the software (e.g., word.exe) with a substitute name (e.g., word.dl_). The executable 52 is given the original name of the main executable. Thus, the additional files added to the installer may include a combination of: the replacement main module (e.g., word.exe) generated by the wrapping facility 4; the encrypted main module (e.g., word.dl_); auxiliary files configured to allow restoration ("popping") of the original source code, disabling of particular features of the software, generation of the sales agent interface, and other auxiliary files; a bitmap; and, a configuration file containing information customized for the corresponding ePOS.
Upon the end user's selecting (clicking on) the downloaded wrapper, the following actions occur: The bitmap and configuration file are extracted to a predefined location, for example, c:\windows\Release\{product_ID}; the modified installation package launches and installs the software; and, when the main program is
run for the first time, it fetches the bitmap and configuration parameters from the predefined location.
Figure 9 illustrates a process that may be implemented in the wrapping facility 4 to create pre-build wrappers 40. In particular, Figure 9 is associated with constructing a pre-build wrapper for a buy-only download. Thus, at 901 the software source code of a given software product is encrypted. In one embodiment, 128-bit RC2 encryption is used. At 902 the wrapper executable 42 (see Figure 8A) is attached to the encrypted source code to form the pre-build wrapper 40.
Figure 10 illustrates a process for constructing a pre-build wrapper for a non- buy-only download (i.e., a try and buy, try-only, or rental download). After loading the software product onto a computer system, the modules of the software product that are desired to be protected are identified. That is, it may be desirable to only allow the end user to access certain functions or features of the software product or to otherwise control the user's use or access of the software product. Consequently, the appropriate modules are identified at 1001 and then encrypted at 1002 to form a modified main module. At 1003, the additional files mentioned above (the auxiliary files and the sales agent files) are generated. The modified main module is renamed with a new file extension, such as the DLL_ extension, as mentioned above. At 1004, the original installer of the software is reconstructed to generate the new installation package. At 1005, the wrapper executable 52 is attached to the installation package 58 with the
.EXE extension to form a pre-build wrapper.
After the pre-build wrappers have been constructed offline, a complete wrapped software package can be quickly and easily constructed on-the-fly in response to a download request in a manner that is customized for a particular ePOS. Figure 11 illustrates a routine by which the on-the-fly wrapping may be accomplished. At 1101, the wrap engine 34 attaches the bitmap and other parameters associated with the requested software product and the associated ePOS to the appropriate pre-build wrapper for the requested product. At 1102, the wrap engine 34 modifies the appropriate offsets of the pre-build wrapper based on the size of the bitmap and the other parameters. Once the offsets have been modified, the package is considered to be wrapped and ready for downloading. It may be desirable, however, to perform error detection and correction and/or other quality assurance measures prior to performing the download.
Figure 12 illustrates a process that may be implemented in the processing system 1 of the end user to "unwrap" a downloaded wrapped software package. In
particular, Figure 12 is associated with a buy-only download. At 1201, the user provides an input for initiating or otherwise selecting the downloaded software, such as double-clicking on a displayed program icon. In response to this user input, the executable of the wrapped software package accesses the bitmap and other parameters and launches the sales agent interface at 1202. Accordingly, the initial screen which the user sees (the "splash" screen) may include the bitmap and any custom text and is therefore custom tailored for the ePOS from which the software was requested. As noted above, the sales agent interface enables the user to enter user information and payment information. When the user has entered all of the required information at 1203, the information is then transmitted to a clearing house at 1204. The clearing house may be included within (i.e., a component of) the wrapping facility 4, or it may be a completely separate facility on the Internet. Upon receiving authorization to proceed from the clearing house at 1205, then at 1206 the executable component of the wrapped package decrypts the software and notifies the user that the purchase has been approved. If no authorization is received or a denial of authorization is received, the user is notified accordingly at 1207, and no decryption of the software is performed.
Figure 13 illustrates a routine that may be implemented in the processing system 1 of the end user to unwrap a downloaded software package for modes other than the buy-only mode. At 1301 a user input selecting the program icon is received. In response, at 1302 the executable of the wrapped software package extracts the bitmap and other parameters into temporary files and stores them in an appropriate location in the processing system 1, such as in the program's root directory or the system folder. At 1303, the modified installation package is run, and at 1304 the sales agent interface is initiated as appropriate. Thus, a method and apparatus for performing on-the-fly wrapping of information for electronic distribution in a customized manner have been described. Although the present invention has been described with reference to specific exemplary embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the invention as set forth in the claims. Accordingly, the specification and drawings are to be regarded in an illustrative sense rather than a restrictive sense.