WO2003060704A2

WO2003060704A2 - System and method for program configuration

Info

Publication number: WO2003060704A2
Application number: PCT/US2003/001160
Authority: WO
Inventors: Jeremy S. De Bonet
Original assignee: Idetic, Inc.
Priority date: 2002-01-15
Filing date: 2003-01-15
Publication date: 2003-07-24
Also published as: WO2003060704A3; AU2003207561A8; AU2003207561A1

Abstract

Embodiments of the present invention provide systems and methods for configuring programs substantially reduce or eliminate the disadvantages associated with previously-developed configuration systems and methods. More particularly, embodiments of the present invention provide a system and method for establishing the configuration parameters for a program through a multiple transaction conversation with configuration sources. The conversation can be directed, at least in part, by external logic at the configuration sources and can include a series of requests for configuration parameters and replies containing those parameters. The responses from configuration sources can also include additional request information that can be used by the program being configured to make additional requests for configuration parameters, thereby extending the conversation.

Description

DESCRIFΠON SYSTEM AND METHOD FOR PROGRAM CONFIGURATION

RELATED APPLICATIONS The present application claims priority under 35 U.S. C. § 119 to United States Provisional

Patent Application Serial No. 60/348,559, entitled "Dynamic Platform Configuration Via Multiple Transactions with External Logic Control," by Jeremy S. de Bonet, filed January 15, 2002, United States Provisional Patent Application No. 60/349,424, entitled "Network Proxy Platform that Simultaneously Supports Data Transformation, Storage, and Manipulation for Multiple Protocols" by de Bonet et al., filed on January 18, 2002, United States Provisional Patent Application No.

60/349,344 entitled "Modular Plug-In Transaction Processing Architecture" by de Bonet et al., filed January 18, 2002, which are hereby fully incorporated by reference herein. Additionally, United

States Patent Application Serial No. , entitled "Method and System of Performing

Transactions Using Shared Resources and Different Applications," by de Bonet et al., filed January 14, 2003 is incorporated by reference herein.

REFERENCE TO APPENDIX

An appendix is included in this application by way of attachment, the totality of which is hereby incorporated by reference for all purposes as an integral part of this application. The appendix is entitled "Network Proxy Platform and Its Use" and includes 17 pages of text and 8 sheets of drawings.

TECHNICAL FIELD

The present invention relates generally to systems and methods of program configuration. More particularly, embodiments of the present invention relate to systems and methods of establishing a set of configuration parameters for a program via multiple transactions.

BACKGROUND OF THE INVENTION

A program is essentially a set of instructions that are executable by a computer processor to perform a task. Without any input, the computer processor will typically run the program the same way every time. To increase flexibility, many current software programs allow a variety of settings to be specified when the program is started in order to allow the program to perform differently. An example of such a setting is the default font used by an instance Microsoft®Word (Microsoft is a trademark of Microsoft Corporation, based in Redmond, Washington) that determines the style of characters displayed and printed by Microsoft® Word. When an instance of Microsoft®Word is started, it will retrieve a set of configuration parameters from a configuration source that includes a font parameter. The font parameter will determine the starting font for the instance of Microsoft® Word. If a user wishes to change the font, he or she may be given the option to do so through a user setting, but, unless the font parameter is changed at the configuration source, Microsoft® Word will revert to the initial font each time a new instance is started. In many current software and hardware systems, a single configuration source or repository is utilized to store configuration parameters. At startup, a program will load the information necessary to query the configuration source and will send a request to the configuration source to get the configuration parameters that dictate the program's run-time characteristics. The configuration source, in an enterprise system, will typically be located on an entity's LAN at a server or database remote from user machines. In other systems, the configuration parameters will be stored locally in a file or command line. The configuration parameters stored in the file, database, server or command line can determine how a program receives inputs, processes data and displays outputs.

Prior art systems of configuring software programs that rely on a single configuration repository tend to be static and do not typically allow the configuration information for a program to change based on a system state. In other words, prior art systems do not allow the settings uploaded by a program to change depending on, for example, the time of day, CPU load or other such factors. Thus, for example, the default font for instances of Microsoft®Word running on an entity's LAN will not change based on time day. In order to change the font, each user will have to change the font through his or her individual user settings. Thus, prior art systems suffer a limitation in that they do not typically allow configuration parameters to change based on system state or be stored across multiple systems. Additionally, because configuration information is stored at a single source, all configuration information must be maintained at that source, often requiring extensive reprogramming. Therefore it is often difficult to integrate existing sources of potential configuration information into new software systems.

SUMMARY OF THE INVENTION

Embodiments of the present invention provide systems and methods for configuring programs that substantially reduce or eliminate the disadvantages associated with previously-developed configuration systems and methods. More particularly, embodiments of the present invention provide a system and method for establishing the configuration parameters for a program through a multiple transaction conversation with configuration sources. The conversation can be directed, at least in part, by external logic at the configuration sources and can include a series of requests for configuration parameters and replies containing those parameters. The responses from configuration sources can also include additional request information that can be used by the program being configured to make additional requests for configuration parameters, thereby extending the conversation. One embodiment of the present invention can include a system for establishing a set of configuration parameters comprising a software program stored on a computer readable memory and executable by a computer processor to: (i) send a first request over a network to a first configuration source; (ii) receive a first response over the network, wherein said first response includes a first portion of the set of configuration parameters; (iii) send a second request over the network to a second configuration source; and (iv) receive a second response over the network, wherein the second response includes a second portion of the set of configuration parameters.

In one embodiment of the present invention, responses generated by a configuration source can include a set of additional request information. The program receiving the response can be executable to generate an additional request based on the additional request information of a previous response. Thus, for example, the second request can be based on the additional request information contained in a previous response. Each additional request can optionally include one or more parameters received in the earlier response. In this manner, values received from one configuration source can be shared with other configuration sources when the additional request is made. In one embodiment of the present invention, each response generated by a configuration program can be based on a received request. The response can be the same regardless of the request, can be the result of an attribute of the request, such as the originating IP address of the request or request parameters (e.g. user name, time, CPU load or other parameter as would be understood by those of ordinary skill in the art) or can be the result of internal logic such as determining the time at the configuration source. In other words, the response may be the same regardless of the request or may vary depending on the content of the request or system state.

Another embodiment of the present invention can include a method for configuring a program, comprising: (i) sending a first request over a network to a first configuration source; (ii) receiving a first response over the network, wherein said first response includes a first portion of the set of configuration parameters; (iii) sending a second request over the network to a second configuration source; and (iv) receiving a second response over the network, wherein said second response includes a second portion of the set of configuration parameters.

Embodiments of the present invention provide an advantage over previously developed configuration systems by allowing multiple configuration sources to be accessed. This can be advantageous particularly in systems in which different people have control over particular settings. For example, if a user has control over visual preferences in a program while a system administrator has control over the types of file the program can open, parameters controlling visual settings can be stored at one configuration source while parameters controlling file types can be stored at another configuration source. As another example, in systems with multiple users, configuration information related to different groups of users can be stored in different places. Embodiments of the present invention provide another advantage by allowing configuration parameters to change depending on information provided by the program being configured or system state information. This can allow a large number of different combinations of configuration parameters to be defined depending on various conditions.

Embodiments of the present invention provide yet another advantage by allowing one configuration source to direct the program being configured to another configuration source. This can allow changes to configuration information to be implemented through changes at the configuration sources, reducing or eliminating reprogramming at user machines. Additionally, this can aid in easily integrating new or legacy data repositories as configuration sources.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the present invention and the advantages thereof may be acquired by referring to the following description, taken in conjunction with the accompanying drawings in which like reference numbers indicate like features and wherein: FIGURE 1 is a diagrammatic representation of a system for establishing a set of configuration parameters according to one embodiment of the present invention;

FIGURE 2 is a diagrammatic representation of a software architecture for establishing a set of configuration parameters according to one embodiment of the present invention;

FIGURE 3 is a flow chart illustrating one embodiment of a method for establishing a set of configuration parameters; and

FIGURE 4 is a diagrammatic representation of another software architecture for establishing a set of configuration parameters at a proxy program according to one embodiment of the present invention.

DETAILED DESCRIPTION

Preferred embodiments of the present invention are illustrated in the figures, like numerals being used to refer to like and corresponding parts of the various drawings. Embodiments of the present invention provide systems and methods for establishing the configuration parameters for a program through a multi-transaction "conversation" over a network that dissociates the program from the configuration sources storing the configuration parameters. The conversation can be directed, at least in part, by external logic at the configuration sources and can include a series of requests for configuration parameters and replies containing those parameters. In the preferred embodiment, the conversation can take place using HyperText Transfer Protocol (HTTP), however, any number of communications protocols known (or developed) in the art can be used (e.g. raw TCP/EP, FTP, UDP, HTTPS, Gopher, news, POP, SMTP, SNMP, etc.). A set of initial configuration parameters can specify an initial request or series of requests to be made by the program. A configuration source can generate an initial response or reply to the request that optionally specifies any number of configuration parameters (e.g. name-value pairs) that the program uses to determine its run-time behavior, hi addition, the initial response or reply can include additional request information specifying new requests to be made by the program. The new requests can be inserted into a list of requests that potentially contains additional requests specified by the initial configuration parameters. The program can continue the conversation by making the additional requests (and any other requests specified in response to the additional requests) and incorporating the configuration parameters received. Each request after the initial request can, in the request itself, include values associated with previously specified parameters. In this manner, parameter values from one configuration source can be included in a request to another configuration source. When the conversation has been completed, the program can use the set of configuration parameters received from the configuration sources to adjust, modify or alter its functionality. FIGURE 1 is a diagrammatic representation of a system 100 for establishing a set of configuration parameters for a software program according to one embodiment of the present invention. System 100 can include a network 105 connecting a first computer 110 and a plurality of configuration sources, (here, indicated as configuration source 120, configuration source 130, configuration source 140, configuration source 150 and configuration source 160). A configuration source can include any system accessible to provide configuration parameters or additional request information, as described below. Network 105 can be a WAN, LAN, global computer network (e.g. Internet, wireless network, fiber optic network) or any other communications network known in the art. First computer 110 can contain a network communications device 111 (e.g. Ethernet card, modem or other communication device known in the art), a CPU 112 and a computer readable ^■ memory 114 (e.g. RAM, ROM, magnetic storage, optical storage device and/or any other computer readable memory known in the art) storing a program 115 that is executable by CPU 112. Program 115 can be a portion of larger program, such as an application, and may be implemented in any suitable programming structure (e.g. plug-in, function, stand alone program) or language known to those of ordinary skill in the art. Each configuration source can include a network communications device (shown as network communications device 121, network communications device 131 . . . network communications device 161) that can be an any network communications device known in the art. Each configuration source can also include a CPU (shown as CPU 122, CPU 132, CPU 142, CPU 152 and CPU 162) and a computer readable memory (shown as computer readable memory 124, computer readable memory 134 . . . computer readable memory 164) that can comprise RAM, ROM, magnetic storage mediums, optical storage mediums and/or other computer readable memories known in the art and can include a configuration source program (shown as configuration program 125, configuration program 135 . . . configuration program 165). Each configuration program can be a portion of larger program, such as an application, and may be implemented in any suitable programming structure (e.g. plug-in, function, stand alone program) or language known to those of ordinary skill in the art. While first computer 110 and each of the configuration sources 130-160 has been shown as a single physical computer, it should be noted that the functionality of each can be distributed. Moreover, multiple configuration programs can be stored on the same physical machine. Thus, a single computer can comprise multiple configuration sources.

In operation, program 115 can make multiple requests to one or more of the configuration sources via network 105 requesting a set of configuration parameters. The reply from each configuration source can potentially contain: (i) at least a portion of the configuration parameters needed by program 115; and or (ii) information necessary to make additional requests to other configuration sources. Through the initial request and additional requests (specified by the initial parameters or by responses to requests), program 115 can establish a set of configuration parameters through a multi-transaction conversation with the configuration sources.

Program 115 can initiate a conversation at the occurrence of any predefined event (e.g. startup, receipt of a request from another computer) or according to a schedule. To initiate the conversation, program 115, in one embodiment of the present invention, can load a set of initial parameters. The initial parameters can specify an initial load list comprising a list of configuration sources that are to be queried for additional configuration information. Whether the configuration information is located on the same physical machine as program 115 (potentially held by another application) or on remote machines, the requests for configuration information can be made over a network connection.

Program 115 can make an initial request based on the set of initial parameters to an initial configuration source. Based on the initial request, the initial configuration source can send back a reply including a set of configuration parameters and/or additional request information. As an example, if configuration source 120 is the initial configuration source, configuration source 120 can format a reply to the initial request that includes configuration parameters and additional request information directing program 115 to query configuration source 130. Based on the initial response, program 115 can then send a request to configuration source 130 for additional configuration parameters. Configuration source 130 can, in turn, send a reply containing additional configuration parameters and/or additional request information directing program 115 to query, for example, configuration source 140 for configuration parameters. In this manner, program 115 can query multiple configuration sources to recursively establish a set of configuration parameters that it can use to determine, adjust or modify its run-time characteristics. FIGURE 2 is a diagrammatic representation of a software system 200 according to one embodiment of the present invention. In system 200, program 115 can query any number of a plurality of configuration programs (here, designated configuration program 125, configuration program 135, configuration program 145, configuration program 155, configuration program 165 and configuration program 204), typically hosted remotely from program 115. Program 115 can initially begin with a limited set initial parameters 205 that can specify a load list 215 that includes a list of configuration sources (potentially running on different computers) that are to be queried for additional configuration parameters. Initial parameters 205 and load list 215 can be stored in a database, a file or any other format known in the art. In operation, program 115 can make an initial request for configuration information to configuration source 120 that can be processed by configuration program 125. The initial request can be a simple request (e.g. an HTTP request such as www.enity.com/configuratonsourcel .htm) or can optionally include request parameters such as a set of system state information (e.g. CPU usage at first computer 110) or user information associated with first computer 110. As an example, if first computer 110 is associated with a user "Paul," the initial configuration parameters can specify that the initial request include a request parameter "user=paul." If the request is made as an HTTP request, the user name "Paul" can, for example, be included as part of a common gateway interface ("CGI") request (e.g. www.entity.com/configurationsourcel/User?user=paul). It should be noted that HTTP and CGI are provided by way of example only, and the present invention can make requests according to a variety of protocols and interfaces known to those of ordinary skill in the art or later developed. It should be further noted that multiple interfaces (e.g. CGI) running on the same computer can comprise different configuration sources.

Based on the user name "Paul" in the initial request, configuration program 125 can determine that Paul uses a PDA and that Paul is in a specific user group (e.g. the bronze user group). Configuration program 125 can then format a response including, for example, a set of configuration parameters associated with each user that accesses configuration program 125 (i.e. global settings), a set of configuration settings associated with the user Paul (preferred settings, for example) and/or additional request information. The additional request information can specify, for example, that program 115 query configuration source 130 for configuration parameters relating to a specific user device (e.g. PDA) and query configuration source 140 for configuration parameters relating to a particular user group (e.g. bronze). Upon receipt of the initial response, program 115 can store any received configuration parameters as part of set of configuration parameters 220 and add the additional requests to load list 215.

Continuing with the previous example, program 1 15 can then make a request to configuration program 135 based on the reply from configuration program 125 that includes information received from configuration program 125 in the request. Thus, for example, program 115 can send a request that has a request parameter indicating the user device is a PDA (e.g. www.entity.com/configurationsource2 /Device?device=PDA). In this manner, additional request parameters received from configuration program 125 (e.g. "PDA") can be shared with configuration program 135. Configuration program 135, can process the request and return a reply that contains additional request information and/or a set of configuration parameters. Program 115 can add additional request(s) to load list 215 and the configuration parameters to the set of configuration parameters 220. While the example request above incorporates request parameters from a previous single reply (e.g. "PDA" from configuration program 125's response), a request can be based on multiple previous responses. For example, program 115 can send a request www.entity.com/ configsource/Preferences?device= PDA&group=bronze to a configuration source, even if the device and group parameters came from different previous replies.

In addition to making a request to configuration program 135, program 115 can make a request to configuration program 145 based on the reply received from configuration program 125. Again, program 115 can formulate a request optionally containing additional request parameters received from configuration program 125 (e.g. www.entity.com/configurationsource2/

Subscription?group=bronze) and or other configuration programs. Configuration program 145 can receive the request and generate a response containing configuration parameters and/or additional request information, which program 115 can add to set of configuration parameters 220 and load list 215, respectively. As can be understood from the foregoing, the response generated by each configuration program can be based on the request received from program 115. The response from a particular configuration program (i.e. the configuration parameters and/or additional request information returned in reply to a request) can be the same regardless of the request (i.e. can return a base set of configuration parameters applicable to each requesting program), can be the result of an attribute of the request, such as the originating IP address of the request or parameters stored in the request (e.g. user name, time, CPU load or other parameter as would be understood by those of ordinary skill in the art) or can be the result of internal logic such as determining the time at the configuration source. Additionally, a particular configuration source can query additional configuration sources in formulating a response to a request from program 115. Thus, as shown in FIGURE 2, configuration program 145 can query configuration program 165 to generate a reply to a request. If, for example, configuration program 165 is part of a network system that monitors bandwidth usage, and the configuration parameters associated with the "bronze" user group are dependent on the available bandwidth, configuration program 135 can query configuration program 165 prior to responding to the example request www.entity.com/configurationsource2/Subscription?group=bronze. Configuration program 165 can further query other resources, such as configuration program 204 prior to responding to configuration program 135. Each response to program 115 can optionally include a set of special parameters that contain cache directives for the configuration parameters included in the response (or in the entire conversation). By way of example, a response from a configuration source can contain directives such as "Valid Since First Used 1000 Seconds" and "Valid Since Last Used 500 Seconds" so that configuration parameters in that response will only be cached for 1000 seconds from their first use or 500 seconds from their last use by program 115. In this manner, a configuration source can dictate how long configuration parameters should be cached. In another embodiment of the present invention, the cache directives can apply to all configuration parameters received in a particular conversation, not just a particular response.

In addition each response can include additional request information that specifies one or more additional configuration requests. Program 115 can make the additional configuration requests and incorporate any received configuration parameters into the set of configuration parameters 220. Depending on the order in which program 115 sends out the additional requests, a particular additional request, while potentially based on a previous reply from a configuration source, may not necessarily be based on the immediately proceeding reply. In other words, there can be a number of intermediate requests between a particular additional request and the previous reply on which it is based, depending on the implementation.

Each additional request can, in the request itself, include parameter values that have been previously specified, either in the initial parameters or by one or more previously queried configuration sources. In this way, parameter values from one configuration source, such as the "PDA" value from configuration program 125, can be shared with other configuration sources, such as configuration program 135, when program 115 makes a request. When the "conversation" between program 115 and the configuration sources is complete, a set of configuration parameters 220 has been established that can dictate the operation of program 115 (or other program operable to receive the configuration parameters from program 115) as it performs its other duties.

Embodiments of the present invention, therefore, provide a system for establishing a set of configuration parameters through a multiple transaction conversation. Program 115, in one embodiment of the present invention, can be executable by CPU 112 to send a first request over a network to a first configuration source. The first request can be an initial request dictated by a set of initial parameters or can be based on a previous request. Program 115 can be further executable to receive a first response over the network that contains a portion of the set of configuration parameters and to send a second request to a second configuration source over the network. The second request can be based on a previous response to a previous request. For example, the second request can be based on the response from the first configuration source, on an intermediate response from another configuration source or on several previous responses. The second response can contain a second portion of the set of configuration parameters.

In one embodiment of the present invention, the first response and/or second response can include a set of additional request information. Program 115 can be executable to generate an additional request based on the additional request information of the first response. Thus, for example, the second request can be based on the additional request information contained in the first response. The additional request can optionally include one or more parameters received in the earlier response. In this manner, values received from one configuration source can be shared with other configuration sources when the additional request is made. In another embodiment of the present invention, load list 215 can define each of the requests to be made by program 115. For example, load list 215 can contain the following requests: http://www.yoursource.com/UserInfo?user==User_ID http://www.yoursource.com/ClassInfo?class=CLASS http://www.yoursource.com/DeviceInfo?device=DEVICE In this case, program 115 can determine the User ID and Device from, for example, initial parameters 205, whereas, the value for the "class" parameter can be defined in a response from the "Userlnfo" CGI (e.g. in the additional request information received in response to a request). In another embodiment, the "class" parameter can also be determined by program 115 by initial parameters 205. It should be noted, in this example, each CGI hosted at http://www.yoursource.com can represent a different configuration source.

Because the responses can vary depending on different conditions and system states, embodiments of the present invention can establish various sets of configuration parameters based on the different conditions. Thus, set of configuration parameters 220 can define very specific configuration information for program 115 under one set of conditions to very general configuration information under another set of conditions.

FIGURE 3 illustrates a flow chart for implementing a method for establishing the configuration parameters for a program according to one embodiment of the present invention. At step 305, program 115 can load a set of initial parameters stored, for example, in a file or database. The initial parameters can specify an initial load list containing one or more requests to configuration sources. At step 310, program 115 can initiate a conversation with the configuration sources by sending the initial request in load list 215 to the corresponding configuration source. In one embodiment of the present invention, the initial request is sent according to HTTP, though other protocols known (or developed) in the art may be used (e.g. TCP/IP, FTP, UDP, HTTPS, Gopher, news, POP, SMTP, SNMP). The initial request can optionally contain one or more parameters specified by the initial parameters, such as a user name. Upon receiving the initial request, the configuration source can generate a reply (step 315). If each program requesting information from the configuration source requires the same configuration information, the configuration source can return a stock reply containing the same information. Alternatively, the configuration source can base the reply on information contained in the request, such as the address from which the request originated or a parameter value contained in the request. Thus, for example, the configuration source may generate a different response to the request www.entity.com/configurationsourcel/User?user=steve than the request www.entity.com/configurationsourcel/ User?user=john.

The configuration source can also base the response on other information, such as a system state. For example, the configuration source can base the response on the time of day, bandwidth usage of a network, amount of memory being used or other factors. The configuration source can derive this information itself or can query another resource (potentially remote from the configuration source) to receive this information.

The response generated by the configuration source can contain a set of configuration parameters, a set of additional request information and/or a set of special parameters. The configuration parameters can be usable by program 115 (or a program that can access the configuration parameters from program 115) to adjust or modify its behavior. The additional request information can be used by program 115 to send new or additional requests to other configuration sources and can include additional request parameters to be sent with an additional request. Alternatively, the additional request information may only include additional request parameters (or values) that are to be sent with requests already defined in load list 215 (e.g. from other previous responses or initial parameters 205). Referring to the example above, if the user "john" is a member of the "gold" group, and the configuration parameters relating to specific users are contained a separate configuration source than configuration parameters relating to groups, a configuration source receiving the request www.entity.com/configurationsource l User?user=john, can send a response including a set of configuration parameters and a set of additional request information such that program 115 can make the request www.entity.com/confϊgurationsource2/Subscriptιon?group=gold. In this manner, one configuration source can indicate to program 115 additional configuration sources to be queried and share parameters with those additional configuration sources. Program 115 can receive the response (step 320) and determine if the response contains one or more configuration parameters (step 325). If the response does contain configuration parameters, program 115 can add the configuration parameters to set of configuration parameters 220 (step 330). Otherwise, program 1 15 can move to step 335. At step 335, program 115 can determine if the response contains additional request information specifying one or more additional requests. The additional request information can include any information necessary for program 115 to make an additional request to a configuration source and can include parameters to be passed to other configuration sources in one or more of the additional requests. If additional request information is included in a response from a configuration source, the additional requests can be added to load list 215 (step 340). If, on the other hand, additional request information is not included in a response, control can pass to step 345. Program 115, at step 345, can determine if load list 215 contains any additional requests. If so, program 115 can then send out additional requests in load list 215 (e.g. can return to step 310 by sending out an additional request). The response to each additional request may include configuration parameters that program 115 can add to set of configuration parameters 220 and further additional requests that program 115 can add to load list 215, extending program 115's conversation. Each additional request can include values associated with any parameters that have been previously specified by, for example, previous responses to requests.

When the conversation is complete, program 115 can use set of configuration parameters 220 to adjust, modify or alter its functionality. Alternatively, program 115 can begin using parameters in set of configuration parameters 220 before the conversation is complete, with the conversation dynamically updating set of configuration parameters 220. It should be noted, the process shown in FIGURE 3 is by way of example only and embodiments of the present invention can include additional steps and, as would be understood by those of ordinary skill in the art, the steps can be performed in a different order.

Program 115 can, thus, generate a first request, which can be based on a set of initial configuration parameters or a previous request, and receive a first response containing a portion of the configuration parameters. Additionally, program 115 can generate a second request based on a previous response (e.g. the first response or an intermediate response) to a previous request. The second response can also contain a portion of the configuration parameters. In one embodiment of the present invention, the second request can be based on a set of additional request information received in a previous response and can include request parameters specified in the previous response. Embodiments of the present invention provide a system and method for establishing the configuration parameters for a program through a multi-transaction "conversation" over a network that dissociates the program from the configuration sources storing the configuration parameters. The • conversation can be directed, at least in part, by external logic at the configuration sources and can include a series of requests for configuration parameters and replies containing those parameters. Because the response provided by a configuration source can vary depending on a system state or request parameters, different instances of a program running on a network can receive different configuration parameters at, for example, different times day or according to the network user. This allows embodiments of the present invention to provide a much more flexible set of configurations parameters than traditional single repository models. Moreover, because the conversation between the program and configuration sources can be arbitrarily extended, new configuration sources can be easily added to a system with minimal or no changes to existing configuration sources. This can allow legacy sources to be utilized without having to port the data in the legacy source to the single configuration repository. For example, if a network operator already has a database of subscriber levels (e.g. gold, silver, bronze), other configuration sources can be modified to include additional request information that directs program 1 15 to request subscriber information from the subscription database. The subscription database can be provided with a CGI interface (or other interface known or developed in the art) such that program 115 can make a request to the subscription database for subscriber information. Implementing the CGI interface (or other interface known in the art) and modifying one or more other configuration sources can, in some cases, be easier than moving the data from the subscription database to another configuration resource. Program 115, in one embodiment of the present invention, can then make a request (e.g. based on a previous response from another configuration source) to the subscription database and receive subscriber information (e.g. subscription level) in the response. This information can be passed to other configuration sources as one or more request parameters and the other configuration sources can generate responses based on the subscriber information. In this manner, the existing subscription database can be quickly integrated as a configuration source.

FIGURE 4 is a diagrammatic representation of another software system 400 according to one embodiment of the present invention. In system 400, program 115 can be implemented as a proxy between client applications (here, indicated as client application 405 and client application 410) and network resources (here indicated as network resource 415 and network resource 420). In one embodiment of the present invention client application 405 and client application 410 can be Internet browsers located on a corporate LAN and network resource 415 and network resource 420 can be web servers located on the Internet. Program 115 can intercept requests from the client applications to the network resources to see if it can fulfill the requests itself from a set of cached web pages. By caching commonly accessed web pages, program 115 can increase the performance of system 400. When a client application request (e.g. a request for www.idetic.com) is received from client application 405 or client application 410, program 115 can initiate a conversation with one or more configuration programs (here, designated configuration program 125, configuration program 135, configuration program 145, configuration program 155, configuration program 165 and configuration program 204) to gather set of configuration parameters 220. Program 115 can make an initial request to a configuration program (e.g. configuration program 125) based on initial configuration parameters 205 and/or the client application request.

Based on the initial request, configuration program 125 can send back a response that includes configuration parameters, additional request information and/or special parameters. Program 115 can add any configuration parameters received to set of configuration parameters 220 and add any additional requests to load list 215. Program 115 can continue the conversation with other configuration programs by making additional requests from load list 215. Through the conversation program 115 can establish set of configuration parameters 220, as described in conjunction with FIGURE 1, FIGURE 2 and FIGURE 3. Program 115 can use set of configuration parameters 220 to determine how to handle the client application request (e.g. www.idetic.com).

Each time a new client application request is received, program 115 can initiate a new conversation to establish set of configuration parameters 220 that dictate how that client application request should be handled. Alternatively, program 115 can cache configuration parameters based, for example, on special parameters received from a configuration source. Thus, if program 115 receives a second client application request for www.idetic.com, program 115 can use the cached parameters rather than initiating a new conversation. The special parameters received from the configuration sources can be used to determine how long particular configuration parameters should be cached. While program 115 is described in terms of a web proxy server, it should be understood that program 115 can be implemented in any proxy known in the art. Moreover, the configuration sources can be located on either side of the proxy with respect to the client applications. In other words, the configuration sources can be located on the Internet and/or the corporate LAN.

Although the present invention has been described in detail herein with reference to the illustrative embodiments, it should be understood that the description is by way of example only and is not to be construed in a limiting sense. It is to be further understood, therefore, that numerous changes in the details of the embodiments of this invention and additional embodiments of this invention will be apparent to, and may be made by, persons of ordinary skill in the art having reference to this description. It is contemplated that all such changes and additional embodiments are within the spirit and true scope of this invention as claimed below.

APPENDD NETWORK PROXY PLATFORM AND ITS USE Reference is made in detail to exemplary embodiments of the network proxy platform and its use, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts (elements). A method and system can comprise a software architecture that allows different applications in the same or different communications protocols to interact with shared resources within a computer. More specifically, code for a computer program may be written to increase the amount of code that is generic to (i.e., shared by) more than one application or communications protocol and reduce the amount of code that handle application-specific or protocol-specific actions. In one embodiment, a transaction may be broken down into a set of discrete actions. The discrete actions may include functions that are common to more than one network application. These functions may be performed by the shared resources.

For each action, code that is specific to a particular protocol or application may be written as part of a software plug-in module with function calls to functions of the shared resources. Each software plug-in module may substantially act similar to a manager for the action, where common tasks are delegated to the shared resources and the module performs specialized functions. Each protocol may have its own set of software plug-in modules for the discrete actions. New applications and support for new protocols can be added by developing a new set of plug-in modules instead of writing an entirely new program. New applications for the same protocol may be developed by replacing or editing as little as one plug-in module from a different application in the same protocol. The software architecture can reduce development time, increase the likelihood that new applications may be developed quickly with fewer changes from an existing application, more protocols will be properly supported, and reduce the burden on hardware and software resources. A few terms are defined or clarified to aid in understanding the descriptions that follow. A network includes an interconnected set of server and client computers over a publicly available medium (e.g., the Internet) or over an internal (company-owned) system. A user at a client computer may gain access to the network using a network access provider. An Internet Service Provider ("ISP") is a common type of network access provider. As used herein, the terms "comprises," "comprising," "includes," "including," "has," "having" or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a method, process, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such method, process, article, or apparatus. Further, unless expressly stated to the contrary, "or" refers to an inclusive or and not to an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present).

The term "software component" is intended to mean at least a portion of a computer program (i.e., a software application). An example includes a software plug-in module or the like. Different software components may reside in the same computer program or in different computer programs on the same computer or different computers.

Before discussing embodiments of the network proxy platform, an exemplary hardware architecture for using network proxy platform is described. FIG. 1 illustrates such an exemplary hardware architecture and includes client computer 120, proxy computer 140, and server computer 160. Client computer 120 and proxy computer 140 are bi-directionally coupled to network 11, and proxy computer 140 and server computer 160 are bi-directionally coupled to network 13. Each of networks 11 and 13 may be an internal network or an external network (e.g., the Internet). In one embodiment, networks 11 and 13 may be the same network, such as the Internet. Computers 140 and 160 may be bi-directionally coupled to databases 14 and 16, respectively. Client computer 120 can include a desktop computer, a laptop computer, a personal digital assistant, a cellular phone, or nearly other device capable of communicating over network 11. Other client computers (not shown) may also be bi-directionally coupled to network 11. The proxy computer 140 can be a server computer, but in another embodiment may be a client computer. Other server computers (not shown) similar to server computer 160 may be bi-directionally coupled to network 13.

In an alternative embodiment, each of proxy computer 140 and server computer 160 may be replaced by a plurality of computers (not shown) that may be interconnected to each other over a network or a combination of networks. For simplicity, a single system is shown for each of proxy computer 140 and server computer 160. The client computer 120 can include central processing unit ("CPU") 122, read-only memory

("ROM") 124, random access memory ("RAM") 126, hard drive ("HD") or storage memory 128, and input/output device(s) ("I/O") 129. I/O 129 can include a keyboard, monitor, printer, electronic pointing device (e.g., mouse, trackball, stylus, etc.), or the like. Proxy computer 140 can include CPU 142, ROM 144, RAM 146, HD 148, and I/O 149, and server computer 160 can include CPU 162, ROM 164, RAM 166, HD 168, and I/O 169.

Each of the computers in FIG. 1 may have more than one CPU, ROM, RAM, HD, I/O, or other hardware components. For simplicity, each computer is illustrated as having one of each of the hardware components, even if more than one is used. Note that FIG. 1 is a simplification of an exemplary hardware configuration. Many other alternative hardware configurations are possible and known to skilled artisans. Each of computers 120, 140, and 160 is an example of a data processing system. ROM 124, 144, and 164; RAM 126, 146, and 166; HD 128, 148, and 168; and databases 14 and 16 can include media that can be read by CPU 122, 142, or 162. Therefore, each of these types of memories includes a data processing system readable medium. These memories may be internal or external to computers 120, 140, or 160.

Portions of the methods described herein may be implemented in suitable software code that may reside within ROM 124, 144, or 164, RAM 126, 146, or 166, or HD 128, 148, or 168. The instructions in an embodiment may be contained on a data storage device, such as HD 148. FIG. 2 illustrates a combination of software code elements 204, 206, and 208 that are embodied within a data processing system readable medium 202, on HD 148. Alternatively, the instructions may be stored as software code elements on a DASD array, magnetic tape, floppy diskette, optical storage device, or other appropriate data processing system readable medium or storage device.

In an illustrative embodiment, the computer-executable instructions may be lines of compiled assembly, C, C^**, Java, or other language code. Other architectures may be used. For example, the functions of any one of the computers may be performed by a different computer shown in FIG. 1. Additionally, a computer program or its software components with such code may be embodied in more than one data processing system readable medium in more than one computer.

In the hardware configuration above, the various software components may reside on a single computer or on any combination of separate computers. In alternative embodiments, some or all of the software components may reside on the same computer. For example, one or more the software components) of the proxy computer 140 could reside on the client computer 120, the server computer 160, or both. In still another embodiment, the proxy computer 140 and database 14 may not be required if the functions performed by the proxy computer 140 are merged into client computer 120 or server computer 160. In such an embodiment, the client computer 120 and server computer 160 may be bi-directionally coupled to the same network (not shown in FIG. 1).

Communications between any of the computers in FIG. 1 can be accomplished using electronic, optical, radio-frequency, or other signals. For example, when a user is at client computer 120, client computer 120 may convert the signals to a human understandable form when sending a communication to the user and may convert input from a human to appropriate electronic, optical, radio-frequency, or other signals to be used by, computers 140 or 160. Similarly, when an operator is at server computer 160, server computer 160 may convert the signals to a human understandable form when sending a communication to the operator and may convert input from a human to appropriate electronic, optical, radio-frequency, or other signals to be used by computers 120, 140, or 160.

Attention is now directed to the methodology of developing a software architecture for the software in accordance with one embodiment. The method can comprise breaking down a transaction into a set of discrete actions. The actual definitions used for separating the transaction into the discrete actions is variable and may be selected by skilled artisans in manners that best suit their particular transactions, hardware requirements, and software requirements. The method can also include determining which functions within the set of discrete actions are common to more than one application. As more are identified, the number of shared resources can increase and the amount of application-specific code can be decreased. Therefore, skilled artisans are encouraged to examine the software from many different levels of abstraction to discover potential shared resources that may otherwise be missed.

The method can further comprise generating software components for the discrete actions. A set of software plug-in modules can correspond to the different discrete actions for the transaction. Each application may have its own set of software plug-in modules. The amount of code within each software plug-in module should be kept relatively low if the identification of shared resources was performed properly. To the extent code for any shared resources does not currently exist, code for the shared resources should be generated to maximize its ability to be used by as many different plug-in modules as possible. At least two of the software plug-in modules for different applications, whether they use the same or different protocols, can make function calls to any one or more of the shared resources. For different applications using the same protocol, only a request manipulation plug-in module, a content manipulation plug-in module, or both may be the only modules changed. Therefore, creating new application for the same protocol may be simplified because other plug-in modules used for the application may be copied from another application using the same protocol. These other plug-in modules may be substantially the same between the applications. By replacing or editing the request manipulation plug-in module, content manipulation plug-in module, or both, new applications may be developed very quickly.

Regarding applications in different protocols, each protocol may have a module that performs substantially the same action as any or all of the similar module(s) for the other protocol(s) though reducing this duplicative code by combining the common functionality is preferable.

Attention is now directed to the software architecture of the software in accordance with one embodiment. The software architecture is illustrated in FIGs. 3 and 4 and is directed towards an electronic transaction that can be performed over a network. A basic idea behind the architecture is to allow programming code for shared resources to be commonly used by as many different network applications as possible. Note that all of the resources may or may not be shared by all the applications. The programming code for each application-specific plug-in module may include code to connect the incoming communication in any supported application to the shared resources. By limiting the code within the plug-in modules, a user of the software architecture can reduce development time, increase the likelihood that more applications in the same or different protocols will be properly supported (especially proprietary protocols that may be used by only a limited number of computers or users), and reduce the burden on hardware and software resources for different applications because only relatively small plug-in modules may be used.

In FIG. 3, each row of boxes 3200, 3400, and 3600 represents different applications in the same or different protocols. For example, row 3200 may represent a first application using HTTP, row 3400 may represent a different application using HTTP, and row 3600 may represent yet another application in a different protocol, such as POP, SNMP, WAP, and the like. Note that the series of dots between rows 3400 and 3600 indicate that many other applications in the same or different protocols may be present. Additionally, the architecture may be configured to allow the addition of future applications. The software architecture easily supports at least three different and potentially many more protocols.

Referring to row 3200, each of the boxes 3202 through 3214 represents different stages (actions) that may occur during an electronic transaction. For example, box 3202 may represent a request reception plug-in module, box 3204 may represent an authorization plug-in module, box 3206 may represent a request manipulation plug-in module, box 3208 may represent a content retrieval plug-in module, box 3210 may represents a content manipulation plug-in module, box 3212 may represent a content delivery plug-in module, and box 3214 may represent a post-response communication plug-in module (e.g., acknowledgement, billing, etc.). Each module may correspond to one or more of the discrete actions. Details about the individual plug-in modules are described later in this specification. Note that the other rows 3400 and 3600 include corresponding boxes for substantially the same types of actions except that they are designed for different applications. More specifically, box 3402 represents an incoming message reception plug-in module for a different application using the same protocol as box 3202, and box 3602 represents an incoming message reception plug-in module for yet another application using a different protocol compared to box 3202. New applications that make use of already-supported protocols can be developed with a minimum of effort. This is achieved by creating a new row, which makes use of protocol specific plug-ins used in another row and combines them with other plug-ins developed for the specific application at hand. Some plug-in modules may be substantially the same for many different applications in the same protocol. In different protocols, the plug-in modules for at least some of the different applications may provide substantially the same functionality, although the code within those plug-in modules may be different compared to similar modules for the other protocols.

Within the software architecture, shared resources are illustrated as planes 3102, 3104, and 3106 that lie beneath each of the rows 3200, 3400, and 3600. Referring to FIG. 4, interfaces may be made to each of the shared resources for each plug-in module. Specifically referring to box 3214, functional connectivity 4102 links module 3214 and shared resource 3102. Likewise, functional connectivity 4104 links module 3214 and shared resource 3104, and functional connectivity 4106 links module 3214 shared resource 3106. Links 4102, 4104, and 4106 can be achieved by function calls to the shared resources. Examples of the shared resources may include a content cache, a parameter cache, a connection pool, a domain name server cache, a clock, a counter, a database, a global variables space (e.g., a logging database), or the like. A list of potential shared resources is nearly limitless. Note that not all shared resources may be connected to all modules along a row. For example, modules 3202 and 3204 may not need access to the content cache because they may not receive or process content returned for a request. Each connection from a client may be handled independently on its own thread. However in other embodiments, fewer threads or a single thread can be used to operate all connections to a specific row that supports a particular application or protocol. Unless stated to the contrary, the method below is described from the perspective of proxy computer 140.

FIG. 5 includes a flow diagram of a method of performing an electronic transaction that corresponds to the software plug-in modules that lie along any of rows 3200, 3400, and 3600. Note that all modules are not required and that functions of some modules may be combined with others (e.g., authorization may be part of processing an initial request). The process flow diagram will be briefly covered followed by a more detailed description of each module.

The method can comprise receiving a request from a client computer using a request reception plug-in module (block 502) and performing authorization using an authorization plug-in module (block 504). The method can also comprise manipulating a request using a request manipulation plug-in module (block 512). The method can further comprise retrieving content using a content retrieval plug-in module (block 522). The method can yet further comprise manipulating returned content using a content manipulation plug-in module (block 532) and sending the modified content to the client computer using a content delivery plug-in module (block 534). The method can still further comprise processing post-response communications using a post-response plug-in module (block 542). Note that not all of the activities described in the process flow diagram are required, that a limitation within a specific activity may not be required, and that further activities may be performed in addition to those illustrated. Also, some of the activities may be performed substantially simultaneously during with other activities. After reading this specification, skilled artisans will be capable of determining what activities can be used for their specific needs. Attention is now directed to the protocol-specific plug-in modules along the rows 3200, 3400, and 3600 and how they are related to the activities illustrated in FIG. 5. Although the discussion is directed to row 3200, the corresponding modules along other rows can provide similar functionality. Also, in the example below, client computer 120 is sending a request for content to proxy computer 140, and server computer 160 is providing content in response to the request. The flow of information could be in the opposite direction (server computer 160 seeking information from client computer 120). The method can comprise receiving a request from client computer 120 using request reception plug-in module 3202 (block 502 in FIG. 5). Request reception plug-in module 3202 can be used when a request from client computer 120 is received or accessed by proxy computer 140. Module 3202 can initially generate an associative array from portions of the header of the request. Part or all of the associative array may be used by the other modules along the same row. The associative array may provide information that can be part of function calls to the shared resources. Any or all the data (including the associative array) may be passed from any prior plug_rin module (e.g., module 3202) to any or all the subsequent plug-in modules along the same row (e.g., 3204, 3206, 3208, 3210, 3212, or 3214). The method can also comprise performing authorization using authorization plug-in module

3204 (block 504). The authorization plug-in module 3204 is optional and can be used for determining whether a user at client computer 120 has proper authorization. The authorization modules may be based on an Internet Protocol ("IP") address or a name and a password. Module 3204 may send the IP address or name and password to a shared resource to determine if the user is allowed access. The method can further comprise manipulating the request using request manipulation plug-in module 3206 (block 512). Request manipulation plug-in module 3206 may be used to modify, replace, or otherwise manipulate the request. For example, proxy computer 140 may have code to redirect a URL within a request to a different URL. More specifically, proxy computer 140 may make a function call to that shared resource using the requested URL. The shared resource may pass the different URL back to module 3206. Module 3206 may have the logic to put the different URL in the correct protocol, so that it will be understood by a computer that may receive the redirected request.

The method can yet further comprise retrieving content using content retrieval plug-in module 3208 (block 522). Content retrieval plug-in module 3208 may be used to send the request and receive or access content in response to the original request or manipulated request. More specifically, a request originating from client computer 120 may have been processed by proxy computer 140 before being received by server computer 160. Content from server computer 160, in response to the processed request from proxy computer 140, would be processed using module 3208. Similar to module 3202, the code may parse the content from server computer 160 into a header portion and a content portion and append that information onto a previously generated associative array. The method can still further comprise manipulating returned content from the server computer using content manipulation plug-in module 3210 (block 532). Content manipulation plug- in module 3210 may be used to add or modify content before sending it to client computer 120. More specifically, proxy computer 140 may add advertisements or supplementary information from third parties to the content provided by server computer 160. In an alternative embodiment, part or all of the content originating from server computer 160 may be deleted or replaced with other content. The method can comprise sending the modified content to the client computer using content delivery plug-in module 3212 (block 534). Content delivery plug-in module 3212 may be used to route the content, after manipulation, if any, to client computer 120. Some of the information in the associative array generated when the original request from client computer 120 was processed may be used by module 3212 when sending the outgoing content to client computer 120.

The method can also comprise processing post-response communications using post-response plug-in module 3214 (block 542). Post-response communication plug-in module 3214 may be used for acknowledgement, billing, or other purposes. For example, after content is successfully sent to client computer 120 from module 3212, module 3124 could then charge the user's credit card for that transaction. Alternatively, module 3214 may look for a signal that service to or from client computer 120 or server computer 160 is being terminated for the current transaction. Such post-response processing may be helpful in avoiding invoices or other bills sent to a user at client computer 120 if a product or service was either incomplete or defective or to properly reflect the connect time for a transaction. Along similar lines, one of the planes as illustrated in FIG. 3 may include global space variables that may need to be used by other shared resources, proxy computer 140, or the plug-in modules. System statistics are examples of information that may be within a global variable space. This information may be useful to proxy computer 140 or another computer, such as client computer 120 or server computer 160, in monitoring activity. The statistics may include how many computers are connected to proxy computer 140, the amount of time each of those computers are connected to proxy computer 140, the amount of or time lapsed during transactions being processed through proxy computer 140, or the like.

These global variables may be used in conjunction with a module, such as authorization module 3204. If too many users are currently logged into proxy computer 140, authorization may be denied even if the computer attempting a connection to proxy computer 140 has proper security clearance. After another transaction by another client computer is terminated, a signal from module 3214 can be sent to the logging system within the shared resources. A new client computer may now gain access to the services provided by proxy computer 140 after the connection from the other transaction is terminated. Attention is now directed to more specific activities that may be performed by a specific module, and how that specific module may interact with other modules for the same transaction using a specific application. The process flow diagram illustrated in FIGs. 6-8 is used to describe some of the specific activities. Again, unless stated to the contrary, the method is primarily described from the perspective of proxy computer 140. To aid in understanding the method in FIGs. 6-8, a specific example is used and occasionally referenced. In the example, an incoming communication may be a request from client computer 120 sent to proxy computer 140 for www.yahoo.com. The client computer 120 is communicating using HTTP, using a Netscape™ browser (of AOL Time Warner, Inc. of New York, New York), and has a MacOS X™ operating system (of Apple Computer, Inc. of Cupertino, California).

Referring to FIG. 6, the method can comprise receiving an incoming communication for a specific application (block 602). The communication can comprise a request, a message, or other form of communication. The communication can be sent by client computer 120 and received or accessed by proxy computer 140 via network 11. Proxy computer 140 can access or read at least a portion of the incoming communication and determine the specific application for the communication. In the example, the incoming communication is a request from client computer 120 sent to proxy computer 140 for www.yahoo.com. The incoming communication will also contain other information within the header of the request. In the example, the other information can include the browser and operating system of client computer 120.

After determining the application for the communication, proxy computer 140 can determine which row 3200, 3400, 3600, or other or row of plug-in modules will be used for the transaction. At this point in the method, proxy computer 140 may activate any or all of the plug-in modules for the row corresponding to the specific application. In one embodiment, plug-in modules within each row may be activated only as they are first used. Referring to the example, the request is for an application corresponding to row 3200. Therefore, plug-in module 3202 may be activated. If the communication is for another application, plug-in module 3402 or 3602 may be activated for the particular application.

The method can further comprise routing the incoming communication to a first software plug-in module for the specific application (block 604). Proxy computer 140 can route the request to request reception software plug-in module 3202 because the incoming request uses the application corresponding to row 3200. The method can comprise parsing the incoming communication into a header portion and a content portion (block 622). The parsing can be performed by module 3202 to obtain information from the request.

The method can also comprise generating an associative array using information contained within the header portion (block 624). The associative array can include nearly any finite number of rows. Each row can comprise a key and a value. The key can comprise a parameter within the header portion, and the value can comprise a value for that parameter. In general, the header portion may include one or more lines of a command followed by a command argument. The command may be a key, and the command argument may be the corresponding value for the key. The associative array may be searched by the key or the value. By knowing conventions used by each of the protocols for incoming communications and the characteristics of headers used for those protocols, formation of the associative array can be performed without complicated coding requirements. The associative array is flexible regarding the number of rows and allows different sizes of associative arrays to be used for different protocols.

For HTTP, one of the lines within the header may include a line with "User- Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:l.l) Gecko." The key will be "User-Agent," and the value will be " Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv: 1.1) Gecko." For POP, a line may include "RETR 27," where 27 is an object identifier for is a particular item to be retrieved. The key will be "COMMAND," and the value will be "RETR." A second entry will be made with a key of "ARGUMENT" and a value of "27." For SNMP, a line may include "get 47.12.112.38," where 47.12.112.38 corresponds to an object identifier. The key will be "COMMAND", and the value will be "GET," and a second entry will have the key "ARGUMENT" and the value "47.12.112.38."

The content may or may not be part of the associative array. If it is, the associative array can include a key of "CONTENT" and the entire content data block as the value. For an image, the content may be a very large amount of data. Alternatively, the associative array may be paired with a data pointer that points to the data block, rather than incorporating it directly into the associative array.

Turning to the example, the associative array may include information as shown in Table 1 below. Descriptive names are used instead of actual names to aid in understanding the associative array. Also, the associative array may include many more rows. Because the associative array may be searched by key or value, the order of the rows is unimportant.

Table 1. Exemplary associative array

The method can also comprise generating a function call to at least one of the shared resources using data within the associative array (block 702 in FIG. 7). In the example, proxy computer 140 can make a function call to a shared resource, more specifically to a clock (shared resource) and a logging system (another shared resource) to get the time and log the beginning of the transaction. The logging information may include the time and a transaction identifier. Note that some of the information within the associative array could be sent with the function call to the shared resource. The method can further comprise receiving data from the function call (block 704). In the example, the transaction identifier may be passed back to module 3202. The method can still further comprise processing data from the function call with other code within the first software module (block 706). Module 3202 may be more focused on processing the incoming message rather than processing data coming back from the function call. Other modules, such as the content deliver plug- in module 3212, may perform such data processing. Note that the application-specific processing may occur before, during, or after function call(s), if any, are made to the shared resource(s).

A determination may be made whether the first software plug-in module is the last software plug-in module (diamond 722). If so, the method may end. Otherwise, the method may continue with passing any or all of the data (including the associative array) from a prior software plug-in module to the next software plug-in module (block 802 in FIG. 8). In the example, the next software plug-in module is authorization module 3204. Authorization module 3204 may use some of the information that was collected or generated by module 3202. Passing the information reduces the load on hardware by not sending a communication from proxy computer 140 to another computer (e.g., client computer 120) or making the same or similar function call to a shared resource for the same information.

The method can also comprise generating a function call to at least one of the shared resources using data within the associative array (block 822). Authorization module 3204 may make a function call to the parameter system to determine if the user has proper authorization, whether access can be granted (whether number of users currently connected to proxy computer has exceeded its limits), priority of connection (level or speed of service to be provided), etc. Module 3204 may pass user name and password when making the function call to the logging system. Module 3204 may also make a function call to the shared clock to obtain a time for the action.

The method can also comprise receiving data from the function call (block 824). The data may include information regarding whether user at client computer 120 has proper security clearance, whether the connection could be made, priority of the connection, and the like. The method can further compπse processing data from the function call with other code within the current software plug-in module (block 826). An example may include sending a communication from proxy computer 140 to client computer 120 informing the user whether the connection was made. Alternatively, no further processing may occur with module 3204.

A determination may be made whether the current software plug-in module is the last software plug-in module (diamond 842). If so, the method may end. Otherwise, the method may continue with block 802 in FIG. 8 and proceed in an iterative manner until the last software plug-in module is reached. The remaining modules along row 3200 will be addressed to complete the example transaction to give a better understanding of actions within the modules and some function calls that those modules may make. More or fewer modules may be used. Also, more, fewer, or different function calls may be made by the modules.

Data can be passed to request manipulation software plug-in module 3206. A function call can be made to a shared resource to determine if the request should be changed. The function call may pass information that a request for www.yahoo.com has been received or accessed. The shared resource may include logic to replace the original client request with www.google.com. The associative array may be changed to replace www.yahoo.com with www.google.com or be appended to note that the manipulated request is www.google.com.

Module 3208 may perform the content retrieval. A function call can be made to a content cache (shared resource) at proxy computer 140 to determine if the content cache includes a network page for www.google.com specifically formatted for a computer having a Netscape™ browser and a MacOS X™ operating system. Note that the browser and operating system information can be obtained from the associative array. If the content cache has the network page, it can be passed to module 3208. Otherwise, module 3208 may formulate an HTTP request to server computer 160 requesting the network page for the specific browser and operating system of client computer 120. After proxy computer 140 obtains the proper network page from server computer 160, module 3208 may send a function call to the content cache at proxy computer 140 to cache the network page. The proper network page and other information previously collected may be sent to module 3210.

Content manipulation module 3210 may delete, add, or replace some or all of the content within the proper network page returned. For example, when the proper Google network page is received or accessed, module 3210 may add advertisement(s) around the border(s) of the page. A function call can be made to a shared resource to determine which advertisement(s) should be added. The logging system may keep track of which advertisement is being added, whose advertisement it is, and how many times the advertisement has been added during the current billing cycle. The logging system, which is a shared resource, may access the counter (another shared resource) by itself. In other works, some or all of the shared resources may interact with each other without requiring an application-specific software plug-in module to intervene. The manipulated content and other information may be passed to module 3212.

Content delivery software plug-in module 3212 may take the Google network page formatted for a Netscape™ browser and MacOS X™ operating system and the advertιsement(s) from module 3210 and prepare a communication using HTTP. The communication can be sent from proxy computer 140 to client computer 120. Function calls can be made to the logging system to note the actual content sent to client computer 120 and time sent. Any or all information collected or generated by modules 3202-3212 may be passed to module 3214. Post-response communications module 3214 may be used to track usage or billing information. At the end of a transaction, module 3214 may make a function call to the clock to determine the current time, and make another function call to the logging system to determine how much time lapsed during the transaction and record any billing information. The billing information may be within a shared resource managed by an accounting department. Billing information for the user at client computer 120 may be passed from one of the shared resources to module 3214, which may return some of the information for the user at client computer 120. Proxy computer 140 may send a message to client computer 120 similar to "You were connected for 2.1 minutes and were charged $1.27. Thank you for using our service." Alternatively, no message may be sent and the method may end.

Note that not all of the activities described in the process flow diagram in FIGs. 6-8 are required, that a limitation within a specific activity may not be required, and that further activities may be performed in addition to those illustrated. Also, some of the activities may be performed substantially simultaneously during with other activities. After reading this specification, skilled artisans will be capable of determining what activities can be used for their specific needs.

The power of creating new applications for the same protocol may be better understood with the flow diagram in FIG. 9 and an example. In one embodiment, different applications may be generated for different priorities of users for a network site. The communication protocol may use HTTP. The method can comprise developing a first set of plug-in modules for a first application (block 902). The set may correspond to row 3200 and be directed to premium users of a network site. A new application may need to be developed for regular users of the network site. The communication protocol may also use HTTP. The method can comprise copying the first set of plug- in modules to form a second set of plug-in modules (block 922).

For the new application, only the request manipulation plug-in module, the content manipulation plug-in module, or both may be replaced. The remainder of the plug-in modules may be unchanged and be substantially the same as the remainder of the plug-in modules for the first application.

The method may comprise replacing a first request manipulation plug-in module with a second request manipulation plug-in module for a second application (block 924). For example, the premium user may have access to some network pages that the regular user may not. If the regular user requests a premium page, the second request manipulation module may direct the regular user to another network page for which the regular user has proper access.

The method may also comprise replacing a first content manipulation plug-in module with a second content manipulation plug-in module for the second application (block 926). The premium user may have only 10 percent of his or her window occupied by advertisements, whereas the regular user may have 50 percent of his or her window occupied by advertisements. The second content manipulation module may reformat the retrieved content to allow for more advertising space. The second content manipulation module may also access the shared resources to obtain the advertisements and keep track of which advertisements were used. Device dependent optimization of network pages (desktop computer vs. cellular phone, etc.) can be achieved by plugging in a module which transcodes content using settings developed for the particular device that made the initial request. After one or both of the request manipulation and content manipulation modules are replaced, the method can still further comprise executing the second application using the second set of plug-in modules (block 942).

Note that while the example focused more on replacing specific modules, in other embodiments, those modules may be generated by editing code within the corresponding modules within the first set for the first application.

After reading this specification, skilled artisans will appreciate that entirely different applications, using the same network protocol, can be developed by simply inserting new plug-in module(s) at the request manipulation location, the content request location, or both locations.

In other embodiments, the method and system may be used for nearly any other network communications. As an example, client computer 120 may make a request for information within a database located at server computer 160. The request may be handled in a manner similar to a request for a network page. If the user does not have proper authorization to all information within a request, the request manipulation module may request only that information for which the user has property access or the content manipulation module may add information stating that the user does not have proper access to some or all the information.

In another embodiment, the multiple-protocol software architecture and plug-in modules may be installed in client computer 120 or server computer 160. Not all modules in proxy computer 140 may be needed by client computer 120 or server computer 160. Authorization modules 3204, 3404, and 3604 may not be used or can be coded to allow authorization (always authorized) at client computer 120. The content manipulation modules 3210, 3410, and 3610 may not be used by the server computer 160. After reading this specification, skilled artisans are capable of determine which modules are needed and which ones can be eliminated or bypassed (module exists but passes information through without performing any other significant activity).

The software components can be designed to maximize their ability use shared resources while minimizing the amount of code used for application-specific operations. Therefore, relatively smaller plug-in modules (compared to the shared resources) may be used to access the shared resources illustrated in the planes below the modules. In this manner, less code needs to be written for a new protocol compared to the prior-art method of writing or copying and modifying an entire program for a specific protocol. For applications in the same protocol, the specific coding requirements may be much less. Furthermore, protocols are more likely to be supported because the coding requirements are less, and therefore, may be generated for protocols that have relatively fewer users compared to other protocols. The method and system are significantly more efficient in both time and cost compared to existing prior-art methods dealing with the problem of many different applications in the same or different protocols.

Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature or element of any or all the claims.

Claims

1. A system for establishing a set of configuration parameters comprising a software program stored on a computer readable memory and executable by a computer processor to: send a first request over a network to a first configuration source; receive a first response over the network, wherein said first response includes a first portion of the set of configuration parameters; send a second request over the network to a second configuration source; and receive a second response over the network, wherein said second response includes a second portion of the set of configuration parameters.

2. The system of Claim 1, wherein said first request and said second request are based on a load list.

3. The system of Claim 1, wherein said second request is based on a previous response to a previous request.

4. The system of Claim 3, wherein said software program is further executable to: send a plurality of requests to a plurality of additional configuration sources; and receive a plurality of responses from said plurality of additional configuration sources, wherein at least one of said plurality of responses contains at least a third portion of the set of configuration parameters.

5. The system of Claim 4, wherein said second request is based on at least one of the plurality of responses.

6. The system of Claim 5, wherein at least one of said plurality of requests are based on a set of initial parameters.

7. The system of Claim 3, wherein said first configuration source and said second configuration source are the same configuration source.

8. The system of Claim 3, wherein the previous response includes a set of additional request information and wherein said second request is based on said set of additional request information.

9. The system of Claim 8, wherein said second request includes an additional request parameter from said set of additional request information.

10. The system of Claim 9, wherein said previous request comprises said first request and said previous response comprises said first response.

11. The system of Claim 9, wherein said second request includes a plurality of additional request parameters.

12. The system of Claim 11, wherein said plurality of additional request parameters come from a plurality of previous responses.

13. The system of Claim 1, wherein said first request and is based on a client application request received by the software program.

14. The system of Claim 13, wherein said software program is further executable to make a request to a configuration server each time a client application request is received.

15. The system of Claim 13, wherein said first response further contains at least one special parameter establishing caching directives for at least said first portion of the set of configuration parameters.

16. A system for establishing a set of configuration parameters comprising: a network a first computer in communication with the network further comprising: a first computer processor; a first computer readable memory accessible by the first computer processor; a first computer network adapter device in communication with the first computer processor and operable to communicate data over the network; a first computer program comprising instructions stored on the first computer readable memory and executable by the first computer processor to: send a first request over a network to a first configuration source; receive a first response over the network including a first portion of the set of configuration parameters; send a second request over the network to a second configuration source; and receive a second response over the network, wherein said second response includes a second portion of the set of configuration parameters; and a plurality of configuration sources in communication with the network, each configuration source further comprising: a configuration source computer processor; a configuration source computer readable memory accessible by the configuration source computer processor; a configuration source network adapter device in communication with the configuration source computer processor and operable to communicate data over the network; a configuration source program comprising instructions stored on the configuration source computer readable memory and executable by the configuration source computer processor to: receive a request over the network from the first computer program; and generate a response based on the received request.

17. The system of Claim 16, wherein at least one configuration source program is further executable to generate a response by: querying an external resource for data; receiving an external resource response; generating the response based on the external source response.

18. The system of Claim 16, wherein at least one configuration source program is further executable to generate a response based on a request parameter received from the first computer.

19. The system of Claim 16, wherein at least one configuration source program is further executable to generate a response based on system state information.

20. The system of Claim 16, wherein said first request is an initial request based on an a set of initial parameters.

21. The system of Claim 16, wherein said second request is based on a previous response to a previous request.

22. The system of Claim 21, wherein said previous response includes additional request information and wherein said second request is based on said additional request information.

23. The system of Claim 22, wherein said additional request information includes an additional request parameter and wherein said second request includes said additional request parameter.

24. The system of Claim 23, wherein said second request includes a plurality of additional request parameters.

25. The system of Claim 21 , wherein said previous request comprises said first request.

26. The system of Claim 16, wherein said first computer program is further executable to send an initial request to an initial configuration source based on a set of initial parameters.

27. The system of Claim 16, wherein said first computer comprises a proxy server.

28. A method for configuring a program, comprising: sending a first request over a network to a first configuration source; receiving a first response over the network, wherein said first response includes a first portion of the set of configuration parameters; sending a second request over the network to a second configuration source; and receiving a second response over the network, wherein said second response includes a second portion of the set of configuration parameters.

29. The method of Claim 28, further comprising sending the second request based on additional request information contained in a previous response to a previous request.

30. The method of Claim 29, wherein the previous response upon which the second request is based includes an additional request parameter and wherein the second request includes the additional request parameter.

31. The method of Claim 29, wherein the second request is based on multiple additional request parameters from one or more previous responses.

32. The method of Claim 29, further comprising: loading a set of initial parameters; making an initial request based on the set of initial parameters.

33. The method of Claim 28, further comprising generating said first response based on a system state.

34. The method of Claim 28, further comprising generating said second response based on a system state.

35. The method of Claim 28, further comprising querying an external resource to generate the first response.

36. The method of Claim 28, further comprising querying an external resource to generate the second response.

37. The method of Claim 28, further compπsmg specifying caching directives for said first portion of the set of configuration parameters.

38. The method of Claim 28, further compnsing specifying cachmg directives for said second portion of the set of configuration parameters.