CA2145922C - Method and apparatus for enabling trial period use of software products: method and apparatus for utilizing an encryption header - Google Patents

Abstract

A method and apparatus is provided in a data processing system for securing access to particular files which are stored in a computer-accessible memory media. A file management program is provided as an operating system component of the data processing system. A
plurality of files are stored in a computer-accessible memory media, including at least one encrypted f1le and at least one unencrypted f1le. For each encrypted f1le, a preselected portion of the file is recorded in memory, a decryption block is generated which includes information which can be utilized to decrypt the file, and the decryption block is incorporated in the file in lieu of the preselected portion which has been recorded in memory. Then, a file management program is utilized to monitor data processing system calls for files stored in the computer-accessible memory media. The file management program determines whether the called file has an associated decryption block. The called file is processed in a particular manner dependent upon whether or not the called file has an associated decryption block.

Description

METHOD AND APP~RATUS FOR ENABLING TRIAL PERIOD USE OF
SOFTWARE PRODUCTS: METHOD AND APPARATUS FOR UTILIZING AN
ENCRYPTION HEADER

BACKGROUND OF THE INVENTION

I . Tcchnical Ficld:

The present invention relates in general to techniques f -r securing access to software objects, and in particular to teehniques for tcmporarily encrypting an(3 restricling aeees,s to software objeets.

2. Description of the Relatcd Art:
The ereation and sale of software produets has ereated tremendous wealth for eompanies having innovative produets, and this trend will eontinue particularly sinec consumers are beeoming ever-more eomputer literate as time goes on. Computer s,(1ftwal~c is difficult to market sinee the potential user has little opportunity to browse the various produels that are available. Typically, the produets are eontained in boxes which are shrink-wrapl-ed elosed, and the potential customer has little or no opportunity to aelually intel~act with or expcrienee the software prior to purchasing. This causcs considerable consumet~ dissalisracliol1 with products, since the consumer is frequently forced to serially pUl~CIla.SC a plurality of softwalc pro(lucts until an aceeptable product is discovered. This is r)erhaps one signiricant cause Of the great amount of software piracy which occurs in our econon1y. A potential software purchaser will frequently "borrow"
a set of diskettes from a frien(l or business associate, with the stated ;ntention of using the software for a temporary perio(l. Frequently, sLIell temporary use extends for long intervals and the potential eustomer may never aetually ,nurehase a eopy Of thc software produet, and may instead rely upon the borrowed eopy.

DA9-94-0 l 0 2 Since no common communication cl1al1t1el exislls for tl1e sampling of software products, such as those created in movie theatrcs by movie trailers, and in television by commercials, software manufacturers are forced to rely upOn printed publicalions and direct mail advertisements in order to advertise ncw producls and solicit new cuslon1els. Unfortunately, printed publications frequently fail to provide an accurate descIiption or Ihc prod-lct, since the user interaction with the procluct cannot be simulaled in a slatic plinlc(l rormat. Tl1e manufacturers of computer software products and the customers woul(l both be well served if the customers could have access to the products prior to making (Iecisions on whell1er or not to purchase the product, if this could be accomplishecl witl1out intro(lLlcing risk or unlawflll utilization of the product.

The distribution of encrypted .software prod~lcts is one mecl1anism a software vendor can utilize to distribute the product to potential USCI5 prior to purchase; however, a key must be distributed which allows the user access to the pro(luct. The vendol- i.s lhen forced to rely entirely upon the honesty and integrity Or a potential customel-. UnscJ upulous Or dishonest ind;viduals may pass keys to their friends and bush1ess associate.s lo allow unauthorized access. It is also possible that unscrupulous individuals may post keys to pLlblicly-accessible bulletin boards to allow great numbers of individuals to become ul1autl1orized users. Typically, these types of breaches in security cannot be easily prevel1te(1, so vendols have l-een hesit;allt to distribute software for preview by potential customels.
SUMMARY OF THE lNVENrlON

It is one object of the presenl invel1tion lo r~ro\~i(lc a metl1od an(l apparatus for distributing software objects from a producel to polel1~ial u~iers ~hicl1 allo~s thc user a temporary trial period without subjecting the soltwale prodLlcl lo ut1l1ecessaly risks of piracy or unauthorized utilization beyond the trial interval. Prerelably Ihis is accomr)lisl1ed by providing a software object on a compuler-accessible memory media along with a file management program.
Preferably, the software objecl is reversibly functionally limited, through one or more particular encry~tion operations. The computer--accessible memoly media ;s shipped from the producer to DA9-94-0 l O 3 the potential user ut;liz;ng convenlioncll mail and delivery services. Upon receipt, the potential user loads the file managemel1t prngram into a uset-contl~olled data processing system and associates it with the operating s~stem ror the clata processing system. Then, the computer-accessible memory media is read utilizing the usel-conllolle(l data processing system. The file management program is executed hy the user-col1trolled data plocessing system and serves to restrict access to the software object rOr a predefine(l and temporary trial period. During the temporary trial mode of operation, t]1e softwate object is temporarily enabled by reversing the reversible functional limitation of the sorlwale object. This is preferably accomplished by decryption of the encrypted sOrtwL3le objecl whell the softwale object is called by the operating system of tlle user-controlled clata proccssing systen1. Tl1e file management program preferably prevents copying operations, so the encrypted softwale project is temporalily decrypted when it is called by the operating Systel11. If the potential Ll~er elects to purchase the software object, a permanent use mode of operation is entere(l, wherein the functional limitation of the software object is permanently reversed, allowit1g unlimite(l use to the software object by the potential user. This facilitates browsing operations which allow the potential user to review the software and determine whether it suits his or her needs.

The file management program contil1uously monilors the operatil1g system of the user-controlled data processing system for o~,erating syslell1 inpul calls an(l output calls. Thc fille management program identifies when tl1e operating systetn of the user-conttolle(l data processing system calls for a software object which is subject to trial-intelval hrowsing. Then, the file management system fetches a temporary acces~ key asc,oci;lled wilh ll1e sol'tw.lre object, and then examines the temporary access key to delet mine ir il i~ v<lli(l. Next, the file management program reverses the functional limitation of lhe ~ortwale ol jecl, al1(1 pclSSCS il lo lhC data pl-ocessing system for processing.

It is another objective of the present invenli(-n to ptovi(le a metl1od and apparatus for distributing a software object fton1 a soulce to a uset, whereil1 a software object is encrypted utilizing a long-lived encryption key, an(l direcle(l ftom the sourcc to the user. The encrypted DA9-94-01 () 4 software object is loaded 011t(1 a user-controllecl d.lta processing system having a particular system configuration. A numerical macl1ine klel1til'ication based at Ieast in part upon the particular configuration of the uscr-conlrolled d.lta processing system is lhen derivcd. Next, a temporary key is derived whicl1 is based al Ieast in part upon thc numerical machine identification and the long-lived encryption key. A long-lived key gcnerator is provided for receiving the temporary key and producing the long-lived encryption key. The temporary key allows the user to generate for a prescribed interval tllc long-livcd encryption key to access the software object. These operations are perrormcd pril1cipally by a file management program which is operable in a plurality of modes. These modes include a set up mode of operation, a machine identification modc of operatiol1, and a temporaly key derivation mode of operation.
During the set up modc of operation, thc rile management program is loaded onto a user-controlled data processing system and associated with an operatil1g system for the user-controlled data processing system. During the machine idenlificatioll mode of operation, the file management program is utilized to derive a numel ical machine identification based upon at least on attribute of the user-controlled data processing syslem. During the temporary key derivation mode of operation, a temporary key is derived which is based at Ieast in part upon the numerical machine identification. The filc mal1agement program also allows a trial mocle Or operation, wherein the file management plogram is utilized by executing it with the user-controlled data processing system to resttict access to ll1e software object i'or an interval defined by the temporary key, dllring which lhe long-live(l key generalor is utilized in the user-controlled data processing system to provide the long-live(l key in responsc to receipt of at Icast one input including the temporary key.

It is yet another objective of the plesent invention lo provide a metl1od and apparatus in a data proeessing system for securing access to particulal filcs which are slored in a computer-accessible memory media. A file managcment progr.3l11 is pro\~ided as an operating system component of the data processing system. A plurality or riles are slored in the computer-accessible memory media, including at least one encrypte(l file and at Ieast one unencrypted file. For each encrypted file, a preselected portion is rccol-(lc(l in computer memory, a decryption block is generated which includes information which can be utilizecl to decrypt the file, and the decryption block is incorporated into the file in lieu of the preselected portion which has been recorded elsewhere in computer meml!ry. The file rmanagement program is utilized to monitor data processing operation calls for a called rile stored in the computer-accessible memory media.
The file management program determines whether the calle(l file has an associated decryption block. The file management program processes the called file in a parlicular manner dependent upon whether or not the callecl file has an associate(l (iecryption block. The incorporation of the clecryption block does not change the size of the encrypte(i file, thus pre~enting certain types of processing errors. During the trial intelval, tlle encrypted file is maintained in an encrypted condition, and cannot be copie~l. If the polelllial USCI opts to purchase the software product, a permanent key is pro~ided which results in replacement of the preselected portion to the file in lieu of the decryption block. Once the decrypti(ln hlock is removed, the encrypted file may be decrypted to allow unrestricted use by the purchasel~. Prererably, the file management program is utilized to intercept files as lhey are called hy the operating system, and to utilize the decryption block to derive a name for a key file and read the called file. The decryption block of each encrypted file includes a validation segment which is dccrypted by the file management program and compared to a selected segment for the calle~l file to determine whetller the key can decrypt the particular file. If the declyr)ted validation segment matches a known clear text validation segment, the file is thell dynamically decrypted as it is passed for further processing.
It is yet another objective of the present invenlioll to p rovkle a method and apparatus in a data processing system for securing access to particlllal riles wllicll al-e stolcd in a computer-accessible memory media. A file mana~enlent pro~l-am is pro~i(le(l as all operaling system component of a data processing system. ~n a computel-accessil~le memory rnedia available to the data processing system, at least one encl~ypte(l file an(l One unenclypted filc are stored. The cncrypted file has associated with it an unerlcryptecl SCCUIity s~ub whicll is at Ieast partially composed of executable code. The file management p rogram is utilizecl to monitor the clata processing system calls for a called file stored in the computer accessible memol-y media? to determine whether the called file has an associated unenclyr)ted security stuh, ancl to process the called file in a 21~5922 -DA9-94-0 l O 6 particular manner dependent upon whether ~lr not the calle(l file has an associated unenerypted security stub. More partieularly, if it is determined that the called filc has no assoeiated unenerypted seeurity stub, the ealled file is allowe(l lo be proccssed. However, if it is determ;ned that the called file has an assoeiated unencrypted security stub, it must be examinecl before a decision ean be made about whether Ot nol to allow it to be proeessed. First, the unenerypted seeurity stub is examined in order to obtain h1formation whieh allows deeryption operations to be performed. Then, the deeryption opera~ions are perrorme(l. Finally, the ealled file is allowed to pass for further proeessing. Preferably, the called file is dynamieally dcerypted as it is passed to the operating system for proccssing. Also, the unenclypted security stub is separated from the ealled file prior to execution of the calleci file. I-lowever, if the unencrypted security stub aceidentally rema;ns attaehed to the callcd file, processing operalions must be stopped, and a message must be posted in or(ler to plevent the pl~ocessol rrom becoming locked-up.

It is still another objeetive of the presen~ invention to provide a method and apparatus for distributing a software objeet from a source to a user. A computer-aeeessible memory media is distributed from the SOUtCC to a potential user. It includes a software object which is encrypted utilizing a predetermined encryr-tion engine and a long-lived and secret key. An interfaee program is provided whieh faeilitates inleractiol1 between tllc source and the user. The interface program ineludes maehine idenlificatiorl mod-lle whieh generates a machine identifieation utilizing at least on predetermined attl ibute of the user-eol1trolle(1 data proeessing system. It also further ineludes a long-lived and SCClCt key genela~or which receives as an input at least a temporary key and produces as an olltrut a long-lived an(l secret key. A validation module is provided which tests temporarS~ key de~e~ ine(l itS V ali(iity. The source of the software object maintains a temporary key genera~or wl1icl1 receives as an illpUt at Ieast a machine identification and produces an output of the temporary key. An interface program is loaded onto the user-eontrolled data processing systel-n. The macl1ine klel1tification module is utilized to examine at least one predetermined attribute of the user-contl-olled data plocessing system and to generate the maehine identifieation. During inleraction between the source and the user, the machine identifieation is communicated over an insecure communication channel. At the source of the _ 2145922 software object, the temporary key is generated utilizing the machine identification (and other information) as an input lo the temporaly key generalot. During interaction between the source and the user, the temporary key is communicated, typically over an insecure communication channel Next, the validation module is utilized to delermine tlle validity of the temporary key.
The long-lived and secret key gencrator is then utilized to reccive Ihc temporary key and generate the long-lived and secret key in order to decrypl and temporarily gain access to the software object. The user is also provicle(l with (3ll imporl module and an export module which allow for the utilization of portable memory media to transfel the encryplecl software object, a key file, and a machine identification filc fronl One machine in a dislributed data processing system to another machine in the distributed dala processillg system, while allowing the temporary key to allow temporary trial access to the sol't-~!clle object The above as well as additional objeclives, i'catures, an(l aclvantages of the present invention will become apparent in the following detailcd written dcscription.
BRIEF DESCRIPTION OF THE DRAWINGS

The novel features believed cllaracterislic of the inventioll are se~ forth in the appended claims The invention itself, however, as well as a pteret-led mo(le of use, further objectives and advantages thereof, will best he understoo(l by rerel-ence to thc following detailed description of an illustrative embodiment when read in con junctioll wilh the accompanying drawings, wherein:

Figure 1 is a pictorial repl-esentatioll ora ~tan(l-.llone dat(l plocessing system, a telephone, and a variety of computer-accessible memory media all of whicll may be utilized in the implementation of the preferted Iecllniclue ol' enabling trial p erio(l USC of software products;
Figure 2 is a pictorial reptesentation Of a distlibuted dala processing system which may utilize the technique of the present invelltioll Or enablin~ lrial petio(l use of software products;
Figure 3 is a block diagram rcpresell~atioll of dala processing system attributes wh;ch may be utilized to generate a machine idcntirication, in accor(lance with the present invention;

21~59~2 DA9-94-0 l O 8 Figurc 4 is a block diagram depiction of a routille for encrypting software objects;
Figure 5 is a pictorial representation of the exchange of information between a source (a software vendor) and a user (a customer) in accordclnce with thc teachings of the present invention;
Figurc 6 is a flowchart representation of the broa(l steps employed in building a user interface shell in accordance with thc p resent invention;
Figure 7 is a flowchart representatioll of venclor and customel- interaction in accordance with the present invention;
Figures 8 9 lOa ancl lOb (Iepict llser interfacc scl-eells which facilitate trial period operations in accordance with the present invention;
Figure l l depicts a user interface which is usc(l to initiale a tcmporary access key;
Figurc 12 is a block diagram dcpictioll of the preferl-ed techllique of generating a machine identifieation;
Figurc 13 is a block diagram (iepiclion of an encryption operation which is util;zed to encrypt a machine identification in accor(lance with tlle present invention;
Figure 14 is a block diagram replesentation of the prcferred technique for generating a product key in accordance witll the presellt invention;
Figurc 15 is a block (:liagram replesentation of a prefel-led technique utilizing a temporary product key to generate a real key whicll call be utilized to decrypt one or more software objeets;
Figurc~ 16 and 17 depicl: ~ prerel re(l technique of' validating the real key which is derived in accordance with the block diagram of Figurc 15;
Figure 18 is a block diaglalll depiction of the prel'el-l-ed routille for encyrpting a key file whicll contains information including a Iemllolaly plo(lLIct key;
Figure 19 is a block dilgtanl depiction ol' ~he preferre(l technique of handling an encryption header in an encrypted file in accor(lallce with the present invention;
Figure 20 depicts in block diaglalll folm ~he techllique of utilizing a plurality of inputs in the user-controlled data processillg syslem to delive the real key which may be utilized to decrypt an encrypted software object;
Figure 21 depicts a decryptioll opetalion lltilizing thc real key derived in accordance with _ 2145922 DA9-94-0 l 0 9 Figure 20;
Figure 22 is a block diagram clepietion of a comparison operation whieh is utilized to determine the validity of the real key;
Figure 23 depiets a deeryption operation utilizing a validated real key;
Figures 24, 25, 26, 27,2X depiet the utilization of an encryption header in aeeordanee with the present invention;
Figures 29a and 29b set forth a flowehart representation of the preferred teehnique of providing a trial period of use for an enerypted software ohjeet;
Figures 30 and 31 depict export an(l im~ort operations which may be utilized to perform trial period use operations in a distributed data proeessing system;
Figures 32 and 33 provide an alternative view of the import and export operations which are depieted in Figures 30 and 31;
Figures 34 and 35 provide a bloek diagram depiction of an alternative technique for performing an export/import operation.
DETAILED DESCRIPTION OF PREFERRED EMBODIMENT

The method and apparatus of the present invention for enabling trail period use of software products can be utilized in stand-alone PCs such as that dep;ctcd in Figure 1, or in distributed data proeessing systems, sueh as that depicted in Figurc 2. In either event, temporary trial period aecess to one or more software pro(lucts depends UpOIl utilization of the trial product on a particular data proeessing system witl1 particulal~ data processing system attributes. This is accomplished by encrypting the trial softwat-e pl-oduct ulilizing a temporary access key which is based upon one or more data processing system attributes. Figurc 3 graphically depicts a plurality of system eonfiguration attributes, whieh may be utilized in developing a temporary aceess key, as will be deseribed in greater detail herebelow. To begin with, the environment of the stand-alone data proeessing system of Figurc 1, and the distributed data proeessing system of Figure 2 wi]l be deseribed in detail, followed by a deseription of partieular system eonfiguration attributes whieh are depieted in Figurc 3.

21~5922 With reference now to the figures and in particular with reference to Figurc 1, thcre is depieted a pictorial represe~tation of data processing system 10 which may be programmed in accordance with the present invention. As may be seen, data processing system 10 includcs processor 12 which preferably includes a graphics processor, memoty device and central processor (not shown). Coupled to processor 12 is video display 16 which may be implemented utilizing either a color or monochromatic monitor, in a manner wcll known in the art. Also coupled to processor 12 is keyboard 14. Keyboar(l 14 preferably comprises a standard computer keyboard which is coupled to the processor by means of a cable.

Also coupled to processor 12 is a graphical pointing device, such as mouse 20. Mouse 20 is coupled to processor 12, in a manner well known in tllc art, via a cable. As is shown, mouse 20 may include left button 24, and right butlon 26, each of which may be depressed, or "clicked", to provide command and control signals to data processing s~slem 10. While the disclosed embodiment of the present invention utilizes a mouse, those skilled in the art will appreciate that any graphical pointing device such as a light pen or touch sensitive screen may be utilized to implement the method of the presellt invention. Upon refetence to the foregoing, those skilled in the art will appreciate that data processing system IV may be implcmented utilizing a so-called personal computcr, such as the Mo(-lel ~() PS/2~ computer manufactured by International Business Machines Corporation of Arlllonk? New York.
While the present invention may be ulilizcd in stand-illone data processing systems, it may also be utilized in a distributed data plOCC.'iSillg systcm, plovi(lc(l the import and export routines of the present invention are utilized to tr.ln~rel- One Or more encl-ypted files, their encrypted key files, and associated file managemenl programs thl-ougl1 a portable memory media ~such as diskettes or tapes) between particular data processing units within the distribute(l data processing systern. While the import an~l export roLItines of the present invention will be described in greater detail herebelow, it is important that a basic distrib~lte(l data processing system be described and understood.

_ 2I4592~

Figure 3 provides a block (liagram depiction of a plurality of data processing system attributes which may he utilized to uniquely identiry a pal~ticular data processing system (whether a stand-a]one or a nocle in a distributed data processing sy~tem), and which further can be utilized to generate in the machine identification value which is utilized to del-ive or generate a temporary access product key which may be utilize(l to gain access to an encrypted product for a particular predefined trial interval. A data processing system may include a particular system bus 60 architecture, a particu]ar memory controller 74, hus controller 76, interrupt controller 7X, keyboard mouse controller ~30, DMA conlroller 6~, VGA video controller X2, parallel controller 84, serial controller X6, diskette contloller XX, and disk controller X2. Additionally, a plurality of empty or occupied slots 106 ma,y be used lo identify tlle particular data processing system.
Each particular data processing syslem may have attrihutes wllich may be derived from RAM
70, ROM 68, or CMOS RAM 72. E~nd devices sucll as prillter 96, monitor 94, mouse 92, keyboard 90, diskette 100, Or disk drive 104 may be utilizecl lo delive one or more attributes of the data processing system which may be processe(l in a predetermined manner to derive a machine identification value. The deriva~ion Or the machine identification value will be described in greater detail below. The present invention is direclecl to an efricient method of distributing software programs to users which woul~l provide to them a means to try the program before obtaining (by purchasing) a license rOr it. In accordallce ~ith this concept, complete programs are distributed to potential users On comput,er-accessihle memol-y media sucll as diskettcs or CD-ROMs. The concept is to generate keys that allow the USCI~ to access the programs from the distributed media. In this environment, a file management program provides a plurality of interfaces which allows the USCI lo hlO\~ C thc di~fCtClll plO(IUClS. The interfaces allow orclering and unlock;ng of the software producl,s contaille(l On the distrib~lte(l media. Unlocking of the software product is acconnplislle(l hy the recertion, ~alidatioll, an(l recording of a temporary access (decryption) key.

The file 1nanagement program is resi(lellt in the user-colltrolled data processing system and becomes a part of the operat;ng system in ~hc USCI'S computer. An example of such a resident program (in the PC DOS environmen~) w(lul(l be a resi(lent program TSR, for "terminate and ~.

stay resident" operations, that intercepts and handles DOS file input and output operations.
When a ternporary access key is pl0vi(1ed to a user, system files are checked to see if this file has been used in a trial mode of operation berore. If the product has never been used in a trial mode of operation, the temporary key is saved. Once lhe trial mocle of operation key exists, an encrypted application can only be run if it is initiate(l by the file management program. The file management program will recognize that the application is encrypted and that a valid trial mode of operation key exists for the particular operatioll. A valid trial mode of application key is one that has not expired. The trial mo(le of operation may be deritled by either a timer, or a counter.
A timer can be used to count (lown a partic~llal prederille(l period (such as thirty days);
alternatively, the counter can be llsed to clecrement through a predefined number of trial "sessions" which are allowed durirlg the trial mode of operation. If the key is valid, the file management program communicates directly with the TSR an(l enables the trial mode of operation for a particular encrypted application. The rile management program then kicks off the encrypted application. The code which is rcsident in the operating system of the user-controlled data processing systcm maintains control over the operating system. It monitors the use of the trial mode of operation keys to allow r~les to be decrypted and loaded into memory, but prevents the encrypted files ftom being decryp~ecl an-l copied to media. This is done by llsing the operating system to determille whicll applicatiolls are trying to access the data and only allowing the applications that have permission to access the data to do so.
Figure 4 is a block diagram depiction of a routine rOr encrypting software objects. The binary characters which make up software objcct 201 31C SUIlpliCd a.s an hlput to enctyption engine 205.
Real key 203 is utilized as an CllCI yptioll key ill encrypl ioll engille 205. The output of encryption engine 205 is an encrypted software ohject 207. Enct-yptioll CtlgillC 205 may bc any conventional encryption operation such as the published an(l well known DES algorithm; alternatively, the encryption engine 205 may be all cxclusive-OR operation whicll randomizes software object 201.

Figure 5 is a pictorial representation of the exchange of information between a source 209 (a software vendor) and a user 211 (a potenti,ll customer, in accordance with the teachings of the '- 2145922 present invention. The arrows between source 209 and user 211 reT~resent exchanges of objects or information between vendor 209 and 211. In the exchange of flow 203, computer-accessible memory media is directed from source 209 to user 211. This transfer may occur by US mail delivery, courier delivery, express service delivery, or hy dclivery through printecl publications such as books and magazines. Alternatively, an electronic document may be transferred from source 209 to user 211 utilizing electronic mail or other transmi.C~sion techniques. In flow 215, user-specific information, preferably including a unique machine identification number which identifies the data processing system of USCI 211, is trclnsfcrte(l from user 211 to source 209 via an insecure communication channel; typically, this hlformalion is exchangcd over the telephone, but may be passed utilizing electl-onic nlail Ot other communication t~chniques. In flow 217, source 209 provides a product key to user 211. The pro(luct key allows the product contained in the memory media to be tempol-arily accesse(l for a prescribed and predefined interval. This interval is considered to be a "~rial" hllerval durillg which user 211 may become familiar with the software and make a determination On whethet or not he or she wishes to purchase the software product. User 211 must communicate additionally with source 209 in order to obtain permanent access to the software product. The product key allows user 211 to obtain access to the software product for a particular prederitle(l time interval, or for a particular number of predefined "sessions." As time passes" the user's clock or counter runs down. At the termination of the trial period, further access is denie(l. Theref'ote, the us,er 211 must take affirmative steps to contact source 209 and purchase a r~ermallent key which is communicated to user 211 and which permanently unlocks a pro(luct to allow untesllicted access to the software product.

The communication between soulce 209 an(l USCt 211 is racilitate(l by a user interface. The creation of the interface is depicte(l in flowcllalt forln in Figurc 6. The process begins at software block 219, and continues al software block 221, wherein sOulce 209 makes language and locale selections which will deterlMine the language and currencies utilized in the interface which facilitates implementation Of the trial pclio(l use of lhe software products. A plurality of software products may be bundled togetller an(l delivered to user 211 011 a single computer-accessible memory media. Therefore, in accor(lance with software block 223, source 209 must ~ .

DA9-94-0 l 0 14 make a determ;nation as to the programs which will be made available on a trial basis on the eomputer-accessible memory media, an(l the apl~ropriate fields are completed, in accordance with software block 223. Next, in accordance with soflware block 225, the programs are functionally limited or encrypted. Then, in accotdance with softwal-e block 227, the shell is loaded along with the computer program proclucts onto a computer-accessible memory media such as a diskette or CD ROM. The process ends at sortware block 229.

Figure 7 is a flowchart representation of ven-Jor and customer interaction in accordance with the present invention. The f]ow begins at software hlock 231, and continues at step 233, wherein computer-accessible memory me(lia are clistribuled to users for a try-and-buy trial interval.
Then, in aecordance with step 235, the file managemellt program is loaded from the computer-accessible memory media 011tO a user-c(~ntl-olled data processing system for execution. The file managementprogram includes a pluralilyof interface screens which facilitate interaction between the vendor and the customer, which and which set forth the options available to the customer.
Thus, in accordance with step 237, the file management program allows browsing and displays appropriate user interfaces. Next, in accordance with step 239, the customer and the vendor interact, typically over the telephone or eleclronic mail, to allow tlle vendor to gather information about the customer and to distribute a temporary key wllich allows access to one or more software products whicll are contailled On the computer-accessible memory media for a predefined trial inlerval. Typiccllly, the hllel-val will be defilled by an internal clock, or by a counter which keeps track of the number of sessions the po~clllial purchaser has with a particular softwar-e product or producls. Step 241 represellts the ~ owallce of the trial interval use. Then, in accordance with software block 243, lhc filc man~lgcmcnl p rogram monitors and oversees all input and output calls in the dat:~1 pl-ocessing system to prevent unauthorized use of the encrypted software products contained On the compuler-accessible memory media. In the preferred embodiment of the presellt invelltion, the rile management program monitors for calls to enerypted files, and then determines whelher access should be allowecl or den;ed before the rlle is passed for furlher processing. The cuslomer can assess the software product and determine whether he or she de~ires lo purchase il. If a decision is made to purehase the DA9-94-0 l 0 15 product, the customer must interact oncc again with the vendor, and the vendor must deliver to the customer a permanent key, as is set fortl1 in step 245. The process ends when the customer receives the permanent key, decrypts the one or more software products that he or she has purchased, and is then allowed ordinary and ~lnrestrictcd access to the software products.

Figures 8, 9, 10a, and 10b depict user interface screetls which facilitate tr;al period operations in accordance with the present invention. I~igurc X depicts an order form user interface 249 which is displayed when the customer selects a "view ordcr" option from another window. The order form uscr interface 249 includes a title bar 251 which identifies the software vendor and provides a telephone number to facilitate interaction between the potential customer and the vendor. An order form field 255 is provided which identifies one or more software products which may be examined during a trial interval perio(l of operation. A plurality of subfields are provided including quantity subfield 259, item subfield 257, description subfield 260, and price subfield 253. Delete button 261 allows the potential customer to delete items from the order form field. Subtotal field 263 provides a subtotal of the prices for the ordered software.
Payment method icons 265 identify the acceptable forms of payment. Of course, a potential user may utilize the telephone number to directly contac~ the venclor and purchase one or more software products; alternatively, the user may select one or more sortware products for a trial period mode of operation, during which a sortware product is examined to determine its 20 adequacy. A plurality of function icons 2~'~7 are provi(led at the lowermost portion of order form interface 249. These include a close icOn, fax icon, mail icon, print icon, unlock icon, and help icon. The user may utilize a grapllicL~ ointing device ill a conventional point-and-click operation to select one or morc of these OpCIatiOIlS. The rax icon racilitates interaction with the vendor utilizing a facsimile maclline or facsimile bolltd. The print icon allows the user to 25 generate a papet archival copy of the inlerLIction with the sorlware vendor.

The customer, the computer-accessible memory media, an-l the computer system utilized by the customer are identified by media identirication 269, c~lstomer identification 273, and machine identification 271. The media identification is assigned to the coml~uter-accessible memory media 21~5922 '_ prior to shipping to the potential customer. It is rixed, and cannot be altered. The customer identification 273 is derived from interaction betwcen thc potential customer and the vendor.
Preferably, the customer provides answers to selecte(l questions in a telephone dialogue, and the vendor supplies a customer identification 273, which is unique to the particular customer. The machine identification 271 is automatically der ived utilizing the file management program which is resident on the computer-accessible memory media, and which is unique to the particular data processing system being utilized by the potential customet. The potential customer will provide the machine identification to the vendoI, typically through telephone interaction, although fax interaction and regular mail interaction is also possible.
Figure 9 is a representation of an order rorm dialog interface 275. This interface facilitates the acquisition of information which uniquely identifies the potelltial customer, and includes name field 277, address field 279, phone number ficld 2XI, facsimile number field 283, payment method field 285, shipping method field 287, accoun~ number field 289, expiration date field 291, value added tax ID field 293. Order information (lialog interface 275 further includes print button 295 and cancel button 297 ~hich allow thc ~otential user to delete information from these fields, or to print a paper copy of the interface screen.

Figures 10a and 10b dcpicl unlock dialog interface scl-eens 301, 303. The user utilizes a graphical pointing device to ~elcct one or more items wllich are identificd by the content item number field 307 and description field 309 which are components of unlock list 305. The interface further includes customer ID field 313 and machine ID field 315. Preferably, the vendor provides the customer identificatioll to the cuslomer in an interaction via phone, fax, or mail. Preferably, the customel provides to the ven(lor ~he machine identification within machine identification field 315 during interaction via phone, rax, or mail. Once the information is exchanged, along with an identification of the pro(lucts which are requested for a trial interval period of operation, a temporary acce~ key i~, provi(le(l which is located within key field 311.
The key will serve to temporarily unlock the products identified and sclccted by the customer.
Close button 319, save button 317, and help hutton 321 are also provided in this interface screen DA9-94-0 10 l 7 to facilitate user interaction.

Figure lOb depicts a single-product unlock interrace screen 303. This interface screen includes only machine identification field 315, customer i(lentirication field 315, and key field 311. The 5 product which is being unlocked need not be identified in lhis interface, since the dialog pertains only to a single product, and it is assumed that the user knows the product for which a temporary trial period of operation is heing requested. Save button 317, cancel button 319, and help button 321 are also provided in this interface to facilitate operator interaction.

Figure 11 depicts a user interface screen which is utilized in unlocking the one or more encrypted products for the commencement of a tri.-ll interval mode of operation. The starting date dialog of Figure 11 is displayed after the "SAVE" push hutton is selected in the unlock dialog of either Figure lOa or Figure lOb. The USCI will he promptecl to verify the correct starting date which is provided in date field 310. The user responds to the query by pointing and clicking to either the "continue" button 312, the "cancel" button 314, Or the "help" button 316. The date displayed in field 310 is derived from tlle system clock of the user-controlled data processing system. The user may have to modify the system clock to make the date correspond to the official or stated date of commencement of the trial period of operation.

20 A trial interval operation can take two rorms: OllC l~)rm i.', a functionally disabled product that allows a user to try all the features, but may n(lt allow a crilical function like printing or saving of data files. Another type of trial intelvcll is a fully runctional product that may be used for a limited time. This requires accesx prolec~il)ll, an(i allows a customer to Iry all the functions of a product for free or for a nominal fee. Tyl~ically, in accordance with the present invention, 25 access to the product is controlled through a "timed" key. The trial period for using the product is a fixed duration determined by the vendor. The trial period begin~, when the key is issued.
In accordance with the present invention, the r~roducts beiMg previewed during the trial interval of operation can only be run rrom withill a customer shell. A decryption driver will not allow the encrypted products to be copied in the clear, nor will it allow the product to be run outside _ DA9-94-0 l 0 18 the customer's shell. In an alternati\~e embodin1ent, the trial interval is defined by a counter which is incremented or decremented with each "session" the customer has with thc product. This may allow the customer a predefil1ed number of uses of the product before decryption is no longer allowed with the temporary key.

The limits of the temporary access key are l~uilt into a "control vector" of the key. Typically, a control vector will inc]udc a short description of the key, a machine identification number, and a formatted text string that includes the trial interval data (such as a clock value or a counter value). The control vector cannot be altered without breaking the key. When a protected software product is run, the usage dala musl be updated to enforce the limits of the trial interval period of operation. In or(ler to protect the clock or counter from tampering, its value is recorded in a multiple number of localions, typically in encrypted files. In the preferred embodiment of the present inventiol1, the trial interval information (clock value and/or counter value) is copied to a "key file" which will be describe(l in further detail herebelow, to a machine identification file, which will also be discussed hcrebelow, and to a system file. When access to an encrypted program is requested, all of these locations are checked to determine if the value for the clock and/or counter is the same. It is unlikely that an average user has the sophistication to tamper successfully with all three riles. 111 the preferred embodiment, a combination of a clock and a countcr is utili7c(l to prevent exlende(l use of backup and restore 20 operations to reset the system clock. Allhough it is p(1ssible to reset a PC's clock each time a trial use is requested, this can also be detecte(l hy Irackillg the date/time stamps of certain files on the system and using the most recent date hetweel1 rile-da/e/time stamps and the system clock. As stated above, onc of the lhl-ee localions lhe limer al1(l/or counter information is stored is a system file. When operatil1g in an OS/2 opel-ating system, the time and usage data can be 25 stored in the system data files, such as the OS2.1NI in the OS/2~ operating system. The user will have lo continuously backup and rcs~ore these files to reset the trial and usage data. These files contain other data that is significant to thc opel-ation Or the user system. The casual user can accidentally lose importanl data for other applications by rcstoring these fi]es to an older version. In the present invention, thcse prolectiol1 techniques greatly hinder a dishonest user's 21~5922 DA9-94-0l0 19 attempts to extend the trial interval use beyond the authorized interval.

In broad overview, in the preseMt invention, the ven(lor loads a plurality of encrypted software products onto a computer-acccssible memory media, such as a CD ROM or magnetic media diskette. Also loadecl onto the computer-accessible memory media is a fite management program which performs a plurality of functions, including the function of providing a plurality of user interface screens which facilitate interaction between the software vendor and the software customer. The computer-accessible memol y media is loaded onto a user-controlled data processing system, and the file managemel1t program is loaded for execution. The file management program provides a plurality of user-interface screens to the software customer which gathers information about the customer (name, address, telephone number, and billing information) and receives thc customer selections of the softwal~e products for which a trial interval is desired. Information is exchanged between the software vendor card customer, including: a customer identification number, a product identification number, a media identification number, and a machine identification number. The vendor gei~erates the customer identification number in accordance with its own internal record keeping. Preferably, the representative of the software vendor gathers information from the software customer and types this information into a established blank form in order to identify the potential software customer. Alternatively, the software ven(lor may receive a facsimile or mail transmission of the completed order information dialog interface screel1 275 (of Figurc 9). Thc distributed memory media (such as CDs and diskettes) also include a file management program which is used to generate a unique machine identirication basecl at Ieast in patt upon one attribute of the user-controlled data processing system. This macl1il1e i(lenlificcltioll is preferably a random eight-bit number which is created during a one-time ~etup process. Preferably, eight random bits are generated from a basic random number generat(1r USitlg the system time as the "seed" for the random number generator. Preferably, check bits are added in the final result. Those check bits are critical to the order system because persons taking ()îders must key in the machine ID that the customer reads over the phone. The check bits allow for instant verification of the machine ID without requiring the customcr to rcpeat the number. Preferably, a master file is maintained DA9-94-0 l O 20 on the user-controlled data processing system which contains the clear text of the machine identification and an encrypted version of the machine i(:lentification.

When the software customer places an order for a temporary trial use of the software products, he or she verbally gives to the telephone representative of the software vendor the machine identification. In return, the telephone representative gives the software customer a product key which serves as a temporary access key to the encrypted software products on the computer-accessible memory media, as well as a customer identification number. Preferably, the product key is a function of the machine identification, the customer number, the real encryption key for the programs or programs ordered, and a hIock of control data. The software customer may verify the product key by combining it with thc customcr number, and an identical block of control data to produce the real encryption key. This key is then used to decrypt an encrypted validation segment, to allow a compare operation. If the encrypted validation segment is identical to known clear text for the valiclation segmcnt, then the user's file management program has determined that the product key is a good product key and can be utilized for temporary access to the software products. Therefore, if the compare matches, the key is stored on the user-controlled data processing syslem in a key ~lle. Preferably, the key file contains the product key, a customer key (which is generaled from the customer number and an internal key generating key) and a clear ASCII string containing thc machine identification. All three items must remain unchanged in order for the declyption tool to derive the real encryption key. To further tie the key file to this particular useI-controlIe(l dala processing system, the same key rlle is encrypted with a key that is ~Ierived flom system parameters. These system parameters may be derived from the configuration of lhe data processing Syste~

Stated broadly, in the present invention the temporary key (which is given verbally over the phone, typically) is created from an algorithm that utilizes encryption to combine the real key with a customer number, the machine identification number, and other predefined clear text.
Thus, the key is only effective for a single machine: even if tl1e key were to be given to another person, it would not unlock the progIam on that other person's machine. This allows the software vendor to market software programs by distl-ibuting complete programs on computer-accessible memory media such as diskettes or CD ROM<" without significant risk of the ]oss of licensing revenue.

Some of the preferred unique attributes of the system which may be utilized for encryption operations include the hard disk serial numbel, the size and format of the hard disk, the system model number, the hardware interface cardc" the hardware serial number, and other con~lguration parameters. The result of this technique is that a machille identification file can only be decrypted on a system which is an idelllical clone of the user-controlled data processing system. This is very difficult to obtain, since most data processing systems have different configurations, and the configurations can only be matched through considerable effort. These features wi]l be described in detail in the following written description.

Turning now to Figure 12, the file management program receives the distributed computer-accessible memory media with encrypted software products and a file management program contained therein. The file management program assesses the configuration of the user-controlled data processing system, as represented in step 351 of Figure 12. The user-specific attributes of tlle data proces~ing system are (Ierivecl in step 353, and provided as an input to machine identification genel-ator 355, whicll is preferably a random number generator which receives a plurality of binary characters as an inpul, and genelates a pseudo-random output which is representative of machine identificatioll 357. The plOCCSS employed by machine identification generator 355 is any conven tiona I pseu(lo-rc] n(lom n u mber generator which receives as an input of binary characters, a nd pro(l uces as a n ou l put a plu l ality Or pseudo-random binary characters, in accordance with a predefine(l algorithm.
With reference now to Figurc 13, machine identification 357 is also maintained within the file management program in an encrypte(l form. Machine identificatioll 357 is supplied as an input to encryption engine 359 to produce as an output the encrypted machine identification 361.
Encryption engine 359 may comprise any convention encryption routine, such as the DES

21~5922 '",._ algorithm. A key 363 is provide(l al~so as an input to encryption engine 359, and impacts the encryption operation in a conventional manner. Key 3~3 is derived from system attribute selector 365. The types of system attrihutes which are candidates for selection include system attribute listing 367 which includes: the har(l disk serial number, the size of the hard disk, the 5 format of the hard disk, the system model number, the hardware interface card, the hardware serial number, or other configuration parameters.

In accordance with the present invention, the clear lext machine identification 357 and the encrypted machine identification 361 are maintained in memory. Also, in accordance with the present invention, the file management program automatically posts the clear text machine identification 357 to the ap,nropriate user interrace screens. The user then communicates the machine identification to the softwate vendor where it is utilized in accordance with the block diagram of Figure 14. As is shown, pro(luct key encryption engine 375 is maintained withi~ the control of the software vendor. This product key encryption engine 375 receives as an input: the machine identification 357, a customer numbcr 369 (which is assigned to the customer in accordance with the internal record keeping of this software vendor), the real encryption key 371 (which is utilized to decrypt the software products maintainecl on the computer-accessible memory media within the custo(ly of the sort~are customer), a control block text 373 (which can be any predefined textura] portion), and trial interval data 374 (such as clock and/or counter value which defines thc trial interval of use). Prod~lct key encryption engine produces as an output a product key 377. Product key 377 may be communicated to the software customer via an insecure communication chanllel, with(!ut risk of revealillg real key 371. Real key 371 is masked by the encryption operation, an{l SillCC Ihe pro(l-lct lcey 377 can only be utilized on a data processing system having a configu r ation idellticlll to that from which machine identification 357 has been derived, access to the encrypte(l software product is maintained in a secure condition.

Upon delivery of product key 377, the file managemenI program resident in the user-controlled data processing system utilizes real key generatot 379 to receive a plurality of inputs, including 2 ~

product key 377, customer number 369, control block text 373, m~.hine identification 357 and trial interval data 374. Real key generator 379 produces as an output the derived real key 381.

Encryption and decryption algo~ , utilized to perfor n the operations of the product key encryption engine 375 and the real key generator 379 (of Figures 14 and 15) is desclibed and cl~imed in U.S.
Patent No. 5,319,705, issued June 7, 1994, entitled "Method and System for Multimedia Access Control Enablement".

Next, as is depicted in Figures 16 and 17, the derived real key 381 is tested to determine the validity 0 and authenticity of the product key 377 which has been provided by the software vendor. As is shown, the derived real key 381 is supplied as an input to encryption engine 385. A pred~le,ll~ned encrypted validation data se~;lllt;l.l 383 is supplied as the other input to encryption engine 385.
Encryption engine supplies as an output derived clear validation text 387. Then, in accordance with Figure 17, the derived clear validation text 387 is co..,pared to the known clear validation text 391 in con,pa.~lor 389. Comparator 389 simply performs a bit-by-bit co"lp~ison of the derived clear validation text 387 with the known clear validation text 391. If the derived clear validation text 387 matches the known clear validation text 391, a key file is created in accordance with step 393;
however, if the derived clear v~lid~tiQn text 387 does not match the known clear validation text 391, a warning is posted to the user-controlled data processing system in accordance with step 395.
Turning now to Figure 18, key file 397 is depicted as in~ inE the temporary product key, the customer key (which is an encrypted version of the customer number), the m~.hine idçntific~tion number in clear text and the trial interval data (such as a clock and/or counter value). This key file is supplied as an input to ~ncly~Jlion engine 399. Key 401 is also provided as an input to encryption engine 399. Key 401 is derived from unique system attributes 403, such as those system attributes utilized in deriving the machine identification number. Encryption engine 399 provides as an output the encrypted key file 405.

Figures 19, 20, 21, 22, and 23 dcpict opcrations of thc file managcment program after a temporary access key has bccn rcceivcd, and validatc(l, and rccord~d in key file 397 (of Figure lX).

Fi~{~ure 19 is a block diagram rcprcscntation of ~he steps which arc pcrformed when an encrypted software product is called for proccssing by thc uscr-control data processing system. The encrypted file 405 is fetchcd, and a "headcr" portion 407 is read by the user-controlled data processing system. The hcadcr has a numbcr or componcnts including the location of the key file. The location of the key filc is utilizcd to fctch thc key file in accordance with step 409. The header further includes an encryptcd validation tcxt 411. Thc encrypted validation text 411 is also read by the user-controllcd data proccssing system. As is statcd above (and dcpicted in Figure 18) the key file includcx thc prodllct kcy 419, a customcr key 417, and the machine identification 415. These arc applicd as inpu~s to decryptioll engine 413. Decryptioll engine 413 provides as an output real key 421. Berore rcal key 421 is utilizcd to decrypt cncrypted software products on the distributed memory me(Iia, it is lestcd to dctermine its validity. Figure 21 is a block diagram of the validation tcsting. Encrypted validation lcxt 423, which is contained in the "header", is provided as an input to dccryption enginc 425. Real key 421 (which was derived in the operation of Figure 20) is also supplicd as an illpUt to decryplion engine 425. Decryption engine 425 provides as an output clear validation tcxt 427. As is sct forth in block diagram form in Figure 22, clear validation tcxt 427 i.s sullplic(l as an input to comparator 429. The known clear validation text 431 is also supplicd as an input to comparator 429. Comparator 429 determines whether the derivc(l clcar valida~ion tcxt 427 matchcs tlle known clear validation text 431. If the texts match, the sortwalc ol~jcct is dcclyl-lc(l in accordancc with step 433; however, if the validation text portions do not match, a walning is post in accordance with step 435.
Figure 23 is a block diagram dcpictioll Or thc (ICCrYPljOI1 opcration of stcp 433 of Figurc 22. The encrypted software object 437 is applicd as an input to dccl~yption cngine 439. The validated real key 441 is also supplicd as an input to dccryplioll engine 439. Dccryption engine 439 supplies as an output the dccryptcd sortwarc objcct 443.

The encryption header is proviclecl to allow ror the determination of whether or not a file is encrypted when that file is stored with clear-text filcs. In providing the encryption header for the encrypted file, it is important that the file size not be altered because the size may be checked as part of a validation step (unrelated in any way to the concept of the present invention) during installation. Therefore, making the file larger than it is suppose to be can create operational difficulties during installation of the software. The encryptioll header is further necessary since the file names associated with the encrypted softwal-e products cannot be moclified to reflect the fact that the file is encrypted, bGcausc the otheI software applications that may be accessing the encrypted product will be accessing those filcs utilizing the original file names. Thus, altering the file name to indicate that the filc is cncrytltc(l would prevent beneficial and desired communication between tlle ellcrypted sortware product and other, perhaps related, software products. For example, spreadsheet applications can usually port portions of the spreadsheet to a related word processing pro~ram to allow the integration of rinancial information into printed documents. Changing the hard-coded original file name for the word processing program would pre~lent the beneficial communication between these software products. The encryption header of the present invention resolves these problems by maintaining the encrypted file at its nominal file length, and by maintaining the file name for the ~oftware product in an unmodified form.

Figure 24 grapllically depicts an encrypted file with eneryption header 451. The encryption header 451 includes a plurality of code seglllents, including: unique identifier portion 453, the name of the key file portion 455, encl-yr~ted vali(iatiotl seglnellt 457, encryption type 459, offset to side file 461, and encrypte(l file data 4~3. or co~" sc, in this view, the encrypted file data 463 is representative of the encrypte(l sortware pro(luct, such as a word processing program or spreadsheet. The encryption header 451 is provided in place of encrypted data which ordinarily would cvmprise part of the encrypted sortware pro(luct. The encryption header is substituted in the place of the first portion of the encrypte(l software product. In order to place the encryption header 451 at the front of the encryptecl software pro(luct of encrypted file data 463, a portion of the encrypted file data musl be copied to another location. Offset to side file 461 identif1es that side rile location whcre the disp1aced file clata is contained.

Figure 25 graphically depicts the relationship between the directory of encrypted files and the side files. As is shown the directory of encrypted riles 465 includes rile aaa file bbb file ccc file ddd through fi]e nnn. Each of these riles i~ representative of a directory name for a particular encryptecl software product. Each encl-ypted software product has associated with it a side file which contains the front l~ortion of ~he file which has been displaced to accommodate encryption header 451 without altering the size or the file and without altering the file name.
File aaa has associated with it a side file AAA. Sortware product file bbb has associated with it a side file BBB. Encrypted software product ece ]las associated with it a side file CCC.
Encrypted software product ddd has associclted with it a side file DDD. Encrypted software product nnn has associated with it a side file NNN. In Figure 25 dh~ectory names 467 469 471 473 475 are dcpicted as being associaled with side files 477 479 481 483 and 485. The purpose of the side files is to allow each Or the encryptcd software products to be tagged with an encryption header without changing the ~lle size.

Encryption type segment 459 or the encryption heacler 451 idelltifies the ty~e of encryption utilized to encrypt the encrypted soflwlte pl-o(lucl. Any one of a number of conventional encryption techniques can he utilized lo encrypt the ptoduct an(l different encryption types can be utilized to encrypt different softwarc products containe(l on the same memory media.
Encryption type segment 459 ensurcs that the appropI iate encryption/(lecryption routine is called so that the encrypted software product may be decryple(J provided the temporary access keys are valid and not expired. Thc name Of key filc SCgll1Cllt 455 of encryption header 451 provides an address ~typically a disk drive localion) of the key file. As i~ st ated ahove (in connection with Figure 18) the key file includes the product key a customer key and the clear machine ID. All three of these pieces of information are required in order to generatc the real key (in accordance with Figure 20). Encrypted validation ~egment 457 inclu(le~ the encrypted validation text which is utilized in the routine depicted in ~igurc 21 which generales a derivecl clear validation text which may be compared utilizing the routine of Figurc 22 to the known clear validation text.

Only if the derived clear validation text exactly matcl1e~ the known clear validation text can the process continue by utilizing the derived and validated real key to decrypt the encrypted software product in accordance with the routine of l~igurc 23. However, prior to performing the decryption operations of Figurc 23, the contents of the corresponding side file must be substituted back into the encrypted sortware procluct in lieu of encryption header 451. This ensures that the encrypted software product is complete prior to the commencement of decryption operations.

Each time a file is called for processing by the operating system of the user-controlled data processing system, the file management program which is resiclent in the operating system intercepts the input/output requests and examil1es the front portion of the file to determine if a decryption block identifiel, such as unique identil'ier 453, exists at a particular known location.
For best performance, as is depicted in Figurc 24, this location will generally be at the beginning of the file. If the file management program delel mines lhat the file has the decryption block, the TSR will read the block into mcmory. The block is then parsed in order to build a fully qualified key file name by COpyil1g an environment variable that specifies the drive and directory containing the key files and concatenating the key file name from the encryption block. The TSR then attempts to open the key file. If the key file does not exist, the TSR returns an "access denied" response to the application which is attemptillg to oF-en the encryp~ed file. If the key file is determined to exist, the TSR opcns the key filc and reads in the keys (the product key, the customer key, and the machine idel1tificalion) and generates the real key. This real key is in use to decrypt the decryption block validation data. As is state(l above, a comparison operation determ;nes whether this decryl1tiol1 opetalion ~as successrul. Il' the compare fails, the key file is determined to be "invalid", an(l lllc TSR relurns an "access denied message" to the application which is attempting to open the encryptecl sorl~vare prod~lct. However, if the compare is successful, the file management program prepales lo decly[-t the file according to the encryption type found in the encryption header. The TSR then retull1s a valid file handle to the calling application to indicate that the filc has been opened. When the application reads data from the encrypted rlle, the TSR reacls and decrypls this data before passing it back to the application.

If the data requested is part or thc displacecl data tllat is store(l in the side file, the TSR will read the side file and return the appropriate decrypte(-l hlock to the calling application without the calling application beillg aware that the data came rrorn a separate rile.

While the broad concepts of the encryption header are depicte(J in ~igures 24 and 25, the more particular aspects of creating the encrypted files are clepicted in Figurcs 26, 27, and 28. ~igures 27 and 28 depict two types Or data riles. Figure 27 depicts a non-executing data f;le, while Figure 28 depicts an executing data file. Figurc 26 depicts a heacler 499 which includes signature segment 501, header LEN 503, side file index 505, sicle file LEN 507, clecryption type identifier 509, verirlcation data 511, and key file name 51 X. As is shown in Figurc 27, a software product begins as a clear file 521, and is encryptecl in accordance with a particular encryption routine into encrypted file 523. Encryption type segment 509 of header 499 identifies the type of encryption utilized to change clear file 521 to enclypted file 523. Next, the front portion of encrypted file 523 is copied to side file 527 which is iclentiriecl by side file index 505 and side file LEN 507 of header 499. Additionally, a copy of the clear texl of the verification data is also included in side file 527. Then, header 499 is copied to the front portion of encrypted file 523 to form modified encrypted files 525. A similar process is employed for executing files, as depicted in Figurc 28. The clear text copy orthe sortware procluct (represented as clear file 531) is encrypted in accordance wilh a conventional routille~ to rOrlll encrypted file 533. The front portion of encrypted file 533 is copie(l to side file 539 so that the overlaid data of encrypted file 533 is preserved. ~urthermore, side file 539 inclu(lex a copy of the clear text of the verification data. Then, the encrypted file 533 is mo(lifie(i hy overlaying an(l executable stub 537 and header 599 onto the first portion of encrypte(:l rile 553.

The purpose of executable stuh 537 of Figurc 2X will now be (lescribed. The DOS operating system for a personal computer will try lo execute an encrypted application. This can result in a system "hang" or unfavorable actiom The executable stub 357 of the executing file of Figure 2X is utilized to protect the user rrom attempting to execute applications that are encrypted: there would be considerable risk that a user would hang his system Or rormat a drive if he or she try _ 2145922 DA9-94-0 l 0 29 to run an encrypted file. The executable stub is attached to the front portion of the encrypted software produet so that this stub is executed whenever the application is run without the installed TSR or run from a drive the TSR is not watching . This stub will post a message to the user that explains why the application cannot run. In addition to providing a message this executable stub can be used to perform sol-histicated actions~ such as:
(l) it can duplicate the functionality of the TSR and install dynamic encryption before kicking off the application a seconcl time;
(2) it can turn on a temporary access key and kick of r the application a second time;

(3) it can communicate with the TSR and inform it to look at the drive the application is being run from.

The executable stub is saved or copied into the encrypted program as follows:
(I) the application is encrypted;
(2) a decryption block is created for this program;
(3) a pre-built executable stub is attached to the front end of the decryption block;

(4) the length of the combincd decryption header and executable stub is determined;

(5) the bytes at the front of Il1e executable filc equal to this length are then read into memory preferably into a pre(lefined side file location; and (6) the encryption header an(l executable slub are then written ovcr the leading bytes in the exeeutable code.

The TSR ean determine if an executablc ;s encrypte(l l~y searcl1irlg beyond the known size of the executable stub for the decryption block portion. When the TSR decrypts the executable stub it accesses the side file to read in the bytes th~t were displacecl by the stub and header block.
Figurcs 29a and 29b provide a flowchart representation of operation during a trial period interval which begins at software block 601. In accordance with software block 603 the file management program located in the operating systen1 of the user-controlled data processing system continually monitors for input/output calls to the memory media. Then in accordance 21~922 with softwa.re block 605, for each input/o~ltput call, the called file is intercepted, and in aeeordanee with software bloek 607 the operating sy.~tem is deniec] access to the called file, until the file management program can determine whether aecess should be allowed or not. A portion of the called file is read where the decryption block sll(!uld he located. This portion of the called file is then read, in accordance with software block 609, to clerive a key file address in accordance with software block 611. The aclclt-css which is c-]erivecl is utilized to fetch the key file, in accordance with software block 613. In accor(lance with dccision block 615, if the key file cannot be loeated, the process ends at software block 617; however, if it is determined in decision block 615 that the key file can be located, the key is clerived in accordance with software block 619. The derived key is then utilized to decrypt the validation segment which is located within the encryption header, in accordance with softwate block 621. In decision block 623, the dccryption validation segment is compared to the clear text for the decryption validation segment; if it is determined that the decryplecl segment cloes nOt match the known clear text segment, the process continues at software hlock 625 by ending; however, if it is determined in deeision block 623 that the clecrypte(l validation segment does match the known clear text validation segment, the process continues as sortwate block 627, wherein access to the called rlle is allowed. Then, the decryption type is read from the decryptioll header in accordance with software block 629, and the callccl file is dynamically decrypted in accordance with software block 631 a~ it is passed for ptocessillg by the operating system of the user-controlled data processing system, in accordatlce with software hlock ()33. The process tcrminates at software block 635.

Jf unauthorized execution of an encr~pte(l file is attemplec:l, the executable stub will at least temporarily deny access and po.st a me~age to tlle .~stem, l~ut may handle the problem in a number of sophisticated ways which were en~lmcratecl above.

In accordance with the prererrecl embodimelll Or the l-resent invelltion, during the trial interval, or at the conclusion of the trial intetval, the prospective purcllaser may contact the vendor to make arrangements for the purchase of a col-y of the on( or more software products on the eomputer-aceessible memory media. Preferably, CD ROMs or floppy disks have been utilizecl to ship the product to the potential user. Preferably, the coms uter-accessible memory media includes the two encrypted copies of eaeh of the pso(lucts whieh are offered for a trial interval of use. One enerypted eopy may be decrypled utilizing the file management program and the 5 temporary key whieh is communicated from lhe vendol lo the p~lsehaser. The other enerypted copy is not provided for use in the trial intervcll mode of operatiol1~ but instead is provided as the permanent copy whieh may be deerypted and utilized OllCe thc software produet has been purehased. In broad overview, Ihe user selee~s a soflware produet for a trial interval mode of operation, and obtains from the ven(lor tempolary aeeess keys, whieh allow the user aeeess to the produet (through the file mctnagemenl Islrogr~m) for a pre(lefined trial interval. Before or after the eonelusion of the trial intGrval, the user m ay ,s urehase a permanent eopy of the software product from the vendor by contacting the vendor hy facsimile, electronic mail, or telephone.
Onee payment is reeeived, the vendor con1mul1icates to the user a ,s~ersnanent aceess key whieh is utilized to decrypt the second enerypted eopy of lhe soflware psoduet. This enerypted product may be encrypted utilizing any conventional encryption rolltine, such as the DES algorithm. The permanent key allows the software product to be deerypted for unrestrieted use. Sinee multiple copies of the product may be pul-ehased in one transcletiol1, the present invention is equipped with a teehn;que for provid;ng movable aeeess keys, whiel1 will he discussed below in connection with Figures 30 through 35. In the r~refersed embodiment of the present invention, the encryption algorithm employed lo encryl-t and deery,s t the seeond eopy of the software product is similar to that employed itl the trial interval mode of operation.

The present invention incllldes an e~port/il11pol~~ nclion whicl1 allows for the distribution of permanent aecess keys, after the eonelusion of a Irial inter\~al periocl. Typieally, an office administrator or data proeessit1g system manages will putchctsc a seleeted number of "eopies" of the enerypted produet after termination of a trial inlesval ~er;od. Cerlain individuals within the organization will then be is~ued permanent keys whicl1 allow for the unrestricted and permanent aceess to the enerypted prod-let. In an ofr;cc ot work envis-ol1mel1t where tl1e eomputing deviees are not connected in a distributed data sl roce!isil1g network, the permanent aeeess keys must be -DA9-94-0 l O 32 communicated from the omce aclministrator or data processing manager to the selected individuals within an organization who are going to receive copies of the encrypted software product. The permanent keys allow ror permanent access to the pro~uct. Since not all employees within an organization may he issued copies of the particular encrypted product, the 5 vendor would like to have the distributiol1 occur in a manner which minimizes or prevents the distribution beyond the sales agreemel1t or license agreement. Since the products are encrypted, they may be liberally distributecl in their encryptecl form. It is the keys which allow unrestricted access to the product which arc lo be prolected in the current invention. To prevent the distribution of keys on electronic mail or printe<l communications, the present invention includes an export program which is resident in a source computer and an import program which is resident in a target computer which allow ror the clistl-ibution of the access keys via a removable memory media, such as a floppy <liskette. This ensures that the access l~eys are not subject to inadvertent or accidental distribulion Or <lisclosurc. Thete are two principal embodiments which accomplish this goal.
In the first embodiment, one or more encrypted file~s which are maintained in the source computer are first decrypted, and then encrypted utilizing an encryption algorithm and an encryption key which is unique to the ~ransportable memoly media (such as a <liskette serial number). The key file may lhen be physically carrie<l via the <liskelte to a target computer, 20 where it is decrypted utilizing a key which is <Ierive<l by the target computer from interaction with the transferable memory media. Immediately, the key file or files are then encrypted utilizing an encryption operation which is keyed with a key wllicll is derived from a unique system attribute of the target computel.

25 In the alternative embodiment, lhe transfe1rable memory media is loa<led onto the target computer to obtain from the targel comr~u~er import file a transfer key which is uniquely assoeiated with the target computer, an<l whicll may be derive~l from one or more unique system attributes of the target computer. The memory media is then transferred to the source computer, where the one or more key files are decryl-te(l, an(l then encrypled utilizing the transfer key. The memory media is then carried to the target computer where the transfer key is generated and ut;lized in a decryption operation lo decrypt the one or more key files. Preferably, immediately the key files are encrypted utilizing an encryption operation which is keyed with a key which is uniquely associated with the target computer, and which may be derived from one or more unique computer configuration attributes. The rirst embodiment is discussed herein in connection with Figures 30, 31, 32, and 33. The secon(l embodiment is discussed in connection with F;gures 34 and 35.

Figures 30 and 31 depict in block diagram form export and import operations which allow an authorized user to move his permanellt key to another d~lta processing system using an "export"
facility that produces a unique diskette image of the acccss key lhclt has been enabled for import into another system. In accordance with the present invention, the access keys which are delivered over the telephone by the softwal~e ven-lor to the customel- are Iess than 40 bytes in length. The key file that is produced is ovel- 2,()()() bytes in Icngth. An export facility is provided for copying the key file and the machine identification file to a diskette. Both files are then encrypted with a modified diskette serial number to inhibit these files from being copied to a public forum where anyone could use them. An import facility provided in another system decrypts the~e files and adds the product key and machine identification from the diskette to a list of import product keys and machine identifica~iol1s in thc import systems master file, and copies the key file to the import system harcl disk. The key rile is encrypted on the import system as is disclosed above.

Figure 30 is a block diagram depiction of an expor~ op7eratiol1 in accorc!ance with the preferred embodiment vf the present in~7elltiol1. As is showl1, soulce computet- 651 includes a key file 653 and a machine identification t'ile 655. Key file 653 includes the plo(luct key, the customer key, the clear text of the machine identifica~ion fot source computel 653, trial ;nterval data (such as a clock and/or counter which definc the trial interval period), and an export counter which performs the dual funct;ons of defining the maximum number of export operations allowed for the particular protected software products and keeping track of the total number of e~port operations which have been accomplished. The machine identification file includes the machine identification number and trial interval data (such as a clock and/or counter which defines the trial interval period). Both key rlle 653 and machine islentification file 655 are encrypted with any conventional encryption operation (such as the DES algorithm), which is keyed with a key which is derived from a unique system attrihute of s(lLIrce computer 651. At the commencement of an export operation, key file 653 an(l machine identiricatioll l'ile 655 are decrypted. Key file 653 is supplied as an input to decryption operation 657 which is keyed with key 659. Likewise, machine identification file 655 is supplied as an input to decryption operation 663 which is keyed with key 661. Decryption opcrations 657, 663 generate a clear text version of key file 653 and machine identification file 655. Once the clear text is obtaine(l, the export counter which is contained within key file 653 is mo(iified in accoldallce with block 661. For example, if this is the seventh permitted export ~I erati(lll out of tcn permissible operations, the counter might read "7:10". The clear text version of key file 653 is supplie(l as an input to encryption operation 669.
Encryption operation 669 may be any conventional encryptioll operation (such as the DES
algorithnn), which is keyed with a memory media attribute 665 which is unique to a memory media which is coupled to source computer 651, which has beell subjected to modification of modifier 667. For example, a unique diskette serial number may be supplied as the "memory media attribute" which is unique to memnry mcdia 677. The diskette serial number is modified in accordance with modifier 667 to altcr it slightly, and supply it as an input to encryption operations 669. The same operation is perrormed ror the clear text of machine identification file 655. A unique memory media attrib-lte 671 is modiried by mo(lirier 673 and utilized as a key for encryption operation 675, which may C(llllpl iSC any convellti(lnal encryption operation, such as the DES operation. F;inally, IllC oull-ul Of enctyl-tioll operalions 669 and 675 are supplied as inputs to copy operations 679, 6XI which copy ~hc encrypted key file fi53 and machine identification file 655 to memory media 677.

Figurc 31 is a hlock d;agram depiction Or an import operLItion. Memory media 677 (of Figure 30) is physically removed from source computer 651 (Or Figure 30) and physically carried over to computer 707 (of Figurc 31); alternatively, in a distribute(i data processing system, this transfer may occur without the physical removal of memory media 677. With reference now to Figure 31, in accordance with block 683, the machine identification of the target machine is copied to memory media 677 t:- maintain a record of which particular target computer received the key file and machine identificatioll file. Then, in accor(lance with block~ 685, 693 the encrypted key file 653 and machine identification file 655 are copied from the memory media to target computer 707. The encryptecl key file 653 is surJplied as an input to decryption operation 689 which is keyed with key 687. Decryption o} eration 6~9 reverses the encryption operation of block 669, and provides as an output a clear text ver.~ion of key file 653. Likewise, machine identification file 655 is supplied as an illpUI to decIyptioll operation 697, which is keyed with key 695. Decryption operation 697 rever~e.~i t:he encryplion Of encryption operation 675 and provides as an output the clear texl of machine identirication file 655. In accordance with block 691, the machine identification of the .~ource computer 651 is retrieve(l and recorded in memory in the clear text of key file 653. Next, the clear text of key file 653 is supplied as an input to encryption operation 699. Encryptioll operation 699 is a conventional encryption operation, such as the DES operation, which is keyed with a target computer unique attribute, such as the machine identification or modified machine identification for the target computer 707. The clear text of machine identification filc 655 is supplied as an input to encryption operation 703.
Encryption operation 703 is any conventional encl yplion ol-eration, such as the DES encryption operation, which is keyed with a unique target com~uter attribute 705, such as machine identification or modified machine identil'icalion ol' larget computer 707. Thc output of encryption operation 699 produces all encrypted key file 709 which includcs a product key (which is the same temporary l~roduc~ kcy of l~ey filc 653 Of ~ rce computer 651), a customer number (which is the same cu~tomer nulllbeI of l~ev filc 653 of s(l-lrcc computer 651), and clear machine identification (which ix thc macllinci(lclltificat:iollfortalgctcomputer707~ and not that of source computer 651), trial interval datcl (whicll i~ idelllical to the trail interval data of key file 653 of source 651), and an idelllificatiotl ofthe machine identil'ication of the source computer 651 The output of encryption opcra~ion 703 defines m~clline identification file 711, whieh includes the machine idenlification of the target computet 707 (and not that of the source computer 651), and the trial interval data (which is identical to that of machine identification file 655 of source computer 651).

Figures 32 and 33 provide alterna~ive views Or the import ancl expl)rt operations which are depicted in Figures 30 and 31, and emphasize several of the important features of the present invention. As is shown, source computer X01 includes machine iclentification file 803 which is encrypted with a system attribute key which is unique to the soulce computer XOI. The machine identification file includes machine identification file number as well as count of the number of exports allowed for each protected software product, ancl a Co~111t of the total number of exports which have been utilized. For examp]e, the firit expot t o~eration carries a count of l :10", which signifies that one export operation of ten permitted CXpOI t ol~erations has occurred. In the next export operation, the countel is incrementecl to 2:2()" whicl1 signifies that two of the total number of ten permitted expolt ol-era~ions has occurl~e(l. Each talget computer which receives the results of the export operation is tagged with this patticular counter value, to identify that it is the recipient of a particular eXpOlt operation. For example, OllC source computer system may carry a counter value of "1:10", WhiCIl signifie.s that it is the recipient of the first export operation of ten permitted export opetations. Yet anoth~r target computer may carry the counter value of "7:10", which signifies lhat this r~at licular target computer received the seventh export operation of a total Or ten r~ermitted exr~(?rt operations. In this fashion, the target computer maintains a count of a tolal number of used exr~ort opetations, while the source computers each carry a difrerel1t countet value whicl1 iclentifies it a the recipient of the machine identification file and key file from the source computer ftom r!articular ones of the plurality of permitted export operations.

Note that in source cornputer X01 macl1ine i<len~ific.ltion file X03 and key file 805 are encrypted with an encryption algoritllm which utilizes as a key a system attl-ibute whicl1 is unique to source computer 801; however, once machine iclenlification file X03 and key file 805 are transferred to a memory media, such as ex~ort key diskette X07, machil1e idel1tilication file 809 and key file Xl I
are encrypted in any conventional encryptiol1 or~etation which utilizes as an encryption key a unique diskette attribute, such as the disket~e's serial number. This minimizes the possibility that 21~5922 D~9-94-0 10 37 the content of the machine ID filc 809 and/ot key file 811 can be copied to another diskette or other memory media and then utilizcd to obtain unauthorized access to the software products.
This is so because for an efrective transrer nr the content of rnachine ID file 809 and key file 811 to a target computer to occur, the target computet must be ahle to read and utilize the unique diskette attribute from the export key diskette 807. Only when the machine ID file 809 and key file 811 are presented to a target computer on thc diskette onto wh;ch these items were copied can an effective transfer occur. The prescnlalion of the rnachine ID rile 809 and key file Xl 1 on a diskette other than export key ~liskelte X07 to a potential target computer will result in the transfer of meaningless information~ since the unique attribute of export key diskette 807 (such as the diskette serial numbel) is required by the targct computer in order to successfully accomplish the decryption operation.

As is shown in l~igurc 33, expott key (liskette X07 is presented to targct computer Y~13. Of course, the machine identification file 809 and key file 811 are in encrypte~ form. In the transfer from export key diskette 807 to target computer X13, the contcnt of machine ID file 809 is updated with the machine identification of the target computer X13, and the count of imports utilized. In accomplishing the lrallsfer to target computer 813? a machine identification file X15 is constructed which includes a number of items sucll as machillc identification for the target computer X13, customer informalion, as well as a list of the machine identification number of the source computer 801. Both machine identificalioll file X15 and the key file X17 are encrypted utilizing a conventional encryption operatioll which uses as a key a unique attribute of target computer X13. This ties machille i(lentirication file X15 an(l key file X17 to the particular target computer 813.

By using an export/import counter lo keep track of the total number of authorized export/import operations, and the total number Of usecl exporl/import operalions, the present invention creates an audit trail which can be utilized to keep track of the (listribution of software products during the trial interval. Each source compuler will carry a recot(l of the total number of export operations which have been p erforme(l. Each SOUtCC computet will carry a record of which ,, particular exportlimport operation was utilized to transfer OllC or more protected software products to the target computer. The memory media utilized to accomplish the transfer (such as a diskette, or group of diskettes~ will carry a permanent record of the machine identificatiorl numbers of both the source computer and the target computel-'s utilized in all export/import operations.

The procedure for implementillg export and import opelations cnsure.s that the protected software products are never exposed to unnece~sary ri~ks. When the machine identification file and key file are passed from the source compulcr to the CXpOI t diskette, they arc encrypted with the unique attribute of the export diskette which ptCVCMtS Ot inhibits copying of the export diskette or posting of its contents to a bulletin board as a means for illegally distributing the keys. During the import operations, the machine identiricatioll and key filcs are encrypted with systern attributes which are unique to the target coml~uter to ensulc that the software products are maintained in a manner which is con.~istent with lhe secul-ity of lhe source computer, except that those software products are encrypted with attribute~ which are unique to the target computer, thus preventing illegal copying and posting of the keys.

The second embodiment of the export/imr)(!l-t runction i~ depicled in block diagram form in Figurcs 34 and 35. ln broad OVClViCW, mcmoJ y media 1677 is first ut;lized to interact with target computer 1707 to obtain from target comr~utel 1707 a transfer key which is unique to target computer 1707, and which is preferably delive(l from one ot more unique system attributes of target computer 1707. The tran~rer key may be a n~O(liricatiOn Or the machine identification for target computer 1707. Nexl, the memol y media I 677 i~ ulilize(l lo interact with source computer 1651 in an export mode of operalion, \~heleil1 key file 1653 and macl1ine identification file 1655 are f1rst decrypted, and then ellclypted utilizing ~he ~ransrel key.

Figurc 34 is a bloek diagram depiction Or an CXp(lt I OpCI atiOIl in aeeorclanee with the preferred embodiment of the present invention. A~ is shown, ~ource computer 1651 includes a key file 16S3 and a machine identific~tion file 1655. Key rile 1653 inclucle~ the product key, the '_ customer key, the clear text of the machine identification for .'iOl]lCC computer 1653, trial interval data (such as a clock and/or counter which define thc trial intel-val period), and an export counter which performs the dual functions of defining the maximum number of export operations allowed for the particular protecte(l software proclucts and keeping track of the total number of export operations which have been accomplishe(l. The machine identification file includes the machine identificat;on number and trial interval data (such as a clock and/or counter which defines the trial interval period). Both key file 1653 and machine identification file 1655 are encrypted with any conventional encryption operation (such a~ the DES algorithm), which is keyed with a key which is clerivcd from a uniq~le system attribute Or source computer 1651. At the commencement of an export operation, key file 1653 and machine identification file 1655 are decrypted. Key file t653 is supplied a~ an input to decryption operation 1657 which is keyed with key 1659. Likewise, machhle identification file 1655 is supplied as an input to decrypt;on operation 1663whichiskeyedwilllkey 1661. Decryl~ noperations 1657,1663generateaclear text version of key file 1653 and machine identification file 1655. Once the clear text is obtained, the export counter which is contained within key file 1653 is mo(lified in accordance with block 1661. For example, if this is the scventh ,nermitted export operation out of ten permissible operations, the counter might read "7:1()'. The cleal lext versioll of key file 1653 is supplied as an input to encryption operation 1669. Encryption operatioll 1669 may be any eonventional encryption operation (such as the DES algorill~ hicll is keyed with the transfer key 1665 which was previously obtained. The same operatioll i perfolllled ror the clear text of machine identification file 1655. Transfel- key 1671 i~ utilize(l as a key roI cncryption operation 1675, which may comprise any conven tiona l encl yptioll oper a l iOn, sucll as the DES operation. Finally, the output of encryption operations 1669 an(l 1675 are suppliecl as illpUtS to COpy operations 1679, 1681 which copy the ellcrypted key rile 1653 an(l macllille identification file 1655 to memory media 1677.

Figure 35 is a block diagram depiction or an import operatioll. Memory media 1677 (of Figure 34) is physically removed from SOUtCC computel 1651 (Of Figure 34) and physically carried over to computer 1707 (of Figurc 35); alternatively, in a distribute(i data processing system, this 21~592~
'_ transfer may occur without the physical rcmoval of memory media 1677. With reference now to Figure 35, in accordance with block 16X3, thc mach;ne identification of the target machine is copied to memory media 1677 lo maintain a record of which l-articular target computer received the key file and machine idcntification file. Then, in accordance with blocks 16X5, 1693 the encrypted key file 1653 and machine identirication file 1655 are copied frorn the memory media to target computer 1707. The encrypted key file lfiS3 is supplied as an input to decryption operation 1689 which i.~ keyed with key 16X7. Decryption operation 1689 reverses the encryption operation of block 1669, and provide!-, a~, an outpul a clear text version of key f;le 1653. Likewise, machine identification file 1655 i~ .~upplied as an input to clecryption operation 1697, which is keyed with key IG95. Decl-yptivn operation 1697 reverses the encryption of encryption operation 1675 and pro~ide~, a~, an output the clear text of machine identification file 1655. In accordance with block 1691, the machinc idellliricatiol1 of the source computer 1651 is retrieved and recorded in mcmoty in the clear text of key file 1653. Next, the clear text of key file 1653 is supplied as an input to encryption ol-eration 1699. Encryption operation 1699 is a conventional encryption operation, swch as the DES operation, which is keyed with a target computer unique attribute, such a~, the machinc identificatioll Or modified machine identification for the target computer 1707. The clear text of machine identirication file 1655 is supplied as an input to cncryption operation 1703. I~nclyptioll operation 1703 is any conventional encryption operation, such as the DES encryption OpCI atior], which is keyecl with a unique target computer attribute 1705, such a~, machine identiriccltion or modified machine identification of target computer 1707. The out~ut of encryption opelation 1699 I-roduces an encrypted key file 1709 which includes a producl key (whicll i~, the .~ame tempolal-y procluct key of key file 1653 of source computcr 1651), a cu.stomet numl~er ~i llich i~ the ~,ame cu~,tomer number of key file 1653 of source computer l651), an(l cleal- machine i~lentirication (which i~ the machine identification for target computer 1707, and not that of ~OUICC computer 1651), trial interval data (which is identical to the trail interval dala of key filc 1653 Of soulce 1651), and an identification of the machine identification of thc SOUICC computer 1~51. The oulput of encryption operation 1703 defines machine identification file 1711, whicll includes the machine identification of the targel computer 1707 (and not that of the .'70-llCC computer 1651), and the trial interval data 21~5922 -(which is identical to that of machine identirication file 1655 of source computer 1651).

While the invention has been ,t~articularly showll and dGscribed with reference to a preferred embodiment, it will be understood by tl1ose skilled in the art that various changes in form and 5 detail may be made therein without departing f'rom the spirit and sc(!pe of the invention.

Claims (16)

1. A method in a data processing system of securing access to particular files which are stored in a computer-accessible memory media, comprising the method steps of:
providing a file management program as an operating system component of said data processing system;
storing a plurality of files including at least one encrypted file and at least one unencrypted file in said computer-accessible memory media;
for each of said at least one encrypted file:
(a) recording in said computer-accessible memory media a preselected portion of said at least one encrypted file;
(b) generating a decryption block which includes information which can be utilized to decrypt said at least one encrypted file;
(c) inserting said decryption block in said at least one encrypted file in the place of said preselected portion;
utilizing said file management program to (a) monitor data processing system calls for a called file stored in said computer-accessible memory media, and (b) determine whether said called file has an inserted decryption block, and (c) process said called file in one manner if said called file has an inserted decryption block, and process said called file in a different manner if said called file does not have an inserted decryption block.

2. A method according to claim 1:
wherein each of said at least one encrypted file has a particular file size;
wherein insertion of said decryption block does not change said particular file size for each of said at least one encrypted file.

3. A method according to claim 1, further comprising:
inserting said preselected portion in said at least one encrypted file in the place of said decryption block following expiration of a specific interval, wherein said interval defines a customer trial period; and decrypting said at least one encrypted file.

4. A method according to claim 1, wherein said step of generating a decryption block comprises:
combining (a) a unique identifier for each of said at least one encrypted file, with at least (b) an address to said preselected portion for each of said at least one encrypted file.

5. A method according to claim 1, wherein said step of generating a decryption block comprises:
combining (a) a unique identifier for each of said at least one encrypted file, with at least (b) a name for a key file which contains decryption keys for each of said at least one encrypted file.

6. A method according to claim 1, wherein said step of generating a decryption block comprises:
combining (a) a unique identifier for each of said at least one encrypted file, with at least (b) a validation segment comprising an encrypted segment of each of said at least one encrypted file.

7. A method according to claim 1, wherein said step of generating a decryption block comprises:
combining (a) a unique identifier for each of said at least one encrypted file, with at least (b) an identifier of which particular one of a plurality of available encryption operations has been utilized to encrypt said at least one encrypted file.

8. A method according to claim 1, wherein said step of utilizing said file management program to process said called file comprises intercepting said called file and at least one of:
(a) utilizing said decryption block to retrieve a name for a key file and reading a key for said called file;
(b) decrypting a validation segment of said decryption block, and comparing said decrypted validation segment to a selected segment of said called file, and continuing operations only if said decrypted validation segment matches said selected segment; and (c) decrypting said called file at the same time as it is passed for further processing.

9. At least one computer accessible memory medium in a data processing system for allowing a user to secure access to a particular file, comprising:
a plurality of files which are accessible to the data processing system, the particular file being one of the plurality of files;
at least one encrypted file, which is one of the plurality of files, having a preselected portion recorded in memory in a side file;
monitoring means for monitoring for a user request for access to the particular file;
receiving means for receiving the user request for access to the particular file;
transforming means for transforming the user request into a data processing system call for access to the particular file;
determining means for determining whether the called file has an inserted decryption block;
processing means for processing the called file in one manner if the called file has the inserted decryption block, and for processing the called file in a different manner if the called file does not have the inserted decryption block, wherein the monitoring means, the receiving means, the transforming means, the determining means, and the processing means are part of a file management program which is adapted to be functionally integrated with an operating system of the data processing system, and wherein the inserted decryption block includes information which is utilized to decrypt the file which is inserted in the at least one encrypted file in lieu of the preselected portion.

10. An apparatus according to claim 9:
wherein each of the at least one encrypted file has a particular file size; and wherein insertion of the decryption block does not change the particular file size for each of the at least one encrypted file.

11. An apparatus according to claim 9, further comprising:
means for maintaining the at least one encrypted file in an encrypted condition for an interval which defines a customer trial period; and means for replacing the preselected portion in the at least one encrypted file in lieu of the decryption block; and means for decrypting the at least one encrypted file.

12. An apparatus according to claim 9, wherein the decryption block includes:
a unique identifier for each of the at least one encrypted file, and an address to the preselected portion for each of the at least one encrypted file.

13. An apparatus according to claim 9, wherein the decryption block includes:
a unique identifier for each of the at least one encrypted file, and an address for a key file which contains decryption keys for each of the at least one encrypted file.

14. An apparatus according to claim 9, wherein the decryption block includes:
a unique identifier for each of the at least one encrypted file, and a validation segment composed of an encrypted segment of each of the at least one encrypted file.

15. An apparatus according to claim 9, wherein the decryption block includes:
a unique identifier for each of the at least one encrypted file, and an identifier of which particular one of a plurality of available encryption operations has been utilized to encrypt the at least one encrypted file.

16. An apparatus according to claim 9, wherein the file management program is utilized to process the called file by performing at least one of:
(a) intercepting the called file;
(b) utilizing the decryption block to retrieve an address for a key file and reading a key for the called file;
(c) decrypting a validation segment of the decryption block, and comparing it to a selected segment of the called file, and continuing operations only if the decrypted validation segment matches the selected segment; and (d) decrypting the called file at the same time as it is passed for further processing.