Multi-domain access control

ES 2 409 629 T3

DESCRIPTION

Multi-domain access control.

RELATED APPLICATION

This patent application claims priority from US Provisional Patent Application No. 60 / 150,392, filed October 23, 1999, entitled Multi-Domain Support in a Web Application Access System, which is hereby incorporated medium by reference in its entirety.

FIELD OF THE INVENTION

The present invention relates to the management of access to accessible resources on a network.

BACKGROUND OF THE INVENTION

Computer networks have become ubiquitous in business, industry, and education. Networks have one or more resources, such as application programs that provide various computing functions, that are available to all users. The development of the globally accessible, packet-switched network known as the Internet has allowed network resources to become available worldwide. The development of the hypertext protocol (“HTTP”) implemented by the World Wide Web (the “web”) enables networks that serve as a platform for global electronic commerce. In particular, through the web a company easily exchanges information with its customers, suppliers and partners around the world. Because some information exchanged is valuable and sensitive, access to it should be limited to selected users. Thus, there is a need to provide selective access information available on the web.

One approach to solve the aforementioned problem is to protect a set of accessible resources on the network with an access control mechanism. An access control mechanism is a combination of software and hardware configured to manage access to a set of resources connected to a network. Often the access control mechanism is a commercial computer program, which is purchased as commercially available computer program from suppliers of access control mechanisms. A resource is a source of information, identified by an identifier, such as a uniform resource locator ("URL") or an Internet protocol ("IP") address. A resource protected by an access control system can be a static file ("page") containing code conforming to the Hypertext Markup Language ("HTML") or a dynamically generated page created by programs based on the User Interface. Common Gateway (“CGI”). Examples of resources include a web page, a full web site, a web-enabled database, and a mini application.

FIGURE 1 is a block diagram depicting an exemplary network architecture 100 that includes a system protected by an access control mechanism 101. The exemplary network architecture 100 includes a browser 110 coupled by a communication link to a network 102 . The block shown for browser 110 represents a terminal, a workstation computer, or an equivalent that runs a standard browser program or an equivalent, such as Netscape, Navigator, Internet Explorer, or NCSA Mosaic. Network 102 is a compatible information communication network, preferably the Internet. In alternative embodiments, browser 100 is a client process or client workstation of any convenient type, and network 102 is a data communication network that can transfer information between the client and a server that is also coupled to the network. .

The term server is used here to refer to one or more pieces of computer software or hardware that are dedicated to providing required functions ("services") on behalf of clients transmitting requests. A server can be a software module that can be invoked by and run by a client process, a separate process that receives requests from other client processes running the same computer system, or a set of processes that run on a set of computers, where processes respond to requests through clients running on other computers.

Access control system 190 is coupled to network 102 and provides services used to manage access to protected servers 150, including user authentication and verification services, in a manner that will be described in greater detail later. Protected servers 150 are also coupled to network 102 and supply one or more resources.

Before a user can access a resource on the protected servers 150, the user must first log into the access control system 190, supplying information to the access control system 190 used to authenticate the user. Users can register either with a digital certificate transmitted to access control system 190 or by opening a registration page provided by access control system 190 with browser 110 and entering a name and password. Once the user is authenticated, an authenticated session is associated with the user, and the user can then access one or more resources on the protected servers for the life of the authenticated session.

ES 2 409 629 T3

For this purpose, the access control system 190 transmits one or more identification data, eg, snoopers, to the browser 110 that is used, at least in part, by a secured server to verify that the user has been authenticated. Sneaks are pieces of information that a server can create and transmit to a browser, to make the browser store the tip and relay it on subsequent requests to the servers. A snitch can be associated with a domain name used to identify the IP address of a server. A domain name is an identifier that identifies a set or one or more IP addresses. Examples of domain names are 'enCommerce.com' or 'uspto.gov'. A browser transmits a whistle in conjunction with a request to the server to access a resource, transmitting the whistles as part of the request. The transmitted tips are associated with the domain name of the server.

A domain name can be used in an address that identifies a resource, such as a URL. For example, a domain can be used to identify resources “sample1File.htm” and “sample2File.htm”, using the URL “www.demoDomain / sample2File.htm”, where 'demoDomain' is the domain name. The domain name corresponds to the IP address of a server that can serve a resource.

A domain is a collection of resources that can be identified by the domain name. In this way, 'sample1File.htm' 'sample2File.htm' are resources that belong to the same domain. The process of accessing a resource through a request that identifies the resource using a domain name is known as accessing the domain.

When a protected server receives a request for access from a client that has been authenticated, the protected server receives "access control messages" for the domain of the server. Access control tips can contain information used to verify that a user has been authenticated, and can contain data that specifies the user's privileges. A privilege is a right to access a particular resource. Access control tips are typically encrypted for security purposes.

A main disadvantage for a conventional access control system is that it only controls access to a set of servers and resources that belong to a domain. The underlying reason for this limitation is as follows. When a conventional access control system supplies access control messages to a user who has just been authenticated, the transmitted messages are associated with the domain of the access control system. When the browser requires access to another resource in another domain, the access control tips are not transmitted because they are associated with another domain. In this way, each domain name used to deploy a set of servers or resources requires its own implementation and maintenance of an access control system, adding the cost of securing accessible resources over a network. In addition, for each domain name a user must register. In this way, the user can be overloaded by repetitive registration procedures, or the number of domain names that can be used is limited by efforts to avoid overloading the user.

Based on the aforementioned, it is clearly desirable to provide an access control system that can be used to manage access to a set of resources deployed under multiple domain names, in particular, requiring a user to register only once for access the set of resources.

SUMMARY OF THE INVENTION

GB-A-2326802 describes a method to control access to a resource protected by an access control system that uses the transmitted access control information in conjunction with requests to access the resource to determine whether access can be allowed. , the method comprising generating a session ID and storing the ID in a database. After an initial verification, subsequent verifications are performed by the server contacting a controller to verify the validity of the session ID.

A mechanism is described that uses a single access control system to manage user access to resources belonging to multiple domains. In one embodiment, a server is associated with each domain in a set of domains. Access to resources in the domains is governed by an access control system. A first server for a first domain transmits a data token to a client seeking access to a resource in a second domain. The client transmits the data token to a second server in the other domain. The second server uses the data token to verify that the user is authorized to access the resources protected by the access control system. Once it is determined that the user is authorized to access the resources, the access control "tips" are transmitted to the client.

According to another embodiment of the present invention, when the client requires access to a resource in the second domain, and the request does not include access control prompts for the second domain, the data is transmitted to the browser causing it to generate another request to the first server. The first server ensures that the user has been authenticated before transmitting the data token to the browser. In addition, the first server can make copies of the access control messages for the user to be stored for later transmission to the second server.

ES 2 409 629 T3

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to like elements and in which:

FIGURE 1 is a block diagram depicting an exemplary network, network-coupled resources, and an access control system used to manage access to resources;

FIGURE 2 is a block diagram depicting an exemplary network, network coupled resources, and an access control system used to manage access to resources in multiple domains;

FIGURE 3A is a flow chart depicting a process used to manage access to resources in multiple domains;

FIGURE 3B is a flow chart depicting a process used to manage access to resources in multiple domains;

FIGURE 4A is a flow chart depicting a process used to manage access to resources in multiple domains;

FIGURE 4B is a flow chart depicting a process used to manage access to resources in multiple domains; Y

FIGURE 5 is a block diagram of a computer system that can be used to implement one embodiment.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

A method and apparatus for a multi-domain access control system is described. In the following description, for purposes of explanation, numerous specific details are set forth below to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention can be practiced without these specific details. In other examples, well known structures and devices are shown in block diagram form to avoid unnecessarily obscuring the present invention.

FIGURE 2 is a block diagram depicting exemplary network architecture 200, an architecture that incorporates a multi-domain access control system. A multi-domain access control system allows a user to access multiple domains but only requires the user to register once to gain access. Domains protected by a multi-domain access control system are referred to herein as trusted domains with respect to the multi-domain access control system.

Exemplary network architecture 200 includes browsers 210, each of which is coupled by a communication link to a network 202. The blocks shown for browsers 210 may represent a terminal, workstation computer, or an equivalent that runs a standard Web browser program or an equivalent, such as Netscape Communicator or Internet Explorer. Users 212 interact with browsers 210 to access resources through network 202. Network 102 is a compatible information communication network, preferably the Internet. In alternative embodiments, a browser 210 is a client process or client workstation of any convenient type, and the network 202 is a data communication network that can transfer information between the client and a server that is also coupled to the network.

Browsers 210 transmit requests for resources ("resource request") to protected servers 205, which transmit the required resource as long as the user initiating the request through a browser 210 has been authenticated by an access control system 220 Requests can be adjusted, and responded to, in a way that conforms to HTTP. The protected servers 205, including the protected servers 240, 260, 280, can be Web servers. In determining who has been authenticated, the protected servers 205 and the resources made available by the protected resources 205 may use one or more services of the access control system 220.

Each of the protected resources 205 can be addressed by a domain name. In this way, each of the protected resources 205 and the resources that can be accessed through the servers belong to a domain. Protected Server 240 and resources 248 and 249 belong to Primary Domain 241, Protected Server 260 and resources 268 and 269 belong to Secondary Domain Agent 262, and Protected Server 280 and resources 288 and 289 belong to Secondary Domain 282 The domains depicted in FIGURE 2 are labeled domain and secondary for reasons that will be explained in more detail.

To determine whether a user is authorized to access the resource, a protected server 205 uses access control alerts, which transmit information derived from them to the access control system 220. The access control alerts can contain encrypted data that specifies the information used to verify that the user is authentic. The protected server 205 can derive information from the tipsters, and then transmit a request to the access control system 120 to verify if the user is authorized, passing the information derived from the tipsters, as well as the required resource. The access control system 120 then responds by transmitting back a message that specifies whether or not the user is authorized to access the resource or any other resource.

ES 2 409 629 T3

COMPONENTS TO PROVIDE MULTI-DOMAIN ACCESS

To provide multi-domain access, access control information is created and stored. When a user first authenticates, a browser receives a set of access control tipsters associated with a particular domain from which the tipsters are broadcast. Later, the user can request access to another domain protected by the access control system 220. Therefore, when the browser transmits the request to a web server belonging to the other domain, the access control alerts for the user are not transmitted. A mechanism verifies if a user has been authenticated without having to receive access control prompts or make the user register again.

Such a mechanism is provided by the following components of the access control system 220: the Primary Domain Agent 242, the Secondary Domain Agents 262 and 282, and the MultiDomain Witness Server 208. These elements can be servers that cooperate with each other. to provide a multi-domain access control system, using a variety of techniques that will be described later in greater detail.

Although each technique is different, there are aspects of the functions performed in each by a component that remain the same. Also, different components, or a few components, that perform the same functions, are equivalent and can be used. Therefore it is useful to describe the role that each component plays by providing an overview of a multi-domain process, as follows.

Generally, in one embodiment, when a browser transmits a request to a protected server on behalf of a user to access a resource in a domain, and the browser transmits no access control flag for the domain, the browser connects to the child domain agent that belongs to the domain. The secondary domain agent makes the browser connect to the Primary Domain Agent 242. If the user has authenticated, then Primary Domain Agent 242 transmits to Multi-Domain Token Server 208 a request for a "Multi-Domain Token." A Multi-Domain Token is an encrypted data item used to verify that the user has been authenticated by the Access Control System 220, and will be explained in more detail. Multi-Domain Token Server 208 generates a Multi-Domain Token and supplies it to Primary Domain Agent 242.

The Primary Domain Agent 242 transmits the Multi-Domain Token to the browser, and causes the browser to connect to the Secondary Domain Agent. When the browser connects with the Secondary Domain Agent, the browser transmits a Multi-Domain Token to the Secondary Domain Agent. The Secondary Domain Agent then transmits to the Multi-Domain Token Server 208 a request to verify that the Multi-Domain Token represents a user who has been authenticated by the access control system 220. After receiving from the Multi-Domain Token Server 208 a message confirming that the user has been authenticated, the Secondary Domain Agent transmits to the browser the access control prompts that are associated with the Secondary Domain Agent's domain.

Multi-Domain Witness Server 208 includes various API functions to support multi-domain control. These include functions to create a Multi-Domain Token, verify a Multi-Domain Token, store and retrieve data for access control whistles associated with a particular domain, and add a trusted domain. A list of trusted domains is maintained by Multi-Domain Witness Server 208.

Multi-Domain Token Server 208 verifies that a Multi-Domain Token was issued from Multi-Domain Token Server 208 through the use of encryption technology. Because Multi-Domain Tokens are issued only to authenticated users, it can be assumed that a browser displaying a Multi-Domain Token has been authenticated.

In a preferred embodiment, the size of a Multi-Domain Token Server 208 is made small enough that it can be transported as part of the URL string in an HTTP request. The URL string is data transmitted as part of a resource request, and is transmitted regardless of the domain to which access is required. The URL string contains data that specifies the URL, and can contain other data, such as parameters in the form of name-value pairs. The amount of data that can be included in a URL string is limited. Because the URL string is always broadcast in a resource request, when a Multi-Domain Token is included in a URL string, it will be broadcast. If the Multi-Domain Token were included in a snitch, it would only be carried in a request for access to the domain associated with the snitch.

In one embodiment, protected servers 205 and access control system 220 are stored on and run by a physical server or computer. In alternative embodiments, one or more of these components are distributed on separate computers; this approach can improve security and performance. For example, each of the protected servers 205 can be installed on or run by separate computers. The Primary Domain Agent 242 and the Secondary Domain Agents 262 and 282 can be installed on the same computer as protected servers 240, 260, 280 respectively. Each of the protected servers 205 and the Secondary Domain Agent and various other components of the Access controller 220 can be located on an extranet for access by external users. The Multi-Domain Witness Server 208 can be attached to a secure intranet that is protected using a firewall.

ES 2 409 629 T3

For a Secondary Domain Agent to perform its role, it must be accessible to users for whom authenticated access control alerts cannot be provided. Consequently, Secondary Domain Agents 262 and 282 are not protected by access control system 120. On the other hand, Primary Domain Agent 242 is inherently protected. Because it is protected, any browser attempting to access the Primary Domain Agent 242 must transmit access control prompts showing that the user is authentic. If the browser does not present such access control tips, they can be obtained by performing registration procedures.

The Primary Domain Agent 242, the Secondary Domain Agents 262 and 282, and the MultiDomain Token Server 208 can be implemented using a variety of software technologies. For example, Primary Domain Agent 242, Secondary Domain Agents 262 and 282 can be written as CGI scripts, Netscape Server API, Internet Server API plug-ins. The MultiDomain Token Server 208 can be written using software used to generate CORBA compliant modules and objects.

MULTI-DOMAIN ACCESS CONTROL

FIGURE 3A, FIGURE 3B, FIGURE 4A, and FIGURE 4B are flow charts representing, in part, one embodiment of a process for implementing a multi-domain access control system. The steps are illustrated using the exemplary network architecture in FIGURE 2. In the illustration, clients communicate using the HTTP protocol. However, any version of HTTP can be used, or any other suitable communication protocol.

Referring to FIGURE 3A, at step 310, browser 210-1 transmits a resource request to protected server 260 for resource 268, a protected resource. A protected resource is a resource that can only be accessed by users authenticated by the access control system 220. In transmitting the resource request, the browser 210-1 did not transmit any access control tokens for the resource domain 268, that is, the child domain 261, which is referred to herein as the required domain.

In step 314, the protected server 260 determines whether or not the access control alerts for the required domain were transmitted to the protected server 260 as part of the resource request transmitted in step 310. If the access control alerts were received, then the steps shown in FIGURE 3A end. When the steps in FIGURES 3A-4B are described as ending, alternatively, other processing may occur. This processing may include, for example, operations to verify that the access control tokens represent an authentic user and provide access to the required resource, or operations to deny access to the required resource. The additional processing that occurs may depend on where the steps in the process depicted in FIGURE 3 - FIGURE 4B end.

If, on the other hand, in step 314, the protected server 260 determines that the access control messages for the required domain have not been transmitted, then execution proceeds to step 318.

In step 318, the protected server 260 redirects the browser 210-1 to a Secondary Domain Agent, for example, the Secondary Domain Agent 262. The term redirect refers to transmitting a redirect to a browser, which is data that makes the browser will generate another request for access to another resource specified in the redirection. The redirect can specify parameters and parameter values ​​to pass along with a request directed to the other resource. For example, the redirect can be accomplished by broadcasting a page with an HTML redirect tag. The tag includes data that specifies the URL of the Secondary Domain Agent 262. The tag can also include parameter values ​​in the form of, for example, name value pairs that are passed with the directed request.

In step 322, Secondary Domain Agent 262 receives the directed request from browser 210-1. In response, in step 324, the Secondary Domain Agent redirects the browser 210-1 to the Primary Domain Agent 242. The redirect specifies the parameter values ​​to pass as part of the request directed to the Primary Domain Agent 242. In a Preferred embodiment, these parameters are known herein as ORIGINATING_SDA, and may include the following.

1. The resource originally required.

2. The required domain, that is, the domain of the originally required resource.

3. The Secondary Domain Agent.

The parameters may comprise identifying information, for example, URLs or IP addresses.

Referring to FIGURE 3B, in step 328, the Primary Domain Agent 242 receives the directed request initiated in step 324.

ES 2 409 629 T3

At step 330, the Primary Domain Agent 242 determines whether the access control alerts for its domain have been transmitted with the directed request received at step 328. If not, then control proceeds to step 332, where it determines whether the user is authentic. The step may include various processes for authenticating users, including user / password authentication, or use of digital certificates. If the user is not authentic, then the execution of the steps ends. Otherwise, control flows to step 336, where the access control messages for the domain of Primary Domain Agent 242, domain 241, are transmitted to browser 210-1. At step 338, the browser is redirected to the Primary Domain Agent 242. At step 328, the Primary Domain Agent 242 receives the directed request, which includes the access control prompts. At step 330, the Primary Domain Agent 242 determines that the access control messages for its domain have been transmitted as part of the directed request.

Referring to FIGURE 4A, at step 410, the Primary Domain Agent 242 determines whether or not the required domain, as specified in ORIGINATING_SMDA, is a trusted domain. To make this determination, the Primary Domain Agent 242 may invoke an API function of the Multi-Domain Witness Server 208. If the Primary Domain Agent 242 determines that the required domain is not a trusted domain, then the execution of the steps ends. Otherwise, execution of the steps proceeds to step 414.

In step 414, the Primary Domain Agent 242 transmits copies of the access control prompts received in step 328 to the Multi-Domain Token Server 208.

In step 418, Multi-Domain Token Server 208 receives the tokens and caches them. They can be stored here for a configurable period of time.

In step 422, Multi-Domain Token Server 208 generates a Multi-Domain Token and transmits it to Primary Domain Agent 242. Multi-Domain Token can have a variety of data items. For example, you can include (1) data that identifies the copy of the whistles stored on Multi-Domain Witness Server 208 according to step 418 (“Whistle Set ID”), (2) the original URL of the originally requested resource , and (3) a key generation value based on the previous two items. A Multi-Domain Token is not limited to containing any particular set of data elements and other equivalent information may be used.

In step 424, the Primary Domain Agent 242 redirects the browser 210-1 to the Secondary Domain Agent 262, transmitting the Multi-Domain Token.

Referring to FIGURE 4B, in step 428, the Secondary Domain Agent 262 receives the directed request, including the Multi-Domain Token.

In step 432, to verify Multi-Domain Token, Secondary Domain Agent 262 transmits Multi-Domain Token to Multi-Domain Token Server 208.

In step 436, the Multi-Domain Token Server 208 determines whether or not the Multi-Domain Token is authentic, that is, whether it has been issued by a Multi-Domain Token Server 208 for an authentic user. The process of making this determination involves deciphering the witness. If the Multi-Domain Token is not authentic, then the execution of the steps ends. Otherwise, control flows to step 440.

At step 440, the previously stored access control flags, which are identified by Cookie_Set_Id, are transmitted to the Secondary Domain Agent. You no longer need to cache access control alerts. At step 444, Secondary Domain Agent 262 redirects browser 210-1 to the originally requested resource, transmitting access control flags to browser 210-1.

At step 448, browser 210-1 transmits the directed request, requesting the originally required resource. As a result of the browser receiving the access control alerts transmitted to it by the secondary domain agent 262 in step 444, the redirection request transmitted by the browser 210-1 includes the access control alerts. Consequently, browser 210-1 can access the originally required resource, assuming that the access control flags specify sufficient privileges.

ALTERNATIVE MULTI-DOMAIN ACCESS CONTROL

In step 414, the Primary Domain Agent 242 transmits copies of the access control alerts received in step 328 to the Multi-Domain Witness Server 208, which causes the Multi-Domain Witness Server 208 to store the access control prompts. Cached access until later required by a Secondary Domain Agent. Rather than transporting the access control whistles to the Secondary Domain Agent in this way, they can be transported through the Multi-Domain Token. Of course the Multi-Domain Token is limited in size, and it is not able to hold the amount of data that can be stored in the snooper and that may be needed for access control privileges.

After browser 210-1 receives access control prompts through Secondary Domain Agent 260, browser 210-1 may request a resource in another trusted domain. If the browser does not

ES 2 409 629 T3 is storing the access control messages for this domain, then no access control messages will be transmitted with the request to access the resource in the other trusted domain. Consequently, the steps shown in FIGURE 3a and FIGURE 4B are re-executed, and these steps can become a cycle that is repeated each time another trusted domain is accessed.

Repetition of the steps shown in FIGS. 3A-4B can be avoided by modifying the process depicted as follows. In step 444, rather than redirecting the browser to the originally required resource, the Secondary Domain Agent redirects the browser to another Secondary Domain Agent, transmitting the MultiDomain Token with the redirection request. After verifying the Multi-Domain Token, the other Secondary Domain Agent redirects the browser to yet another Secondary Domain Agent in another trusted domain, transmitting the access control prompts to the browser and the Multi-Domain Token to the browser. This process is repeated until the browser receives the access control alerts for all trusted domains, at which point the browser is redirected to the originally required resource.

For efficiency and fault handling purposes, it may be desirable to run replicas of Multi-Domain Witness Servers. The access control whistles could be replicated to each MultiDomain Witness Server replica. In this way, when a Multi-Domain Witness Server receives a request to store the access control tokens, it stores them and communicates them to the other replicas of the Multi-Domain Witness Server. Consequently, for the purposes of retrieving access control messages, a secondary Domain Agent may request a copy of a set of access control messages from any replica.

To avoid replicating access control alerts across all replicas of a Multi-Domain Witness Server, only one set of access control alerts for a user would be stored in a replica. Specifically, in response to a request to store copies of access control whistles, a Multi-Domain Witness Server replica generates a Multi-Domain Witness that includes a Replica Id that identifies the Multi-Domain Witness Server. A Secondary Domain Agent requires Multi-Domain Token Server access control tokens identified by a Multi-Domain Token.

If a replication fails, a Secondary Domain Agent redirects browsers that present a Multi-Domain Token that identifies the failed Multi-Domain Witness Server 208 to the Primary Domain Agent 242. This redirection may eventually lead to the generation and storage of another set of access control tokens on a functioning Multi-Domain Witness Server replica, and the generation of another Multi-Domain Witness that identifies the functioning Multi-Domain Witness Server. .

PHYSICAL COMPONENTS OVERVIEW

FIGURE 5 is a block diagram illustrating a computer system 500 upon which an embodiment of the invention may be implemented. The computer system 500 includes a main channel 502 or other communication mechanism for communicating information, and a processor 504 coupled with the main channel 502 for information processing. Computer system 500 also includes main memory 506, such as random access memory (RAM) or other dynamic storage device, coupled to main channel 502 to store information and instructions to be executed by processor 504. The memory Main 506 can also be used to store temporary variables or other intermediate information during the execution of instructions to be executed by processor 504. The computer system 500 further includes a read-only memory (ROM) 508 or other static storage device coupled to the main channel 502 to store static information and instructions for the processor 504. A storage device 510, such as a magnetic disk or disk optical, is provided and coupled to main channel 502 to store information and instructions.

Computer system 500 may be coupled via main channel 502 to a display 512, such as a cathode ray tube (CRT), to display information for a user of the computer. An input device 514, including alphanumeric and other keys, is coupled to main channel 502 to communicate information and command selections to processor 504. Another type of user input device is cursor control 516, such as a mouse, trackball, or cursor arrow keys to communicate direction information and command selections to processor 504 and to control movement of the cursor. cursor over display 512. This input device typically has two degrees of freedom on two axes, a first axis (eg x) and a second axis (eg y), which allows the device to specify positions in a plane.

The invention relates to the use of computer system 500 to implement the techniques described herein. According to one embodiment of the invention, those techniques are implemented by computer system 500 in response to processor 504 executing one or more sequences of one or more instructions contained in main memory 506. Such instructions can be read into main memory 506 from another computer-readable medium, such as storage device 510. Execution of the sequences of instructions contained in main memory 506 causes processor 504 to perform the process steps described in present memory. In alternative embodiments, hardwired circuits may be used in place of or in combination with software instructions to implement the invention. In this way, the realizations

ES 2 409 629 T3 of the invention are not limited to any specific combination of hardware and software circuits.

The term "computer-readable medium" as used herein refers to any medium that participates in providing instructions to processor 504 for execution. Such a medium can take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical or magnetic discs, such as storage device 510. Volatile media includes dynamic memory, such as main memory 506. Transmission media includes coaxial cables, copper wires, and optical fibers, including wires that comprise main channel 502. Transmission media can also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

Common forms of computer-readable media include, for example, a floppy disk, a floppy disk, a hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punched cards, paper tape, and any other physical media with hole patterns, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other integrated circuit or memory cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.

Various forms of computer-readable media may be involved in transporting one or more sequences of one or more instructions to processor 504 for execution. For example, the instructions can be carried out initially on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A local modem for the computer system 500 can receive the data on the telephone line and use the infrared transmitter to convert the data to an infrared signal. An infrared detector can receive the data carried in the infrared signal and suitable circuitry can place the data on main channel 502. Main channel 502 carries the data to main memory 506, from which processor 504 retrieves and executes the instructions. Instructions received by main memory 506 can optionally be stored in storage device 510 either before or after execution by processor 504.

The computer system 500 also includes a communication interface 518 coupled to the main channel 502. The communication interface 518 provides two-way data communication that is coupled to a network link 520 that is connected to a local network 522. For example , the communication interface 518 may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line. According to another example, the communication interface 518 may be a local area network (LAN) card to provide data communication connection to a compatible lAn. Wireless links can also be implemented. In any such implementation, communication interface 518 sends and receives electrical, electromagnetic, or optical signals that carry sequences of digital data representing various types of information.

Network link 520 typically provides data communication over one or more networks to other data devices. For example, the network link 520 may provide a connection through the local network 522 to a host computer 524 or to data equipment operated by an Internet Service Provider (ISP) 526. The ISP 526 in turn provides data communication services over the worldwide packet data communication network now commonly known as the "Internet" 528. The local 522 network and the Internet 528 both use electrical, electromagnetic, or optics that carry sequences of digital data. The signals over the various networks and the signals on the network link 520 and through the communication interface 518, which carries the digital data to and from the computer system 500, are exemplary forms of carrier waves that carry the information.

Computer system 500 can send messages and receive data, including program code, through network (s), network link 520, and communication interface 518. In the Internet example, a server 530 It could transmit a code required for an application program over the Internet 528, the ISP 526, the local network 522, and the communication interface 518. In accordance with the invention, such a downloaded application implements the techniques described herein.

The received code can be executed by processor 504 as received, and / or stored in storage device 510, or other non-volatile storage for later execution. In this way, the computer system 500 can obtain an application code in the form of a carrier wave.

In the above-mentioned specification, the invention has been described with reference to specific embodiments thereof.