US006134593A
`6,134,593
`(11) Patent Number:
`(5
`United States Patent
`Alexanderetal.
`[45] Date of Patent:
`Oct. 17, 2000
`
`
`[54] AUTOMATED METHOD FOR ELECTRONIC
`SOFTWAREDISTRIBUTION
`
`[75]
`
`Inventors: Marc A. Alexander, Clackamas;
`Gerald B. Feldkamp; Bernard R
`Strathern, both of Beaverton,all of
`Oreg.
`
`[73] Assignee: CCComplete, Inc., Portland, Oreg.
`
`[21] Appl. No.: 08/941,643
`[22]
`Filed:
`Sep. 30, 1997
`[51] Unt. C17 cicccecccesseeesseen GO6F 15/16; GO6E 15/173
`[52] US. CI
`709/229: 709/225: 709/219:
`—— “709/300:705 [54; 705, Ad: 705 26; 705/39:
`. 7171: 713200: 743201: 1302
`
`>
`~?
`.
`-
`:
`[58] Field of Sieroadsoe35.35, Joeooer:
`
`705/54 55. 18. 26- 7137159 165. 200.
`awe 340/825 3I: 380 3
`“ve
`NY
`References Cited
`U.S. PATENT DOCUMENTS
`
`[56]
`
`4,658,093
`5,319,705
`5,337,357
`5,375,206
`
`4/1987 Hellman occ eceesseecreteteeees 705/52
`6/1994 Halter et al.
`..
`.
`
`8/1994 Chou et al.
`...
`12/1994 Hunter et ab. oe eeceeeeeees 395/200
`
`5,490,216
`5,652,793
`5,809,144
`5,835,911
`5,898,777
`
`2/1996 Richardson, IIT 0... eee 705/59
`eseseceeeceeees 380/4
`7/1997 Priem et al.
`occ
`
`........
`wa 705/52
`9/1998 Sirbu etal.
`
`11/1998 Nakagawaet al.
`.
`» 707/203
`4/1999 Tycksen et al... eee 380/4
`.
`.
`.
`Primary Examiner—Mark H. Rinehart
`Assistant Examiner—Beatriz Prieto
`Attorney, Agent, or Firm—Blakely Sokoloff Taylor &
`Zafman, LLP
`ABSTRACT
`[57]
`A methodfor a user to automatically order, unlock and pay
`for a vendor software application via an automated tele-
`phony and/orInternet system. The user requests access to a
`vendor software application. If access is not allowed, the
`user transmits a computing deviceidentifier identifying the
`computing device on which the vendor software application
`is executing,
`a vendor software product distribution
`identifier, and a vendoridentifier to a aserver. Pricing data is
`provided to the user, and payment for the vendor software
`application is processed before access is granted thereto.
`After payment processing, the server then transmits a pass-
`word to the client based on the identifiers. Thercafter, the
`user enters the password to gain access to and execute the
`vendor software application to which access was previously
`denied.
`
`17 Claims, 4 Drawing Sheets
`
`420
`
`430
`
`
`
`
`
`INSTALLATION IDENTIFIER
`
`450
`
`
`
`é
`
`s.
`
`s“
`
`
`
`410
`
`PRODID
`
`
`
`
` 400
`
`EXP DATE ——>
`
`PASSWORD
`
`Google Exhibit 1070
`Google v. VirtaMove
`
`Google Exhibit 1070
`Google v. VirtaMove
`
`

`

`U.S. Patent
`
`Sheet 1 of 4
`
`6,134,593
`
`100
`
`Oct. 17, 2000
`
`FIG.1
`
`

`

`U.S. Patent
`
`Oct. 17, 2000
`
`Sheet 2 of 4
`
`6,134,593
`
`002
`
`6Dl
`
`0&2
`
`qOle
`
`BOLNOILVOIMIdd¥M/SHOONSA
`
`NOILVOMdd¥M/SHOONSA
`
`Oecd
`
`‘NOILONNS
`
`SWIL
`
`YO
`
`4035Y9s30
`
`ALIVNOLLONNA
`
`

`

`U.S. Patent
`
`Oct. 17, 2000
`
`Sheet 3 of 4
`
`6,134,593
`
`START
`
`INSTALL VENDOR SW|__395
`APPLICATION
`RETRIEVE AND DISPLAY
`INSTALLATION ID
`
`CREATE INSTALL ID
`AND CLIENT ID
`
`310
`
`LAUNCH VENDOR S/W
`APPLICATION
`
`315
`
`TRANSMIT INSTALLID
`AND DISTRIBUTE ID
`
`TO SERVER
`
`340
`
`PROCESS PAYMENT
`
`345
`
`EXECUTE MODULE
`210a
`
`
`
`EXECUTE
`MODULE 210b
`?
`
`YES
`
`330
`210b LOCKED
`2
`
`
`
`NO
`
`YES
`
`TRANSMIT PASSWORD
`TO CLIENT DEVICE
`
`350
`
`ENTER PASSWORD
`
`355
`
`EXECUTE MODULE
`210b
`
`FIG. 3
`
`

`

`U.S. Patent
`
`Oct. 17, 2000
`
`Sheet 4 of 4
`
`6,134,593
`
`430
`
`440
`
`VENDORID
`
`CLIENT DEVICE ID
`
`i
`ty
`ty
`tr
`li
`“
`
`! i
`
`)
`
`I!tI
`
`I
`I
`i
`f
`i
`
`t'
`
`
`
`450
`
`420
`
`PRODDISTID
`
`
`
`“
`
`~“~ XN.~~
`
`
`
`
`
`410
`
`
`
`
`
`PROD ID
`
`INSTALLATION IDENTIFIER
`
`EXP DATE ——>
`
`PASSWORD
`
`
`400
`
`FIG. 4
`
`

`

`6,134,593
`
`1
`AUTOMATED METHOD FOR ELECTRONIC
`SOFTWAREDISTRIBUTION
`
`CROSS REFERENCE TO RELATED
`APPLICATIONS
`
`Not applicable.
`
`STATEMENT REGARDING FEDERALLY
`SPONSORED RESEARCH OR DEVELOPMENT
`
`Not Applicable.
`
`COPYRIGHT NOTICE
`
`Contained herein is material that is subject to copyright
`protection. ‘The copyright owner has no objection to the
`facsimile reproduction of the patent disclosure by any per-
`son as it appears in the Patent and Trademark Office patent
`files or records, but otherwise reserves all rights to the
`copyright whatsoever.
`
`BACKGROUND OF THE INVENTION
`
`1. Field of the Invention
`
`The present invention is related to the field of electronic
`software distribution. In particular, the present invention is
`related to an automated method for software unlocking and
`paymentprocessing to allow execution of the software by a
`user on a client computing system in a client-server com-
`puting environment.
`2. Description of the Related Art
`Sales of products and services traditionally have been
`transacted by sales people or agents. More recently, sales of
`products and services,
`in particular high technology
`products, including software products, have been transacted
`by a combination of sales people and electronic delivery
`and/or payment systems. Consumers today increasingly
`expect
`immediate access to products, services and
`information, via telecommunications-,
`intranet-, Internet-,
`cable-, and satellite-based commerce systems or combina-
`tions thereof.
`
`Telecommunications technology including predictive
`dialers, automated call management systems and database
`management
`technology has enabled “teleservice” to
`become a more cost-effective way of reaching consumers.
`Inbound tclescrvice activity, often in a customer service
`application, is growing rapidly, placing demands on corpo-
`rate staffing requirements to handle increased call loads
`while providing faster delivery of products, services, and
`information to the consumer.
`
`Moreover, communications between customers and ven-
`dors are labor intensive with telephone service representa-
`tives providing the primary link between a vendor andits
`customers. The representatives are responsible for a cus-
`tomer’s impressions. Although labor often represents a high
`percentage of vendor’s costs, most vendors under-invest in
`their employees and have both high turnover and a high
`percentage of part-time employees.
`To increase cost-effectiveness, what is needed is an auto-
`mated inbound, non-operator intervention call-handling
`system, capable of operating 24 hours a day, scven days a
`week, via which consumers can order products and services
`or obtain information without interaction with telephone
`service representatives. Automation provides the vendor
`with the opportunity to segment customers into those who
`can purchase products or services, or have their issues
`resolved automatically, and those who need personal attcn-
`
`2
`tion that can be provided by fewer, better skilled, and
`higherpaid telephone service representatives. In particular,
`whatis needed is an automated system via which consumers
`can order software products without interaction with tele-
`phone service representatives.
`BRIEF SUMMARY OF THE INVENTION
`
`A method is disclosed for a user to automatically order,
`unlock and pay for a software application from a vendorvia
`a computer-automated telephony and/or Internet ordering
`system in a client-server computing environment. The user,
`proximate to the client device, requests access to at least a
`portion of a vendor software application generally via the
`applicationitself. If access is not allowed, the user transmits
`product distribution and installation identifiers to a server.
`The server processesthe identifiers and transmits a password
`to the user based thereon, wherein the user enters the
`password at the client to gain access to and execute that
`portion of the vendor software application to which access
`waspreviously denied. The method also provides for pro-
`cessing payment for the vendor software application before
`access is granted thereto.
`BRIEF DESCRIPTION OF THE SEVERAL
`VIEWS OF THE DRAWINGS
`
`The present invention is illustrated by way of example
`and not limitation in the following figures. Like references
`indicate similar elements, in which:
`FIG. 1 is a block diagram of client-server computing
`environment in which an cmbodiment of the present inven-
`tion may beutilized.
`FIG. 2 is a block diagram illustrating a functional or
`temporal allocation of modules comprising a vendor soft-
`ware application as may be utilized in an embodimentof the
`present invention.
`FIG. 3 is a flow diagram of an embodimentof the present
`invention.
`
`FIG. 4 is a diagram of the elements comprising the
`password generated according to an embodiment of the
`present invention.
`DETAILED DESCRIPTION OF THE
`INVENTION
`
`The present invention is related to an automated method
`for software unlocking and payment processing to allow
`execution of the software by a user on a client computing
`system in a client-server computing environment. In the
`following description, numerous specific details are set forth
`in order to provide a thorough understanding of the present
`invention. It will be apparent, however, to one of ordinary
`skill in the art that the present invention may be practiced
`without these specific details. In other instances, well-known
`systems, architectures, and techniques have not been shown
`to avoid unnecessarily obscuring the present invention.
`With reference to FIG.1, a client-server computing envi-
`ronment 100 as may be utilized by an embodiment of the
`present invention is illustrated. A client computing device
`110, or simply, client 110, e.g., a Personal Computer (PC),
`is capable of communicating with a server 150, either by
`way of the Public Switched Telephone Network (PSTN) 130
`or Internet 125. Additionally, a user of the client may
`communicate with server 150 via telephone 105,
`for
`example, to configure clicnt 110 by sclecting options via
`keypad entry on the telephone which cause server 150 to
`communicate parameters to client 110 necessary for desired
`configuration and operation of clicnt 110.
`
`10
`
`20
`
`25
`
`30
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`

`

`6,134,593
`
`3
`In alternative embodiments, client 110 may be a host,
`workstation, network device, personal digital assistant,
`mobile computer, or other general or special purpose com-
`puting device executing a general or special purpose oper-
`aling system and one or more software applications. In the
`illustration, client 110 accesses PSTN 130 via a local loop
`111 to Central Office (CO) 120. Client 110 may include an
`internal modem or be associated with an external modem
`necessary for communication over local loop 111, which
`may transmit voice and/or data in analog or digital format.
`An internal or external microphone 109 is connected to
`client 110 to provide a means for voice input to client 110,
`whichin turn, processes the voice input and communicates,
`as appropriate, with the server based onthe input. Client 110
`also accesses the Internet 125 via Internet Service Provider
`115. Other systems for communicating between client and
`server not shown include wireless communications, ¢.g.,
`radio, cellular radio or satellite communications. Server 150
`may also be a host, workstation or network device, or other
`gencral or special purpose computing device executing a
`general or special purpose operating system and one or more
`software applications. Server 150 can communicate with
`clients, e.g., client 110 via the same or similar communica-
`tion channels described above with respect to client 110.
`With reference to FIG. 2, client 110 executes at least one
`vendor software application 200. According to the preferred
`embodiment, vendor application 200 is executed locally by
`a processor within client 110. However, it is understood by
`those of ordinary skill in the art that vendor application 200
`may be accessed and/or executed remotely on server 150, or
`another server (not shown), according to well known pro-
`cedures for such execution in the client-server computing
`environment 100. Additionally, the vendor application, or
`portions or modules thereof, may be executed in a distrib-
`uted or other well known computing environment.
`Vendor software application 200 may comprise multiple
`modules or routines, for example module 210a and 2105,
`where module 210a is accessible and may be executed upon
`installation of the application 200 and module 2105 is
`locked and inaccessible uponinstallation. However, module
`210b may later be unlocked and executable after payment or
`some other vendor requirementis provided bythe userto the
`vendor according to the automated procedure embodied by
`the present invention. The modules maybe delineated by, for
`example,
`time, function, or degree of functionality. For
`instance, a user may be allowedto freely access and execute
`module 210a for a periad of time, say 30 days, after which
`time payment must be rendered for access to continuc, as
`represented by module 2105, as is common with shareware
`applications. Alternatively, a user may opt to purchase a
`portion of a vendor software application or one module in a
`suite of vendor software applications, say an accounts pay-
`able module, at one point in time, and then later purchase
`another module, say an accounts receivable module. As yet
`another example, module 210a may be a demonstration
`module providing limited functionality, whereas module
`210b maybe a commercial module providing full function-
`ality. While both modules may be installed together or
`separately on the client or a computing device accessible by
`the client, the user can only freely access and execute the
`demonstration module. The commercial module is acces-
`
`sible only after paymentis received by the vendor according
`to the steps discussed below. Of course, although not shown
`in FIG. 2, it is understood that multiple modules 210b may
`beinstalled andinitially inaccessible by theuser, 1.e., locked,
`until such time as the vendor’s requirements for access,1.e.,
`unlocking, are met.
`
`10
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`Unlocking software routine 220 is shown embedded
`between or linking modules 210@ and 2105 of vendor
`software application 200. In the preferred embodiment, the
`unlocking routine 220 provides a set of Application Pro-
`gramming Interfaces (APIs) via which the vendor can pro-
`cess the locking and unlocking of module 2105. By provid-
`ing a set of APIs that the vendor software application can
`call, the unlocking routine may be reused by the same or
`other vendors. While FIG. 2 illustrates the unlocking soft-
`ware routine as embeddedin the vendor software application
`200, it is understood that the routine may be separate from
`and externally linked to or called from the vendor software
`application 200.
`Payment software routine 230 is also shown embedded
`between or linking modules 210a and 2105 of vendor
`software application 200. As with the unlocking routine 220,
`the payment routine provides a set of APIs. The vendor can
`call the APIs to process payment for the module 210d, as
`will be discussed more fully below.
`In the preferred
`embodiment, payment routine 230 is separate from but
`utilized in conjunction with unlocking routine 220 to pro-
`vide the user with an automated method for unlocking and
`paying for module 210b of the vendor software application.
`With reference now to FIG. 3, the method for automati-
`cally unlocking and paying for at
`least a portion, e.g.,
`module 2105, of the vendor software application 200 is
`described. A user begins at step 305 by first installing the
`vendor software application 200, including modules 210a
`and 2106. According to one embodiment, at the time the
`vendor software applicationis installed, an installation iden-
`tifier based on the vendor andthe client computing device is
`created and stored at step 310 for later access by the client
`computing device. The installation identifier may be stored
`in the client computing device, a peripheral device or
`computing device accessible bythe client computing device,
`€.g.,
`in permanent nonvolatile memory, on magnetic or
`optical media, or other forms of permanent storage media.
`The installation identifier is once defined but may be used
`many times for separate products from a given vendor.
`Additionally, as will be described in more detail below, a
`client device identifier, which is related to the installation
`identifier, and based on the client computing device,
`is
`created and stored in the same mamner as the installation
`identifier. According to a second embodiment, the installa-
`tion and client identifiers are created and stored at or after
`
`the time the user attempts to execute a locked module.
`According to yet another embodiment,the identifiers may be
`created and stored after the module has been unlocked and
`
`payment received therefor.
`Application 200 is then launched at step 315. For
`example, given a PC operating under the Microsoft Win-
`dows™ operating system, a user might select application
`200 for execution by double clicking with an input device
`such as a mouse on an icon in a window, wherein the icon
`represents an executable file for the vendor software appli-
`cation. In one embodiment, module 210a begins executing
`at step 320, and as a next step at 325, module 210a
`determines whether module 210b is to be executed, accord-
`ing to further user input. For example, if a user selects an
`icon representing module 2105, then module 210a deter-
`mines module 210b is to be executed. At step 330, module
`210a determines whether module 210b can be executed,i.e.,
`whether module 210b is locked. If the module is unlocked,
`it can be immediately executed at step 360.
`it cannot be
`If, however, the module 2105 is locked,
`executed without first processing payment for the module
`and providing a password for the module. In particular,
`
`

`

`6,134,593
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`5
`module 210a calls the unlocking software routine 220 to
`determine whether the user previously purchased module
`2105. The unlocking software routine 220 determines
`whether the user previously purchased module 210b by
`searching for a password for module 2105. The password is
`either stored in or accessible by client computing device 110,
`the presence of which indicates payment has already been
`received for module 210b, as will be apparent from the
`discussion below. If module 2106 is not locked, ie., if a
`password is detected for module 2105, then module 210a
`automatically starts executing module 210d at step 360, and
`no further interaction with the unlocking routine 220 is
`required.
`It will be understood bythose of ordinary skill in the art
`that
`the module 2105 may be packaged in a separate
`executable file or integrated with module 210a, with access
`to restricted portions of the vendor software application 200
`controlled in either case by whether module 2105 was
`purchased as determined by the presence of a password for
`module 210b. Additionally, while the embodiment described
`above executes module 210a, which in turn, determines
`whether to execute module 2105 with the help of unlocking
`module 220, it is understood that either module 210¢ or
`2105 may be executed, but not necessarily both, as in the
`case where 210a represents a demonstration module and
`module 2105 represents a fully functioning module.
`Furthermore, in an alternative embodiment, the executing
`module 210a may first determine whether module 2105 is
`locked, and if not, then determine whether to execute the
`module.
`
`6
`operation performed by demo_mod.exeis to call the API for
`the unlocking routine 220 to determine whether the user
`previously purchased the fully functioning version (i.e.,
`commercial software module) of the vendor software appli-
`cation. If so, then demo__mod.exe automatically starts full__
`mod.exe, which is the commercial software module of the
`vendor software application, and no further interaction with
`the unlocking routine API is thereafter required.
`If demo_mod.exe determines that an appropriate pass-
`word is not stored in or accessible by the client computing
`device, demo_mod.exe displays buttons labeled Preview
`and Purchase. If the user clicks on Preview, then demo__
`mod.exe continues executing. If, however, the user clicks on
`Purchase, then demo__mod.exestarts the payment routine
`230. When the user purchases the fully functioning com-
`mercial software module full_mod.exe, a password for
`full_mod.exe is stored in the client computing device or a
`permanent nonvolatile storage location accessible by the
`client computing device, so that subsequent invocations of
`the vendor software application cause the full_mod.exe
`software module to be executed, via demo_mod.exe.
`At step 335, the payment routine displays on a display
`device associated with the client computing device a tele-
`phone number, generally a toll-free 800 or 888 telephone
`number, for the user to call to access the server 150. In
`addition, the payment routine conveys the purchase price of
`module 2105, payment options and instructions, and
`prompts the user to enter the installation identifier, and the
`vendor software product distribution identifier. (Recall the
`installation identificr, based on the clicnt computing device
`If module 210¢@ begins executing at step 320, receives
`and vendor, wasstored in the client computing device or the
`input at step 325 to execute module 2105, and determines,
`like at
`the time the vendor software application was
`in conjunction with unlocking routine 220 at step 330 that
`installed. The installation identifier is retrieved at step 335
`module 210is locked, then payment routine 230 is called
`and displayed on the display device when the payment
`so that the user can purchase the software, receive a pass-
`routine is invoked and the user is provided with instructions
`word for executing the module 2105 and then begin execut-
`for processing payment for module 2105).
`ing the module. Alternatively, according to another
`In response to the prompts displayed on the display device
`embodiment, steps 325 and 330 may be reversed. For
`associated with the client computing device, the user inputs
`example, if module 210a begins executing at step 320 and
`the installation identifier displayed on the display device, as
`determines at step 325 that module 210d is locked, then
`well as the vendor software product distribution identifier, or
`module 210a provides the user with the choice of whether to
`simply, product distribution identifier. The product distribu-
`execute module 2105 at step 330. In either embodiment,
`tion identifier may be, for example, printed onalabelaffixed
`module 210a determines whether module 2105 is locked by
`to a Compact Disc (CD) case in which a compact disc media
`calling the unlocking software routine 220. Module 2105 is
`storing the vendor software application is shipped. In one
`locked if payment has not been received for the module.
`embodiment, at step 340,
`the installation identifier and
`Unlocking routine 220 determines that module 2105 is
`product distribution identifier are transmitted to the server
`locked and that payment for
`the module has not been
`via a telephone transmission initiated by the user via touch
`received if there is no password stored in or otherwise
`tone input at telephone 105. In an alternative embodiment,
`accessible by the client computing device. If the module
`installation identifier and product distribution identifier are
`2105 is locked, the unlocking routine indicates such to the
`supplied by the user via an input device, such as microphone
`module 210a. Auserinterface screen is displayed by module
`109 or a keyboard associated with the client computing
`210a on a display device associated with the client comput-
`device and transmitted to the server over the Internet 125 or
`ing device providing instructions to the user for activating,
`World Wide Web.
`Le., unlocking, the module 210.
`An example of the steps described thus far is now
`provided for a vendor software application having both a
`demonstration software module and a fully functioning
`commercial software module. The example assumes the
`vendor software application has already been installed on
`the client 110 to whatever degree chosen by the vendor. In
`a PC/ Microsoft Windows™ cnvironment, a user double-
`clicks on an icon representing the executable file for a
`vendorsoftware application, which may appear either within
`the installation directory or as a shortcut on the desktop. The
`executable file is called demo_mod.exe and is the demon-
`stration version (i.e., demonstration software module) of the
`vendor software application supplicd by the vendor. The first
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`The server 150 may be configured, maintained and oper-
`ated by a third party other than the vendor. For example,
`vendors may outsource the automated method of unlocking
`and paying for their software applications as contemplated
`by the present invention to a third party. The toll-free 800 or
`888 telephone numberthat the user dials when accessing the
`server for purposes of unlocking and paying for a vendor’s
`software application serves as an index to the third party
`indicating one of perhaps multiple vendors for which such
`services are being provided by the third party.
`A database on the server 150 maintains information
`regarding at least one vendor,asis the case when the vendor
`maintains the server, or multiple vendors, in the case where
`
`

`

`6,134,593
`
`7
`vendors outsource the unlocking and payment processing to
`a third party. In the latter case, separate tables are maintained
`per each vendor, in which are stored installation identifiers
`and product distribution identifiers. When an installation
`identifier and productdistribution identifier are provided by
`a user to the server, the appropriate vendor table in which to
`search for such identifiers is located in the database accord-
`ing to, for example, the toll free numberdialed by the user.
`If the installation identifier and product distribution identi-
`fier are located in the appropriate vendortable, the server
`produces a password, or unlocking key, and passes the same
`to the client computing device at step 350, after payment for
`the application has been processed at step 345, as discussed
`in below.
`
`At step 345,the user has input the productdistribution and
`installation identifiers, and the server looks up the pricing
`information related to the vendor software productidentified
`by the two identifiers. The pricing information is confirmed
`to the user. User prompting and input regarding credit card
`information,e.g., credit card number, type, and expiration,is
`transmitted via an automated Interactive Voice Response
`(IVR) system utilizing touch tone techniques with telephone
`105, or alternatively, via an Internet session or the like
`between the client 110 and the server 150.
`
`After payment for the module has been processed, a
`password generation routine executing on the server takes
`the product distribution identifier and installation identifier
`and creates a unique password through a mathematical
`routine. The mathematical routine varies uniquely by client
`and product such that different passwords are gencrated for
`different software products for a particular vendor.
`The password may be communicated to the client com-
`puting device by any one of a number of means,including
`butnot limited to a data communicationslink with the client
`110, such as the Internet 125, including a World Wide Web,
`FTP or Telnet session, or a telecommunications link
`utilizing, for example, Interactive Voice Response (IVR)
`technology in connection with telephone 105 and corre-
`sponding touch tone or DTMFtone techniques, the impor-
`tant point being that the method for providing the password
`is entirely automated—nointeraction with a telephone ser-
`vice representative is required.
`In one embodiment, an
`additional step of checking the password against an expira-
`tion date associated with the module is performed. The
`expiration date could be prompted to and input by the user
`as part of the unlocking or payment processing routines, or
`stored either at
`the client or server at
`installation or
`attempted execution, and retrieved as part of the unlocking
`or payment processing routines.
`Forreinstallation of a software module, a public version
`of the password, along with an associated expiration date, is
`stored in or accessible by the client computing device, for
`example, in a ASCII file, so that it may be viewed by the
`user. Given that there is a configurable numberof times that
`the user can attempt to unlock a locked software module, the
`public password does not present a security threat.
`With reference to FIG. 4, the password 400 created and
`transmitted by the server 150 to the client computing device
`110 is derived from a number of different identifiers and
`
`procedures. The product distribution identificr 420,
`described above, is vendor specific and application software
`product specific. Thus, it provides, in part, the identity of the
`product being unlockedoractivated, and providesthe ability
`to track the numberof software applications distributed (on,
`for example, CDs) and successfully activated from multiple
`distributors at multiple locations. Thus, as is shown in FIG.
`
`5
`
`10
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`8
`4, the product distribution identifier 420 comprises at least
`a product identifier 410 that identifies a particular software
`vendor’s application software product. For example, differ-
`ent versions of the same product may havedifferent product
`identifiers.
`
`Additionally, the product distribution identifier 420 may
`comprise a distribution identifier, a location identifier, and a
`checksum (none of which are shown in TIG. 4). The
`distribution identifier may indicate, for example, a particular
`build or compilation of the software application, or distri-
`bution channel. The location identifier may identify the
`geographical location to which the software application (as
`stored, for example, on permanent storage media such as a
`CD) wasshipped, either byitself or as a unit in a lot or block
`shipment. The product distribution identifier thus provides
`the ability for a vendor to track any numberof products
`according to any numberof distribution methods.
`The installation identifier 450, from which the password
`is also partly derived, comprises a vendoridentifier 430 and
`a clicnt computing device identificr 440, or simply, clicnt
`identifier 440. The vendoridentifier 430, of course, identifies
`the vendorthat is selling or licensing the software applica-
`tion for which the password is being provided. The client
`computing device identifier 440 identifies the particular
`machine or computing device on which the vendor’s soft-
`ware application has been installed, and is hidden from the
`user. The client identifier can be created and stored in the
`
`client computing device at the same time the installation
`identifier
`is stored,
`i.c., when the vendor software
`application, or relevant portion thereof, such as module
`2105,is installed on the client computing device. Just as is
`the installation identifier,
`the client identifier is machine
`dependent—.e., it is based on the client computing device
`or combination of the client computing device and vendor.
`At run-time, the password and client identifier are checked
`to verify that they correspond correctly. If they do,
`the
`application or module, whatever the case may be, can be
`executed.
`
`There is a mathematical relationship between the pass-
`word andclient identifier. However, encryptionis utilized to
`secure the client
`identifier to the password, so that
`the
`relationship between the client identifier and password is
`obscured. The encryption involves a multi-step process: the
`installation identifier is derived through encryption of the
`client identifier; the installation identifier is then encrypted;
`and the password then derived in part through the encrypted
`installation identifier.
`
`With reference again to FIG. 3, at step 355, upon recciv-
`ing the password from the server,
`the payment routine
`displays the password on the display device attached to the
`client computing device and prompts the user to enter the
`password to activate the application 210b. The user then
`enters the password, by one of various means, including
`keyboard, microphone 109 or telephone 105 input. The
`password is then verified by the payment routine. If the
`passwordis verified, the paymentroutine transfers control to
`the application 2106 at step 360. Optionally, the payment
`routine transfers control to module 210a or 2105, cither of
`whichcalls the unlocking routine to verify both payment for
`and authorization to use the module 210b. If the password is
`determined to be incorrect by the unlocking routine (c.g.,
`through incorrect data entry on the telephone keypad or
`input device for the client computing device), an error
`message is displayed on the display devicc. Some number of
`attempts to unlock the module 2105,e.g., three, is provided,
`after which the user is prevented from further attempts, e.g.,
`to prevent tying up an IVR port on the server, or prevent a
`
`

`

`6,134,593
`
`9
`hacker from attempting many possible combinations of
`product distribution and installation identifiers.
`In the
`embodimentutilizing the TVR system, once module 2105, or
`full_mod.exe in our example above, is activated, the user
`hangs up from the IVR. The IVR system records the
`activation that just transpired, including l