System and method controlling access to digital works using a network

TECHNICAL FIELD

[0001] The field of the invention relates generally to a system and method of controlling access to software (or other digital media accessible by software) using a network to allow remote authorization.

BACKGROUND ART

[0002] It is known in the art that unauthorized use of software applications, (and digital media accessed by such applications) is difficult to prevent. However, the availability of network connections is becoming widespread and this can provide a client/server mechanism by which to improve control of access to such works. In this client/server system, a consumer has an electronic device, such as a video game console or general purpose personal computer, which is the client, and which is capable of communicating over the internet with a server.

[0003] The server may act as a database of licensing and access rights for authorizing remote access to the desired work. Such works may be acquired for installation through any distribution method, including over the internet itself. The distributor or owner of the work may wish to completely prevent access to unpaid unauthorized users, or may wish to provide restricted access (e.g. a limited trial period). There is a need for a system and method which provide flexible access rights to such digital works.

[0004] It is further known in the art that most resident software running on an insecure client machine is inherently untrustworthy, in the sense that it is not exceedingly difficult for a party to substitute their own programs in order to allow the party to perform unauthorized actions. The client/server mechanism therefore wishes to rely only on the actions of trusted software modules that act as agents of the server. Such trusted modules may or may not normally completely reside on the client. Any temporarily installed software component that represents the interests of the server, and which is delivered over the internet, is called a remote agent.

[0005] It is also known in the art that the internet is not an inherently secure environment: it must be assumed that any data transmitted over the internet between a client and server can be intercepted and analyzed. Therefore secure cryptographic techniques are required when transmitting information that should remain secret (i.e., which should remain known only to the server or one of its agents). Such generic cryptographic techniques include block or stream encryption under secret keys, as well as key exchange protocols.

[0006] To prevent an attacker from directly modifying the desired application programs to induce desired behaviour (e.g. to acquire unauthorized access), encryption of all or part of those programs may be used, but a decryption key must then be provided (normally to a remote agent) to decrypt the programs in order to grant authorized access. This in turn necessitates a method by which such a secret can be securely transferred over the insecure network.

[0007] Finally, the client/server authorization method naturally allows a conduit for additional information to be provided to the consumer on launch of the digital content in question. This creates an opportunity for directed consumer advertisement.

DISCLOSURE OF THE INVENTION

[0008] In one aspect the invention provides a method and system of providing controlled access to digital works by communicating over an insecure network. The insecure communications network comprises a client and server. The method comprises employing a client identification code to uniquely identify the client to the server; employing a content identification code to identify the digital work; transmitting from the client to the server the client identification code; and evaluating access rights of the client to the digital work at the server by checking the client identification against a database comprising access rights for a plurality of clients for the data content; and if the access is authorized, transmitting to the client a secret used to gain acces to the digital work.

[0009] In the first aspect, the method may include providing a software module at the client for coordinating access-rights checking with the server, said software module being attached to form an integral part of any software application digital works.

[0010] In the method of the first aspect, the step of transmitting may be performed when on-line connection to the authorization server is possible. When on-line connection to an authorization server is not possible, the method may include locally evaluating at the client a set of time-limited access rights stored locally, said locally stored access rights having been previously digitally signed and transmitted by the server, and if said access is authorized, allowing off-line access to the digital work.

[0011] In the first aspect, the method may include updating the dynamic client identification code so that copied off-line access rights will be invalidated at subsequent server contacts. The method may include leaving in local storage at the client a set of access rights digitally signed by the server to allow subsequent off-line usage. The method may include encrypting the secret or authorization code prior to transmitting it.

[0012] In another aspect, the invention provides a method for creating a client identification code by composing the identification code as a concatenation of a fixed identifier unique to the server, a changeable sequence number incremented by the server, and a changeable pseudo-random number; and at every authorization contact of a client with a server, updating the client and server database with a modified identification code.

[0013] In another aspect, the invention provides a method and system of transmitting in encrypted fashion to the client a secret over an insecure communications network. The insecure communications network comprises a client and server. The method comprises establishing a composite session key common to both the client and the server where the client and the server each provide one portion towards construction of the composite key, where the composite key cannot be constructed by any other party not knowing one of the two provided portions; encrypting the secret with the composite session key to form an encrypted secret; transmitting from the client to the server an authentication message, where the authentication message is known only to the client and the server within a time limit, and to no other party within the time limit; transmitting the encrypted secret from the server to the client if and only if the authentication message is valid and is received by the server within the time limit; and decrypting the encrypted secret at the client using the session key to recover the secret.

[0014] In still yet another aspect, the invention provides a database association in a software license environment for multiple copies of different digital works and at least one machine. The database association has a first record for a digital work license owner; a second record for new digital work licenses controlled by the owner which have not yet been assigned to a machine; a third set of records for machines controlled by the owner; for each machine in the third set, a set of records of installed digital works associated with the machine; and for each record in the set of records of installed digital works a record for a license relating to the installed digital work.

[0015] The database allows manipulation and access of records therein when (i) a record for the owner does exist in the database and a query is being made regarding status of the owner to the database; (ii) a record for the owner exists in the database and the owner is attempting to access a digital work for which a record is not in the database; and (iii) a record for the owner exists in the database and the owner is attempting access a digital work for which there is a record in the database.

[0016] In still yet another aspect, the invention provides a method and system of distributing supplemental data content (e.g. advertising) from the server to the client or other clients in a communications network where a client communicates with a number of types of servers. The method comprises when the client is executing a program, contacting an authentication server to determine whether the primary data content should be provided to the client; and retrieving from a data content server the supplemental data content and transmitting the supplemental data content to the client for display on the client.

BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The foregoing and other aspects of the invention will become more apparent from the following description of specific embodiments thereof and the accompanying drawings that illustrate, by way of example only, the principles of the invention. In the drawings, where like elements feature like reference numerals (and wherein individual elements bear unique alphabetical suffixes):

[0018]FIG. 1 is a block diagram of an exemplary communications network in which the preferred embodiment of the invention may reside;

[0019]FIG. 2 is a block diagram of a client and server communicating over an insecure network associated with the embodiment of FIG. 1;

[0020]FIG. 3 is a block diagram of a modified client/server network of FIG. 2;

[0021]FIG. 4 is a block diagram of a client in a client/server network operating after initiation of a process associated with the embodiment of FIG. 3;

[0022]FIG. 5 is a block diagram of another aspect of the embodiment showing a secure transmission protocol;

[0023]FIG. 6 is another block diagram of another secure transmission protocol for the aspect of the embodiment of FIG. 5;

[0024]FIG. 7 is a block diagram of relationships existing amongst object classes in a database associated with another aspect of an embodiment;

[0025]FIG. 8 is a flow chart of a system states for objects related to another aspect of an embodiment of FIG. 7;

[0026]FIG. 9 is a block diagram of an authentication process for a client in a multiple client/server network in yet another aspect of an embodiment of the invention;

[0027]FIG. 10 is another block diagram of a process related to an aspect of the embodiment of FIG. 9; and

[0028]FIG. 11 is another block diagram of a process related to an aspect of the embodiment of FIG. 9.

MODES FOR CARRYING OUT THE INVENTION

[0029] The description which follows and the embodiments described therein, is provided by way of illustration of an example, or examples of particular embodiments of the principles of the present invention These examples are provided for the purposes of explanation, and not limitation, of those principles and of the invention. In the description, which follows, like elements are marked throughout the specification and the drawings with the same respective reference numerals.

[0030] Referring to FIG. 1, in order to provide secure authentication and controlled application program startup, it is necessary to employ secure software. Part of this secure software will reside and execute inside a protected computer called a “server” <b>102</b> that is connected to user PCs <b>100</b> through a communications network, such as the Internet (“web”) <b>104</b>. Many types of connections to the internet <b>104</b> are known in the art, including modem connections and cable connections. The remaining part of the secure software must execute on user PC <b>100</b> (or console). Ideally the user PC software should remain temporarily on the user PC for the purposes of application startup. This software is identified as “remote agent” (or “RA”) <b>106</b>. Alternately, bcal permanently-resident software may act in place of a temporary remote agent, but with reduced security.

[0031] The remote agent <b>106</b> acts as the remote presence of the secure server software, and must authenticate itself to the server before application program startup will be authorized by the server. Once the RA <b>106</b> authentication process is satisfied, if encryption has been used, a media “key” will be passed to the RA <b>106</b> who will then use it to decrypt an encrypted portion of the application. Once decrypted, the application will be started by the RA. The media “key” (if employed) must be encrypted to prevent an eavesdropper from decoding its contents.

[0032] The RA <b>106</b> is transmitted from the server to the client, and is installed by the initialization program for execution on the user PC. Unlike typical software “installation” process that PC users are familiar with, the RA <b>106</b> installation process is dynamic, requiring only a fraction of a second to complete.

[0033] The RA <b>106</b> performs the following activities:

[0034] a) extracting the unique ID of the user PC;

[0035] b) optionally, verifying that the application and INIT program are intact and unhampered;

[0036] c) optionally, verifying that a valid operating system is present; like a familiar windows-based interface;

[0037] d) optionally, verifying that it itself has not been modified since installation;

[0038] e) computing a unique authentication response to verify itself and the PC's ID to the server; and

[0039] f) if encryption of the digital work has been employed, securely (secretly) receiving the media key from the server.

[0040] Also, the RA <b>106</b> must be preferably resistant to attacks from programs residing on the user PC which attempt to take the media key.

[0041] Referring to FIG. 2, client <b>100</b> communicates with server <b>102</b> through insecure network <b>104</b>. It can be appreciated that Proxy <b>210</b> below is equivalent to RA <b>106</b> above. To control access, the embodiment performs the following steps:

[0042] 1. The user begins to attempt to access the secured digital work, which causes Launcher <b>206</b> to begin executing.

[0043] 2. Launcher <b>206</b> contacts Controller <b>208</b> through communications network <b>104</b>.

[0044] 3. Controller <b>208</b> downloads Proxy <b>210</b> to the Launcher <b>206</b>, which then invokes Proxy <b>210</b>.

[0045] 4. Proxy <b>210</b> extracts and transmits to Controller <b>208</b> an identifier of the digital content, CID <b>212</b>, and the unique user-device identifier UID <b>214</b>.

[0046] 5. The Controller <b>208</b> checks CID <b>212</b> and UID <b>214</b> against database <b>216</b> of previously recorded access rights.

[0047] 6. If access is to be granted, Controller <b>208</b> initiates method M by which Controller <b>208</b> transfers secret S <b>218</b> to the Proxy <b>210</b> (or transfers missing content encrypted under secret S <b>218</b>).

[0048] 7. Proxy <b>210</b> uses secret S <b>218</b> to decrypt the content (if encryption has been used).

[0049] 8. Proxy <b>210</b> erases secret S <b>218</b>, then allows user access to the decrypted content.

[0050] It can be appreciated that other variations may be incorporated in this aspect of the embodiment. Specifically, the Launcher <b>206</b> may subsume the functions of the Proxy <b>210</b>.

[0051] Identifiers UID <b>214</b> and CID <b>212</b> may be sent unencrypted or encrypted across the network <b>104</b> using methods known in the art.

[0052] Also, before the secret S <b>218</b> is transferred to the Proxy <b>210</b>, Proxy <b>210</b> may generate and send a message to the Controller to authenticate itself to the Controller <b>208</b> as its valid proxy.

[0053] The Proxy <b>210</b> may have various levels of security, producing varying levels of degrees of difficulty for an attacker to discover the secret S <b>218</b>. A more secure Proxy <b>210</b> would be unique, and not used twice. For example, Proxy <b>210</b> may generate an authentication response which is unique on each instance.

[0054] Further, referring to FIG. 3, the operation of the system of FIG. 2 may be modified such that the server is not contacted at every launch. Therein, the Launcher <b>206</b> will be responsible for enforcing access rights for the launches in which the Controller <b>208</b> is not contacted. To support this, a Proxy <b>210</b> must be sent at least for the first launch and must leave behind in non-volatile storage a data packet that will allow the Launcher <b>206</b> to decide on whether or not to grant access on subsequent launches in which the Controller <b>208</b> is not contacted.

[0055] The procedure for the first launch of this alternative embodiment is as follows:

[0056] 1. The user launches the digital work, which causes the Launcher <b>206</b> to begin executing.

[0057] 2. Launcher <b>206</b> contacts the Controller <b>208</b> over network <b>104</b>.

[0058] 3. Controller <b>208</b> downloads the Proxy <b>210</b> to Launcher <b>206</b>, which then invokes Proxy <b>210</b>.

[0059] 4. Proxy <b>210</b> extracts and returns to the Controller <b>208</b>, CID <b>212</b>, and a unique UID <b>214</b>.

[0060] 5. The Controller <b>208</b> checks CID <b>212</b> and UID <b>214</b> against a database <b>216</b> of previously recorded access rights.

[0061] 6. The Controller constructs a packet <b>300</b> that embeds within it the identifiers CID <b>212</b>, and UID <b>214</b>, the current access rights for that pair of identifiers, and the secret S <b>218</b>.

[0062] 7. Controller <b>208</b> then encrypts this packet <b>300</b> using its private signature key d <b>302</b>, to create signed packet P <b>304</b>, and transmits that packet to the Proxy. Signature key d <b>302</b> is the private half of a signature scheme (for example RSA) key pair (e,d).

[0063] 8. Proxy <b>210</b> records the packet P <b>304</b> in nonvolatile memory <b>306</b> on the user device.

[0064] In the alternative, Launcher <b>206</b> may provide any or all the functions of the Proxy <b>210</b> in the above steps, and by doing so to avoid the downloading of the Proxy <b>210</b> even on the first launch. Such a system is less secure in that it is more vulnerable to users discovering the secret S <b>218</b>.

[0065] Referring to FIG. 4 for subsequent launches of the application, the procedure is as follows.

[0066] 1. The client <b>100</b> launches the digital work, which causes Launcher <b>206</b> to begin executing. The Launcher <b>206</b> sees the presence of the Controller-signed signed packet P <b>304</b> in non-volatile memory <b>306</b>.

[0067] 2. Launcher <b>206</b> retrieves the packet P <b>304</b> from non-volatile memory <b>306</b>, decrypts it using the known inverse e <b>400</b> of the Controller's signature key d <b>302</b>, then extracts the values of CID <b>212</b> and UID <b>214</b> contained within that packet, along with the access rights.

[0068] 3. Launcher <b>206</b> now retrieves identifiers CID <b>212</b> and UID <b>214</b> from the digital work and the user device, respectively, and compares them to the access rights retrieved earlier from non-volatile storage.

[0069] 4. If the access values match, Launcher <b>206</b> is assured that Controller <b>208</b> has previously configured access for this CID <b>212</b> and UID <b>214</b> combination. If the access rights are still in effect (they have not expired), Launcher <b>206</b> will grant access. If encryption has been employed, the Launcher <b>206</b> then extracts S <b>218</b> from the packet P <b>304</b> and uses S <b>218</b> to decrypt the digital content to be accessed by the user.

[0070] 5. Launcher <b>206</b> erases secret S <b>218</b>, and allows access to the decrypted digital content.

[0071] Another aspect of the embodiment provides a method M for transferring a long-lived secret S <b>218</b> from a principal to its proxy agent over an insecure link. Specifically, the aspect utilizes a time-limited secret Z known to principal and proxy agent so that the principal may authenticate the proxy agent as the recipient of secret S. The method M employs encryption of secret S <b>218</b> by a one-time-use time-limited-secret key K_sto prevent an eavesdropper from capturing the value of S <b>218</b> while it is transferred over the insecure link. This one-time-use secret key K_sis established between principal and proxy using a method suitable for establishing such keys over an insecure link when the parties have had no previous communication, for example, by using the Diffie-Hellman protocol or one of its variants.

[0072] The secret value Z is known solely to the principal and its proxy agent during the time limit T. This may be pre-arranged by a transfer of the secret Z between proxy agent and principal over a secure link at some time prior to using the insecure link. The time-limit on the secret-keeping ability of the proxy agent only begins at a predetermined later time. This method can, for example, find application in networked computer systems where a remote software agent will have only time-limited secret-keeping ability. In such an application, secret Z can be securely transferred between the remote agent (the proxy agent) and its principal prior to dispatch of the agent to its remote location. Once the agent is dispatched, the clock would begin to tick on its secret-keeping ability.

[0073] Referring to FIGS. 5 and 6 the aspect employing the normal Diffie-Hellman protocol is shown. FIG. 6 shows the method employing the Hughes variant of the Diffie-Hellman protocol (which allows much of the principal's required computation to be done beforehand).

[0074] In FIG. 5, n is a large prime number equal to 2p+1 where p is also a large prime. The size of n should be sufficient to make the task of computing discrete logarithms in the finite field (0,n−1) computationally prohibitive.

[0075] Also, g is a small number which in the aspect is primitive modulo p. This means that if g is raised to all integer powers in the range (0,n−1) with the result reduced modulo n, this reduced result would cover all possible values in the range (0,n−1). It can be appreciated that, g need not be a primitive element, but must at least be a value that will generate a very large subgroup of the integers in the range (0, n−1).

[0076] In this aspect of the embodiment, the following steps are performed:

[0077] 1. The principal <b>500</b> and its proxy agent <b>502</b> generate random values X_p<b>504</b> and X_a, <b>506</b> respectively, from which they compute corresponding values Y_p<b>508</b>, wherein Y_p=g^Xpmod n and Y_a<b>510</b>, wherein Y_a=g^Xamod n, respectively, using exponentiation modulo n;

[0078] 2. The principal <b>500</b> and proxy agent <b>502</b> exchange values Y_p<b>508</b> and Y_a<b>510</b>;

[0079] 3. The principal <b>500</b> and proxy agent <b>502</b> compute values K_p<b>512</b>, wherein K_p=Y_a^Xpmod n and K_a<b>514</b>, wherein K_a=Y_p^Xamod n, respectively, using exponentiation modulo n. This establishes a composite session key common to both the client and the server where the client and the server each provide one portion towards construction of the composite key, where said composite key cannot be constructed by any other party not knowing one of the two provided portions. If there has been no interception and modification of messages Y_pand Y_a, agent <b>502</b> and server <b>500</b> will compute identical values K_pand K_a, i.e., K_a=K_pand this common value is called K_s;

[0080] 4. Principal <b>500</b> and proxy agent <b>502</b> now each compute a secure hash value of their previously computed K value (K_pand K_arespectively), and encrypt the hashed value H (H_p<b>516</b> and H_a<b>518</b> for principal <b>500</b> and proxy agent <b>502</b>, respectively) under the time-limited secret Z to produce a validation message V (V_pand V_afor principal and proxy agent, respectively). The encryption of H_a<b>518</b> by the proxy agent <b>502</b> acts as its signature.

[0081] 5. The proxy agent <b>502</b> then returns its validation message V_a<b>522</b> to principal <b>500</b> (and the principal <b>500</b> can optionally send its validation message V_p<b>520</b> to the proxy agent);

[0082] 6. If principal <b>500</b> receives validation message V_a<b>522</b> within the time limit T (that is, within time T from the time at which a clock started on the proxy agent's secret-keeping ability), it then compares it to its own validation message V_p<b>520</b>. If there is a match, the principal is assured that it has in fact exchanged secret session key K_swith the intended proxy agent, and not with an impostor (i.e. any party that cannot discover secret Z within time limit T). The server then encrypts the secret key S <b>218</b> under the shared secret KS to form message W, and sends that to the proxy agent. If the validation message V_ais, however, not received before time T elapses, the server aborts the protocol; and

[0083] 7. The proxy agent uses K, to decrypt W and recover secret S. This completes the transfer of secret S.

[0084] It can be appreciated that principal <b>500</b> may be equivalent to server <b>102</b> and proxy <b>502</b> may be equivalent to RA <b>106</b>, or to Launcher <b>206</b>.

[0085] In yet another aspect of the embodiment, a method for multiple independent accesses to a server is provided. Using the standard server-side digital rights management paradigm, software licenses are necessarily associated with specific machines. The following method allows for portability of machine-specific licenses from workstation to workstation.

[0086] The server co-ordinates use of software installed on the PCs. It responds to authentication requests, accesses a server-side database to determine software legitimacy and coordinates access control with the client-side software module. In the preferred embodiment, the server is object-oriented, comprising a modular arrangement of processes. The object classes thereof mimic conceptual components of a known software licensing system.

[0087] Referring to FIG. 7, a class-hierarchy enabling multiple accesses is shown. The class hierarchy consists of:

[0088] an owner <b>716</b> (comprising a collection of Machine objects <b>700</b> and a FloatingLicenses object <b>720</b>);

[0089] Machine objects <b>700</b> (comprising collections of Application objects);

[0090] FloatingLicense objects <b>720</b> (comprising collections of ApplicationLicenses <b>724</b> owned by a user, but not affixed to a Machine);

[0091] Application object <b>704</b> (comprising a LicenseTerms object <b>706</b>); and

[0092] UserID objects <b>730</b> (specifying a legitimate user in connection with the Owner of the machines).

[0093] Machine object <b>700</b> is the central object of the embodiment, and the first one accessed by the database upon initiation of an authentication request from the client. The primary database search key is the MachineID <b>702</b>.

[0094] The Initial request from the client contains the AppID of the application attempting to launch, and the MachineID <b>702</b> of the machine attempting to launch it. MachineID <b>702</b> itself is in the preferred embodiment a combination of i) an identifier unique to the database serving the client; ii) a sequence number maintained by the database's authorization server; and iii) a large pseudo-random number to make MachineIDs unpredictable. At every authorization contact of the client with the server, the sequence number portion is incremented, the large pseudo-random number portion is modified to a new pseudo-random value, and the resulting new client identification code is updated in both the server database and at the client.

[0095] Machine objects contain a collection of application objects <b>704</b> in a one-to-many relationship (noted by link <b>708</b>), which are uniquely identified by AppID <b>706</b>. The AppID <b>706</b> is a unique identifier for a single version of a software application produced by a vendor. There can be any finite number of applications associated with a Machine, or none at all. An application object <b>706</b> represents a software license associated with that application. By adding an application object <b>706</b> to the collection in a Machine object <b>700</b>, the application license may be validated on that machine, pursuant to the qualification of licensing terms. LicenseTerms objects <b>710</b> are associated on a one-to-one basis with Application objects <b>704</b>, as noted by link <b>712</b>. A LicenseTerms object <b>710</b> is a self-contained, self-executable set of instructions for determining whether a software license is valid to be launched on a given machine. Data regarding license validation criteria, as well as current standing in the license, are stored in LecenseTerms object <b>710</b>, including criteria for licensing options available to the user for the given Application. The important feature of the LicenseTerms object <b>710</b> is the IsActive( ) task <b>714</b>, which returns true if the licensing conditions are met for a particular launch, and false if not.

[0096] While the system ties a software license to a specific machine via Machine object <b>700</b> and its Application objects <b>704</b>, it is important to support the transferability of licenses from one machine to another. Ease of transfer of licenses between machines must be balanced with control and tracking of where licenses reside (i.e. on which machines) and ownership of the machines. To this end, the Owner object <b>716</b> is a collection of machines owned by the same individual. This is represent by a many-to-one link as noted by link <b>718</b>. License portability is effected by the user via the Owner model; licenses that are purchased are associated with the owner through a FloatingLicense <b>720</b> before they are tied to a given machine. There is a one-to-one relationship between Floating License <b>720</b> and Owner <b>716</b> as shown by link <b>722</b>. The FloatingLicense object <b>720</b> is a variant on the Machine object <b>700</b>. There is a one-to-many relationship between Floating License <b>720</b> and ApplicationCollection object <b>724</b> as shown by link <b>726</b>. The FloatingLicense object <b>720</b> does not contain members representing a MachineID <b>702</b>. It is essentially a collection of currently unused licenses purchased by the owner. Any given Owner has only one FloatingLicenses object <b>720</b>.

[0097] When a license is first associated with an Owner it is not associated with a Machine. All licenses associated with an Owner that are not yet associated with one of its Machines are instead associated with its FloatingLicenses object <b>720</b>. When the software application for which the license was bought is run, the license is found in the FloatingLicenses <b>720</b> and transferred to the given Machine.

[0098] A User object <b>730</b> simply stores a name and password <b>732</b> providing access to an Owner object <b>716</b>. This is a many-to-one relationship as shown by link <b>734</b>. The reason for implementing a distinction between user and owner is to provide for multi-user access for large corporations or bodies in which it is important to distinguish between the owner of a license and individuals acting on behalf of that owner. It can be appreciated that other features of the server software may provide restricted access capabilities, granting access to certain users and not to others.

[0099] In use the server-side database is catalogued by MachineID <b>702</b>. These MachineID <b>702</b> entries match pointer values which point at the appropriate Machine objects <b>700</b>. Sinc e authentication requests are performed using MachinelD numbers as the validation criteria, this allows the entire semi-radial object structure to be accessible through a standard database query.

[0100] Typical on-line authentication request consists of:

[0101] 1. Lookup Machine object <b>700</b> with associated MachineID <b>702</b>

[0102] 2. Navigate to Machine object <b>700</b>

[0103] 3. Lookup Application object <b>724</b> within Machine object <b>700</b> with associated AppID <b>724</b>

[0104] 4. Navigate to Application object <b>724</b>

[0105] 5. Navigate to LicenseTerms <b>710</b> to determine if license is still valid

[0106] 6. Launch contingent to validity of license

[0107] 7. Update the value of the dynamic MachineID <b>702</b>.

[0108] Referring to FIG. 8, one of these paths are followed when a user signs onto the system: (i) First contact, (ii) first use of software and (iii) normal launch.

[0109] In a first contact scenario <b>800</b> by a machine is made with the system, there is no record of the user's system in the database. The client side compiles MachineID <b>702</b> which does not match up with any database entries. Thus, ApplicationID <b>728</b> must be associated with an Owner <b>716</b>. The system will ask for a username and password. If the user has one, the user enters it, and the user is taken to the software vendor's purchase website to negotiate payment for the software, or to enter a registration key if the software was bought in a store. The vendor's website alerts to the system of the purchase by the Owner of a new license, which is stored in the FloatingLicenses object <b>720</b>.

[0110] If the user has no username, the user is taken to the server website for assignment of a username and password.

[0111] In a first use of software, at node <b>802</b> an existing user is attempting to run a new piece of software. Because the MachineID <b>702</b> is already stored in the database and is associated with an Owner object <b>716</b>, no username or password is necessary. However, the ApplicationID <b>706</b> given by the client will not match an Application stored in that Machine object <b>700</b>; thus the system must attempt to locate a license owned by that user or ask the user to purchase/register one.

[0112] The server checks the FloatingLicenses object <b>720</b> to determine if a license has been purchased. If the user has already negotiated purchase or registration with the vendor website, the license is transferred from the FloatingLicenses object <b>720</b> to the Machine on which the user is attempting to launch. Otherwise, the user is taken to the software vendor's website (again, to negotiate license purchase or to register a store-made purchase), at which point the new license is stored in the FloatingLicenses object <b>720</b>.

[0113] In a normal launch, information on MachinelD <b>702</b> provided to system by the client exists in the database, and the ApplicationID <b>728</b> given by the client matches an Application within the Machine object <b>700</b>. To ensure that the purchase license is still valid, the LicenseTerms object <b>710</b> is checked to ensure that the user still should have access to the Application. If isActive( ) task <b>714</b> of the LicenseTerms object <b>710</b> returns false, the user is no longer allowed to access the application, and the Application object <b>706</b> is deleted from the Machine object <b>700</b>. Otherwise, an access normal run is approved. The LicenseTerms object <b>710</b> may be updated to reflect this access.

[0114] Still yet another aspect of the embodiment provides a method by which the communications connection between a client and an authentication server may be accessed by an alternative conduit provider in delivering supplemental data content, such as advertising, to the client.

[0115] The method includes a web page interface, allowing companies to exchange advertisement spaces of their software applications and advertise their own products. It also allows other non-software/software companies (External Advertisers) to purchase advertisement spaces that belong to the server community.

[0116] Referring to FIG. 9 in a distributed advertising system, a plurality of clients would be linked to an application server through a communications network. Also an advertising server is associated with the networks, which provides a series of advertisements or other communications to selected clients.

[0117] The following procedure is used to distribute advertising.

[0118] 1. Client Software (i.e. primary data content) contacts authentication Server to request for authentication.

[0119] 2. a) an authentication process is performed (which may be as described above).

[0120] b) If an Advertisement is allowed for this run of executing software (Determined by the frequency of advertisement occurrence as determined by individual Software Vendors), the Authentication Server contacts the Advertisement Server and starts the Advertisement process, passing the Software Application Number to it.

[0121] 3. Advertisement Server looks up the sorted database with the Software Application Number.

[0122] 4. Advertisement Server obtains the appropriate Advertisement Number.

[0123] 5. Advertisement Server contacts the Advertisement Bank with the Advertisement Number.

[0124] 6. The Advertisement matching the Advertisement Number is passed back to the Advertisement Server.

[0125] 7. The Advertisement is downloaded to the Client machine and executed.

[0126] Referring to FIGS. 10 and 11, the distribution space of a Software Vendor consists of a record of times in which an advertisement can be send to the Client machine during authentication of that Software Vendor's software. This distribution is divided into three sections: advertisements which allow Software Vendors to perform their own advertisements; advertisements that are traded among the server; and advertisements from external advertisers.

[0127]FIG. 10 shows the contents of the first Web page in which to advertise. User has four choices of selecting a sub-domain. a) is for external advertisers, b) is for a group who wishes to trade advertisements, c) is for Software Vendors' submission of advertisements for its own products placing with own Software titles, and d) is Software Vendors' submission of Software titles as conduits for advertisements.

[0128] External advertisers will be directed to the contents as shown on FIG. 11, where there will be three choices. The external advertiser can place his/her advertisement by software vendor, software titles, or by the sorted data.

[0129] If the user chooses b), server the user will first be asked to choose another member to trade with and submit a software title to be traded. Then, the user selects a software title for advertisement or placement. First, the system will seek other members who are searching for advertisement space to exchange and verify if there are any that is requested by this member. If there are, the system will check if these other member request the advertisement that this member had submitted. It there is a match, the system immediately places the advertisement submitted by both parties into the advertisement spaces and emails will be sent to both parties' account Web page. If not, the system will send out a priority email to notify the other member who this user wishes to trade with. The other member can then check this email in his/her own account and confirm the transaction on his/her account Web page.

[0130] If the system user chooses to advertise his/her companies own product using its own Software, he can do so by selecting c). The system will direct the user to a Web page where he can choose and manage the advertisement spaces (software titles) where he/she can put the advertisement. This is illustrated in FIG. 11.

[0131] If the system user chooses to put up an advertisement space of either exchange or sale to external advertisers he/she may do so by choosing d). The system user can simply go to his/her company's account Web page where he/she can submit his/her advertisement space.

[0132] It can be appreciated that while the above aspect of the preferred embodiment is described in the context of distributing advertisements over a network, it will be appreciated that other content may be distributed over a network using the same aspect of the embodiment.

[0133] It is noted that those skilled in the art will appreciate that various modifications of detail may be made to the present embodiment, all of which would come within the scope of the invention.