The following are further messages sent to web server add-in components
[0103]1501-
150nfrom Java Applet/Controlling #"[0104]">
The various status commands determine the status of a connection. The status command is the only command that can be issued if an audio session has not yet established. Status can be determine at the web server add-in component level (using the status command); at the control server level (using the status and statuscs commands); or at the audio server level (using the statusas command). The web server add-in component can be configured to record connection states as told to it by the control server. If the web-server add-in component is configured to record connection states, then the status command is fulfilled by the web server add-in component. If the web-server add-in component is not configured to record connection states, the status command is passed to the control server for processing (same as with the statuscs command). In one embodiment of the invention, the purpose of all the status commands is to set an HTTP cookie named status to indicate the state of the users connection. The possible values of this status cookie are: (a) off—no connection at this time; (b) ipt—in progress, telephone mode; (c) ipv—in progress, VoIP mode; (d) ont—connection established, telephone mode; (e) onv—connection established, VoIP mode; (f) ontm—same as d but currently muted; (g) onvm—same as e, but currently muted; (h) busy—in dial-out mode, the user specified number was busy; (i) noa—in dial-out mode, no answer; (j) asb—in dial out mode, all circuits were busy. “busy,” “noa,” and “asb” states are preserved for a predetermined amount of time (configurable and typically a short time) after the failure to allow for the reception on the status by the user. This is to allow the user to take the appropriate steps (if any) to change the conditions, and then re-initiate the connection. The status is retrieved by polling the web server add-in component or the control server during the condition initiation phase to relay the state to the user.[0104]
The following are Messages/Requests web server add-in components
[0105]1501-
150nreceive from control servers
3001-
300p:
|
|
| // Request 2000. Request web server status |
| const unsigned int CS_WS_PROVIDE_STATUS = 2000; |
| // uses only STANDARD_REQUEST header. |
| // Request 2001. Request web server set CS configuration information |
| const unsigned int CS_WS_SET_CS_CONFIGURATION = 2001; |
| // STANDARD_REQUEST header followed by: |
| unsigned int startTime; |
| unsigned int majorVersion; |
| unsigned int minorVersion; |
| unsigned int dialType; // in ,out or both |
| unsigned int mode; // phone, voip or both (bit vector) |
| unsigned int connectionType; | // internal or external |
| unsigned int extensionLength; | // Length of the extensions that the |
| | // control server will dial if it is in |
| | // internal mode. |
| unsigned char ipDomain[CHAR_BUFFER_SIZE]; // for cookies |
| unsigned char isCallBackEnabled; // T or F: control server mode |
| unsigned int vocodersAvailable; // VoIP mode (bit vector) |
| // Request 2002. Notify of status change |
| const unsigned int CS_WS_NOTIFY_STATUS_CHANGE = 2002; |
| // uses only STANDARD_REQUEST header. |
| // Request 2003. Notify control server shutting down |
| const unsigned int CS_WS_NOTIFY_SHUTTING_DOWN = 2003; |
| // uses only STANDARD_REQUEST header. |
| // Request 2004. Notify web servers that a user/visitor ID has a line |
| // reserved or a call in progress. |
| const unsigned int CS_WS_NOTIFY_IN_PROGRESS = 2004; |
| // uses STANDARD_REQUEST header followed by: |
| unsigned int visitorID; | // user/visitor ID of the requester |
| // Request 2005. Notify web servers that a user/visitor ID has |
| a call connected. |
| const unsigned int CS_WS_NOTIFY_CONNECTED = 2005; |
| // uses STANDARD_REQUEST header followed by: |
| unsigned int visitorID; | // user/visitor ID of the requester |
| // Request 2006. Notify web servers that a user/visitor ID has a call |
| disconnected. |
| const unsigned int CS_WS_NOTIFY_DISCONNECTED = 2006; |
| // uses STANDARD_REQUEST header followed by: |
| unsigned int visitorID; | // user/visitor ID of the requester |
| // Request 2007. Notify web servers of all the connections and those |
| in progress. |
| const unsigned int CS_WS_SET_CS_CONNECTIONS = 2007; |
| // STANDARD_REQUEST header followed by: |
| unsigned int listLength; |
| unsigned int list[MAX_VISITOR_IDS_PER_MESSAGE]; |
| // list of user/visitor ID |
| // Request 2008. Notify web servers of a large disconnection. |
| // An audio server shutdown, or a board / trunk failure. |
| const unsigned int CS_WS_SET_CS_DISCONNECTIONS = 2008; |
| // STANDARD_REQUEST header followed by: |
| unsigned int listLength; |
| unsigned int list[MAX_VISITOR_IDS_PER_MESSAGE]; // list of |
| user/visitor IDs |
| // Request 2009. Notify web servers of federation configuration (optional) |
| const unsigned int |
| CS_WS_SET_FEDERATION_CONFIGURATION = 2009; |
| // STANDARD_REQUEST header followed by: |
| Embodiment configuration information |
| //Request 2010. Notify web servers of embodiment statistics (optional) |
| const unsigned int CS_WS_SET_FEDERATION_STATISTICS = |
| 2010; |
| // STANDARD_REQUEST header followed by: |
|
Embodiment Statistics Information[0106]
The following is a sample configuration of an embodiment of an inventive web server add-in component using Netscape's FastTrack Web Server on Microsoft's Windows NT operating system. This sample file below is normally named obj.conf and is located in a web server specific configuration directory. In this example, the web server add-in component (addins.dll) is located in the C:\Program Files\isound\nsapi\bin directory. Invention specific configuration command lines are underlined.[0107]
The sample below uses the technique of using file extensions (MIME types—is, ispn, ispl, issn, issl ) to detect HTTP requests to play or set audio files; and uses HTTP requests to the “/isound/commands” virtual directory to initiate audio commands (louder, etc.). As stated earlier this is but one way to accomplish the task of determining which HTTP requests are intended for the web server add-ins
[0108]1501-
150n. If other approaches are used (e.g. conditional get requests) the statements in this configuration file would change accordingly.
|
|
| Init fn=flex-init access=“C:/Program Files/Netscape/Server/httpd-adams1/logs/access” |
| format.access=“%Ses->client.ip% − %Req->vars.auth-user% [%SYSDATE%]\”%Req- |
| >reqpb.clf-request%\“%Req->srvhdrs.clf-status%%Req->srvhdrs.content-length%%Req- |
| >headers.if-modified-since%” |
| Init fn=load-types mime-types=mime.types |
| Init funcs=“is-init,is-set-connect-document, is-send-document,is-process-connect-info,is- |
| set-disconnect-document,is-process-disconnect-info,is-play-audio,is-process-command” |
| fn=load-modules shlib=“C:/Program Files/isound/nsapi/bin/addins.dll” |
| Init fn=is-init control_server=12,udp,adams1,adams1b request_port=90 threads=4 |
| web_server_id=1 close_connection=false, command_time_out=2, domain=.intensifi.org |
| <Object name=default> |
| NameTrans fn=assign-name from=/isound/commands/* name=is-process-command |
| NameTrans fn=assign-name from=/isound/connect/* name=is-connect |
| NameTrans fn=assign-name from=/isound/disconnect/* name=is-disconnect |
| NameTrans fn=pfx2dir from=/ns-icons dir=“C:/Program Files/Netscape/Server/ns-icons” |
| NameTrans fn=pfx2dir from=/mc-icons dir=“C:/Program Files/Netscape/Server/ns-icons” |
| NameTrans fn=document-root root=“C:/Program Files/Netscape/Server/docs” |
| PathCheck fn=nt-uri-clean |
| PathCheck fn=find-pathinfo |
| PathCheck fn=find-index index-names=“index.html,home.html,index.htm,home.htm” |
| ObjectType fn=type-by-extension |
| ObjectType fn=force-type type=text/plain |
| Service method=(GET|HEAD) type=isound-internal/audio fn=is-play-audio |
| Service method=(GET|HEAD) type=magnus-internal/imagemap fn=imagemap |
| Service method=(GET|HEAD) type=magnus-internal/directory fn=index-common |
| Service method=(GET|HEAD) type=*˜magnus-internal/* fn=send-file |
| AddLog fn=flex-log name=“access” |
| </Object> |
| <Object name=cgi> |
| ObjectType fn=force-type type=magnus-internal/cgi |
| Service fn=send-cgi |
| </Object> |
| <Object name=is-process-command> |
| Service method(GET|HEAD) fn=is-process-command |
| </Object> |
| <Object name=is-connect> |
| NameTrans fn=is-set-connect-document |
| Service method=(GET|HEAD) type=text/html fn=is-send-document |
| Service metho&(GET|POST) type=isound-internal/form fn=is-process-connect-info |
| </Object> |
| <Object name=is-disconnect> |
| NameTrans fn=is-set-disconnect-document |
| Service method=(GET|HEAD) type=text/html fn=is-send-document |
| Service method=(GET|POST) type=isound-internal/form fn=is-process-disconnect-info |
| </Object> |
|
The first underlined section “Init funcs= . . . ” indicates that the Netscape FastTrack Web Server is to load the IntenseSound dynamic link library (dll) from the specified directory. The Netscape server is also told to be aware of several functions in this dll which will be called by directives later in the file. The second underlined section “Init fn= . . . ” initializes embodiment[0109]150 (calls is-init): (a) to set the web server id to 1; (b) to set the control server ID to contact to 12; (c) to use UDP as the normal protocol when contacting control server300; (d) to use the IP interface known as “adams1” as a primary interface when contacting the control server; (e) to use the IP interface known as “adams1b” as a secondary interface when contacting control server300; (f) to specify 90 as the UDP and TCP port on which to listen on for messages from control server300 on all IP interfaces configured on the local machine; (g) to set the initial number of request processing threads (messages from control server300 to 4); (h) indicates not to close the socket connection after each isound request; (i) set the timeout to two seconds—no commands within two seconds of a play or set request.; and (j) overrides the domain specified by the control server with “intensifi.org”. The domain is used to set HTTP cookies. The control server domain would be overriden where a single control server was being shared by multiple independent web servers. In other embodiments of the present invention, these and other parameters may be set forth in a specific configuration file separate from a web server configuration file to ease reconfiguring the inventive components. The third, fourth and fifth underlined sections “NameTrans fn= . . . ” name Netscape “configuration styles” to use when documents in specific directories are requested. The styles are defined below. The sixth underlined section “Service method= . . . ” indicates that any HTTP GET or HEAD requests for files of type isound-internal/audio (decided by mime type described below) are to be processed by the function is-play-audio. This function sends the play file request to control server300, waits for a response, sends a “no response necessary” response code to the user's web browser, and then sets status flags to tell Netscape not to process the request further. The rest of the underlined sections tell what actions to take based on URL requests that met the style types defined earlier. Commands are processed by is-process-command. Connect and disconnect requests are processed by the appropriate styles as well. Note that the connect and disconnect styles have two responsibilities: (a) to determine which connect or disconnect document to send to the user based on current configurations and connection status and (b) to process the form that is eventually submitted by the user to process the connect or disconnect request itself. In all cases, the processing sends a “no response necessary” HTTP response code back to the requesting web browser, and tells the Netscape web server that no further processing is necessary.
The following is a sample section of configuration information for the inventive web server add-in components using Netscape's FastTrack Web Server on Microsoft's Windows NT operating system. This sample section below is normally located in the mime.types file and is located in the web server specific configuration directory.
[0110] | |
| |
| type=isound-internal/audio | exts=is |
| type=isound-internal/audio | exts=ispn |
| type=isound-internal/audio | exts=ispl |
| type=isound-internal/audio | exts=issn |
| type=isound-internal/audio | exts=issl |
| type=isound-internal/parsed-html exts=is_html |
| type=isound-internal/form | exts=is_form |
| |
The first five lines specify that if any requests come in for files with the named extensions, the request's internal type is to be set to “isound-internal/audio”. When this occurs, the appropriate inventive function processes these requests. The last two entries state that if requests come in for files with the named extensions that the request's internal type is to be set to “isound-internal/parsed-html” or “isound-internal/form”. When this occurs, the appropriate inventive function processes these requests.[0111]
Control Server[0112]
Control server[0113]300 (a daemon background process on Unix, a service background process on Windows NT) receives messages/commands/requests from web server add-in components1501-150nand audio-servers2001-200n, processes them, maintains a state for connections, and sends appropriate message/command/request to other components of the inventive embodiment.
In accordance with a preferred embodiment of the present invention, incoming messages/commands/requests are optionally logged for later review. User sessions can also be optionally logged for later review and/or billing. In a preferred embodiment, control server[0114]300 is capable of running in debug mode where it will display on a console window detailed information pertaining to the messages/commands/requests that it receives. Further, control server300 can be configured to not allow any more new connections or to allow new connections (the default). In accordance with the present invention, this is useful when control server300 is to be taken offline for maintenance, but current connections are to remain unaffected. Once all connections have ceased, control server300 can then be taken offline safely. However, audio functions ofembodiment1000 will be unavailable until control server300 comes back online and notifies its associated audio servers and web server add-in components that it is available for processing.
In addition, and in accordance with the present invention, control server[0115]300 keeps a list keyed by user/visitor ID which tracks whether the user is connected or in the process of connecting. This list is updated based on messages being sent to control server300 from audio servers2001-200m. Control server300 can optionally also maintain a list of users waiting to connect when no lines were available to satisfy their original connection request. Control server300 also maintains the next available user/visitor ID. This value is obtained from a configuration file at startup. Upon shutdown, the next available number is written back to a predetermined file for a subsequent startup. During operations, control server300 controls access to the next available user/visitor ID with read/write wave locks (described above). In one embodiment of the present invention,100 (configurable) user/visitor IDs are cached at a time. The next available user/visitor ID (after the cached100) is written back to the configuration file to prevent more then100 user/visitor IDs from being lost if control server300 were to crash for some reason. Once these100 user/visitor IDs are used, another100 are obtained by reading a user/visitor ID file and updating its contents for the next potential read. The number of visitor ID's to cache is not fixed at100. It is configurable, but defaults to100.
In all operating systems, it is preferred (but not required) to implement this component of the inventive embodiment using the C++ programming language. For example, on Microsoft platforms, Microsoft's Visual C++ is the preferred compilation language and environment, and on Unix or Linux platforms, GNU C/C++ is the preferred compilation language and environment.[0116]
Messages control server[0117]300 can send are described: (a) below in the discussion regarding messages that can be received by audio servers2001-200mand (b) above in the discussion regarding messages that can be received by web server add-in components1501-150n.
Messages control server[0118]300 can receive are described: (a) below in the discussion regarding messages that can be sent by audio servers2001-200mand (b) above in the discussion regarding messages that can be sent by web server add-in components1501-150n.
Configuration of control server
[0119]300 is controlled by several configuration files located in the same or parallel directory as the executable files of control servers
1001-
100n. The first configuration file, configuration.cs, is the main file used to control the operation of control server
300. It contains multiple parameters. The parameters and their uses are described below.
|
|
| Parameter | sample value | Usage |
|
| control server: | 19,adams1 | Identifies the control |
| | server host and its ID |
| listening port number: | 83 | TCP and UDP port to |
| | listen on |
| logging directory: | | directory where to log |
| | information |
| log configuration: | true | log configuration on |
| | startup |
| log warnings: | true | log warnings |
| log informational messages: | true | log informational |
| | messages |
| log usage: | true | log audio server usage |
| log requests: | false | log incoming requests |
| log visitors: | false | log the visitors |
| accepting new connections: | true | allow new connections |
| | on startup |
| admin consoles: | false | can configuration be |
| | updated externally |
| admin password: | sadasf | password required for |
| | admin functions |
| min udp request threads: | 1 | min UDP request |
| | processing threads |
| max udp request threads: | 12 | max UDP request |
| | processing threads |
| delta udp request threads: | 2 | delta number of UDP |
| | threads to start/stop |
| min tcp request threads: | 4 | min number of TCP |
| | request processing |
| | threads |
| max tcp request threads: | 20 | max number of TCP |
| | request processing |
| | threads |
| delta tcp request threads: | 2 | delta number of TCP |
| | threads to start/stop |
| max concurrent udp datagrams: | 100 | maximum number of |
| | concurrent UDP requests |
| max concurrent tcp connections: | 100 | maximum number of |
| | concurrent TCP requests |
| number of sending threads: | 20 | Number of threads used |
| | to send messages to |
| | audio servers and web |
| | servers |
| extension length: | 5 | how long are extensions |
| mode: | both | phone, voip or both |
| | Note: This setting simply |
| | allows certain types of |
| | audio servers to join the |
| | federation. The actual |
| | mode can change over |
| | time as audio servers |
| | come online or go |
| | offline. Web server |
| | add-ins are notified as |
| | the mode changes. |
| | Additionally the control |
| | server maintains an |
| | internal state as to which |
| | vocoders are available. |
| | The state is determined |
| | as audio servers |
| | announce themselves and |
| | their configuration to the |
| | control server. |
| dial type: | out | configured for dial-in or |
| | dial-out, or both |
| | Note: This setting |
| | detemines which type of |
| | audio server will be used |
| | to initiate connections to |
| | users. An audio server in |
| | an incompatible mode |
| | can still be part of the |
| | federation, however it |
| | will be used exclusively |
| | for private ports as the |
| | control server will ignore |
| | it |
| allow private lines: | yes | allow private lines to be |
| | configured (if not, |
| | private lines are ignored) |
| connection type: | external | connected to PSTN |
| | (external) or PBX |
| | (internal) |
| line reservation time: | 4 | number of minutes to |
| | reserve a line before |
| | freeing the line for |
| | another's use. |
| max active calls: | 1000 | number of active calls to |
| | support (work in |
| | conjunction with the |
| | authorization key) |
| authorization key: | 12QW- | controls which host and |
| ER45-SD89 | at what capability level |
| | the control server is |
| | running, enterprise, |
| | workgroup or developer, |
| | (described below) |
| max call inactive time: | 10 | how long before auto |
| | disconnect |
| heart beat interval: | 120 | how long to wait |
| | between each attempt to |
| | contact the associated |
| | audio servers and web |
| | server add-in components |
| ip domain: | .adams.com | domain to use for setting |
| | HTTP cookies |
| command timeout window: | 2 | number of seconds after |
| | requests before |
| | commands are processed |
| enable callback: | false | If no ports are available |
| | should call back when |
| | available be used? |
| Max callback time: | 20 | If in callback mode how |
| | long before callsback are |
| | too old? |
| Max waiting visitors: | 10 | If in callback mode how |
| | many waiters to allow? |
|
The second configuration file, web_servers.cs, lists the web server add-in components that are part of[0120]embodiment1000 managed by control server300. For example:
web server:1,80,udp,[0121]90,adams1, 10.0.10.12
This example states that: (a) web server add-in[0122]component ID 1 listens to HTTP requests on port80 (the default); (b) UDP is the preferred protocol to use when making or responding to requests; (c)90 is the UDP and TCP port that the web server add-in component will be listening on; (d) the name of the primary IP interface to use when contacting this web server add-in component is adams1; and (e) the secondary IP interface to use when contacting this web server add-in component is 10.0.10.12.
The third configuration file, audio_servers.cs, lists the audio servers that are part of[0123]embodiment1000 managed by control server300. For example:
audio server:19,udp,83,adams1[0124]
This example states that: (a) audio server ID is 19; (b) UDP is the preferred protocol to use when making or responding to requests; (c)[0125]83 is the UDP and TCP port that the audio server will be listening on; (d) the name of the primary IP interface to use when contacting this audio server is adams1; and (e) no secondary IP interface has been specified.
The fourth configuration file, next_visitor_id.cs, stores the next available user/visitor ID as an editable number. While running, the value stored in this file is the next user/visitor ID to use after the internally cached values are exhausted. When control server[0126]300 shuts down, the next available user/visitor ID is written back to this file so as not to needlessly waste user/visitor IDs.
The fifth configuration file, allowed_numbers.cs (optional file and optional contents), stores a list of allowed area codes, area code and prefixes, complete numbers and domains. If any of this information is specified then all requests to the control server must be listed in this information or the call will be disallowed. It is highly unlikely that the “number” directive will ever be used as it drastically limits the numbers that can be dialed. It is more likely that the area code directive will be the only one used. This information is only consulted if control server
[0127]300 is configured in dial-out mode. For example:
| |
| |
| area code:303 # denver, |
| area code:714 # orange county, |
| area code & prefix:650654 |
| number:6506549999 |
| domain: intensifi.com # VoIP only |
| |
The sixth configuration file, disallowed_numbers.cs, stores a list of disallowed area codes, prefixes, area code and prefixes, complete numbers and domains. If any of this information is specified then all requests to the control server will be checked against this information before the call is allowed. This information is only consulted if control server
[0128]300 is configured in dial-out mode. For example:
|
|
| area code:800 # No toll free numbers as caller id cannot be blocked. |
| area code:888 # No toll free numbers as caller id cannot be blocked. |
| area code:900 # No toll numbers |
| prefix:976 # No toll numbers |
| prefix:555 # reserved |
| area code & prefix:650506 # competitor |
| area code & prefix:650767 # time |
| number:6502937000 |
| domain: badcompany.com # VoIP only |
|
Audio Server[0129]
Audio servers[0130]2001-200m(a daemon background process on Unix, a service background process on Windows NT) receive messages/commands/requests from control servers3001-300pand users connected over telephone lines or VoIP connections, process them, maintain a state for connections, and send the appropriate message/request to control servers3001-300pwhen appropriate.
In accordance with a preferred embodiment of the present invention, incoming messages/commands/requests are optionally logged for later review. User connections can also be optionally logged for later review and/or billing. Audio servers[0131]2001-200mare capable of running in debug mode where detailed information pertaining to the messages/commands/requests that are received will be displayed on a console window. Audio servers2001-200mcan be configured to not allow any more new connections or to allow new connections (the default). This is useful when an audio server is to be taken offline for maintenance but current connections are to remain unaffected. Once all connections have ceased, the audio server can then be taken offline safely.
In a preferred embodiment, each of audio servers[0132]2001-200mkeeps a list keyed by a board number/port number combination which tracks port allocation (use by a particular control server and user/visitor), status, configuration and state. In accordance with a preferred embodiment of the present invention, this list is managed by a “state machine” which tracks the current state of the port in question and what the next possible state is based on allowed types of telephony events, or inventive functionality generated events that might occur. The “states” of the state machine that must be tracked are specific to the computer telephony board types (Natural Microsystems, Dialogic, etc.) installed in the particular audio server; which computer telephony boards and methods of use thereof are well known to those of ordinary skill in the art.
In all operating systems, it is preferred (but not required) to implement this component of the inventive embodiment using the C++ programming language. For example, on Microsoft platforms, Microsoft's Visual C++ is the preferred compilation language and environment, and on Unix or Linux platforms, GNU C/C++ is the preferred compilation language and environment.[0133]
The following are Messages/Requests audio servers
[0134]2001-
200msend to control servers
3001-
300p:
|
|
| // Request 3000. Request control server status. |
| const unsigned int AS_CS_PROVIDE_STATUS = 3000; |
| // uses only STANDARD_REQUEST header. |
| // Request 3001. Update audio server base configuration information |
| const unsigned int AS_CS_SET_AS_BASE_CONFIGURATION = 3001; |
| // uses STANDARD_REQUEST header followed by: |
| unsigned int startTime; //time that the audio server started. |
| unsigned int majorVersion; |
| unsigned int minorVersion; |
| unsigned int mode; // phone or VoIP |
| unsigned int dialType; // in or out |
| unsigned int connectionType; // internal or external |
| unsigned int extensionLength; // how long are extensions |
| unsigned int lineReservationTime; // how long to reserve lines |
| unsigned int maxInactiveTime; // how long before auto disconnect |
| unsigned char isShared; // used my multiple control servers |
| unsigned char arePrivateConnectionsAllowed; // has private lines |
| unsigned char localAreaCode[AREA_CODE_LENGTH]; |
| unsigned char usingAllowedNumbers; // allowed numbers in use |
| unsigned char usingDisallowedNumbers; // disallowed numbers in use |
| unsigned char voipIPInterface[IP_INTERFACE_LENGTH]; |
| unsigned int voipVocoder; // G723.1, G729a, G711, GSM, etc. (bit vector) |
| // Request 3002. Update audio server allowed area code configuration information |
| const unsigned int AS_CS_SET_AS_ALLOWED_AREA_CODES = 3002; |
| // uses STANDARD_REQUEST header followed by: |
| unsigned int listLength; |
| unsigned char list[MAX_AREA_CODES][AREA_CODE_LENGTH]; |
| // Request 3003. Update audio server allowed area codes and |
| // prefixes configuration information |
| const unsigned int AS_CS_SET_AS_ALLOWED_AREA_CODE_AND_PREFIXES = 3003; |
| // uses STANDARD_REQUEST header followed by: |
| unsigned int listLength; |
| unsigned char list [MAX_AREA_CODE_AND_PREFIXES] |
| [AREA CODE_LENGTH + PREFIX_LENGTH]; |
| // Request 3004. Update audio server allowed complete numbers |
| // configuration information |
| const unsigned int AS_CS_SET_AS_ALLOWED_COMPLETE_NUMBERS = 3004; |
| // uses STANDARD_REQUEST header followed by: |
| unsigned int listLength; |
| unsigned char list [MAX_COMPLETE_NUMBERS] |
| [COMPLETE_PHONE_NUMBER_LENGTH]; |
| // Request 3005. Update audio server allowed domains configuration information |
| const unsigned int AS_CS_SET_AS_ALLOWED_DOMAINS = 3005; |
| // uses STANDARD_REQUEST header followed by: |
| unsigned int listLength; |
| unsigned char list [MAX_DOMAINS] |
| // Request 3006. Update audio server disallowed area code |
| // configuration information |
| const unsigned int AS_CS_SET_AS_DISALLOWED_AREA_CODES = 3006; |
| // uses STANDARD_REQUEST header followed by: |
| unsigned int listLength; |
| unsigned char list[MAX_AREA_CODES][AREA CODE_LENGTH]; |
| // Request 3007. Update audio server disallowed area code |
| // and prefixes configuration information |
| const unsigned int AS_CS_SET_AS_DISALLOWED_AREA_CODE_AND_PREFIXES = 3007; |
| // uses STANDARD_REQUEST header followed by: |
| unsigned int listLength; |
| unsigned char list [MAX_AREA_CODE_AND_PREFIXES] |
| [AREA_CODE_LENGTH + PREFIX_LENGTH]; |
| // Request 3008. Update audio server disallowed prefixes |
| // configuration information |
| const unsigned int AS_CS_SET_AS_DISALLOWED_PREFIXES = 3008; |
| // uses STANDARD_REQUEST header followed by: |
| unsigned int listLength; |
| unsigned char list[MAX_PREFIXES][PREFIX_LENGTH]; |
| // Request 3009. Update audio server disallowed complete numbers |
| // configuration information |
| const unsigned int AS_CS_SET_AS_DISALLOWED_COMPLETE_NUMBERS = 3009; |
| // uses STANDARD_REQUEST header followed by: |
| unsigned int listLength; |
| unsigned char list [MAX_COMPLETE_NUMBERS] |
| [COMPLETE_PHONE_NUMBER_LENGTH]; |
| // Request 3010. Update audio server disallowed domains |
| // configuration information |
| const unsigned nt AS_CS_SET_AS_DISALLOWED_DOMAINS = 3010; |
| // uses STANDARD_REQUEST header followed by: |
| unsigned int listLength; |
| unsigned char list [MAX_DOMAINS] |
| // Request 3011. Status change |
| const unsigned int AS_CS_NOTIFY_STATUS_CHANGE = 3011; |
| // uses only STANDARD_REQUEST header |
| // Request 3012. Notify audio server shutting down |
| const unsigned int AS_CS_NOTIFY_SHUTTING_DOWN = 3012; |
| // uses only STANDARD_REQUEST header |
| // Request 3013. Update audio server port status |
| const unsigned int AS_CS_UPDATE_PORT_COUNTS = 3013; |
| // uses STANDARD_REQUEST header followed by: |
| int | deltaNumberOfInternalPorts; |
| int | deltaNumberOfInternalPortsInUse; |
| int | deltaNumberOfExternalPorts; |
| int | deltaNumberOfExternalPortsInUse; |
| int | deltaNumberOfPrivatePorts; |
| int | deltaNumberOfPrivatePortsInUse; |
| // Request 3014. Notify visitor is disconnected (or timed out) |
| const unsigned int AS_CS_NOTIFY_DISCONNECTED = 3014; |
| // uses STANDARD_REQUEST header followed by: |
| unsigned int visitorID; |
| unsigned char didVisitorInitiateDisconnection; // used to reinitiate |
| // in case of equipment failure |
| // Request 3015. Notify Visitor is connected |
| const unsigned int AS_CS_NOTIFY_CONNECTED = 3015; |
| // uses STANDARD_REQUEST header followed by: |
| unsigned int visitorID; |
| unsigned int boardNumber; // board connected to |
| unsigned int portNumber; //port connected to |
| unsigned char isPrivateConnection; // T or F occurred on private line? |
| // Request 3016. Notify web servers of a large disconnection. |
| // An audio server shutdown, or a board or trunk failure. |
| const unsigned int AS_CS_SET_AS_DISCONNECTIONS = 3016; |
| // uses STANDARD_REQUEST header followed by: |
| unsigned int listLength; |
| unsigned int list[MAX_VISITOR_IDS_PER_MESSAGE]; // visitors |
| // Request 3017. Update audio server proximity are codes. |
| // proximity area codes are used to determine which area codes are |
| // dialed by simply prefixing a 1 and which can potentially benefit from |
| // long distance access companies (10-10-321 for example) |
| const unsigned int AS_CS_SET_AS_PROXIMITY_AREA_CODES = 3017; |
| // uses STANDARD_REQUEST header followed by: |
| unsigned int listLength; |
| unsigned char list[MAX_AREA_CODES][AREA CODE_LENGTH]; |
|
The following are Messages/Requests audio servers
[0135]2001-
200mreceive from control servers
3001-
300p:
|
|
| // Request 1000. Request audio server status |
| const unsigned int CS_AS_PROVIDE_STATUS = 1000; |
| // uses only STANDARD_REQUEST header. |
| // Request 1001. Request audio server configuration information |
| const unsigned int CS_AS_PROVIDE_CONFIGURATION = 1001; |
| // uses only STANDARD_REQUEST header. |
| // Request 1002. Notify of status change |
| const unsigned int CS_AS_NOTIFY_STATUS_CHANGE = 1002; |
| // uses only STANDARD_REQUEST header. |
| // Request 1003. Notify control server shutting down |
| const unsigned int CS_AS_NOTIFY_SHUTTING_DOWN = 1003; |
| // uses only STANDARD_REQUEST header. |
| // Request 1004(external) and 1005 (internal). dial a call |
| const unsigned int CS_AS_DIAL_EXTERNAL_NUMBER = 1004; |
| const unsigned int CS_AS_DIAL_INTERNAL_NUMBER = 1005; |
| // uses STANDARD_REQUEST header followed by: |
| unsigned int webServerID; // webServerID of the original connection point |
| unsigned int visitorID; | // user/visitor ID of the requester |
| unsigned int lineReservationTime; | // how long to reserve the line |
| unsigned int accessCode; | // entry to allow user to confirm call |
| unsigned char phoneNumberToDial |
| [FORMATTED_PHONE_NUMBER_LENGTH + 1]; |
| // Request 1006 and 1007. Reserve a line |
| const unsigned int CS_AS_RESERVE_EXTERNAL_LINE = 1006; |
| const unsigned int CS_AS_RESERVE_INTERNAL_LINE = 1007; |
| // uses STANDARD_REQUEST header followed by: |
| unsigned int webServerID; // webServerID of the original connection point |
| unsigned int visitorID; // user/visitor ID of the requester |
| unsigned int lineReservationTime; // how long to reserve the line |
| unsigned int accessCode; // entry to allow user to confirm call |
| // Request 1008. Disconnect a call. |
| const unsigned int CS_AS_DISCONNECT_CALL = 1008; |
| // uses STANDARD_REQUEST header followed by: |
| unsigned int visitorID; | // user/visitor ID of the requester |
| unsigned int boardNumber; | // used to specify board key |
| unsigned int portNumber; | // used to specify port key |
| // Request 1009. process a command. |
| const unsigned int CS_AS_PROCESS_COMMAND = 1009; |
| // uses STANDARD_REQUEST header followed by: |
| unsigned int visitorID; | // user/visitor ID of the requester |
| unsigned int boardNumber; | // where connected |
| unsigned int portNumber; | // where connected |
| unsigned int commandToProcess; | // which command |
| //Request 1010. Play an audio file |
| const unsigned int CS_AS_PLAY_AUDIO_FILE = 1010; |
| // uses STANDARD_REQUEST header followed by: |
| unsigned int visitorID; | // user/visitor ID of the requester |
| unsigned int webServerID; | // web server where the request originated |
| unsigned int boardNumber; | // where connected |
| unsigned int portNumber; | // where connected |
| unsigned char interruptIfPlaying; | // T or F, Should a file that is currently |
| | // playing be interrupted or |
| | // should the file be played when the |
| | // current file is finished. |
| unsigned char setFileOnly; | // T or F Should the file only be set |
| | // and not actually started? |
| unsigned char fileNameToPlay[MAX_PATH + 1]; |
| // Request 1011. Notify audio server to disconnect all calls |
| // Control server shutting down or web server shutting down (if only one web server) |
| const unsigned int CS_AS_DISCONNECT_ALL_CALLS = 1011; |
| // uses only STANDARD_REQUEST header. |
| // Request 1012. Notify audio server to update configuration (optional) |
| const unsigned int CS_AS_SET_AS_CONFIGURATION = 1012 |
| // uses STANDARD_REQUEST header followed by: |
|
Audio Server Configuration Information[0136]
Configuration of the audio servers is controlled by several configuration files located in the same or parallel directory as the executable files of audio servers
[0137]1001-
100n. The first configuration file, configuration.as, is the main file used to control the operation of the audio servers. It contains multiple parameters. The parameters and their uses are described below.
|
|
| Parameter | sample value | Usage |
|
| audio server: | 19,adams1 | Identifies the audio |
| | server and its ID |
| listening port number: | 83 | TCP and UDP port to |
| | listen on |
| mode: | voip | determines which mode |
| or phone | the audio server is |
| | running in |
| logging directory: | | directory for logging |
| | information |
| log configuration: | true | log configuration on |
| | startup |
| log warnings: | false | whether or not to log |
| | warnings |
| log informational messages: | true | log informational |
| | messages |
| log requests: | false | Whether or not to log |
| | individual command and |
| | play/set requests |
| log usage: | true | log audio server usage |
| accepting new connections: | true | allow new connections |
| | on startup |
| admin consoles: | false | can configuration be |
| | updated externally |
| admin password: | xyz | password required for |
| | admin functions |
| min udp request threads: | 1 | min UDP request |
| | processing threads |
| max udp request threads: | 12 | max UDP request |
| | processing threads |
| delta udp request threads: | 2 | delta number of UDP |
| | threads to start/stop |
| min tcp request threads: | 4 | min number of TCP |
| | request processing |
| | threads |
| max tcp request threads: | 20 | max number of TCP |
| | request processing |
| | threads |
| delta tcp request threads: | 2 | delta number of TCP |
| | threads to start/stop |
| min telephony event threads: | 2 | min telephony event |
| | processing threads |
| max telephony event threads: | 24 | max telephony event |
| | processing threads |
| delta telephony event threads: | 2 | delta number of |
| | telephony threads to |
| | start/stop |
| max concurrent udp datagrams: | 100 | max number of |
| | concurrent UDP requests |
| max concurrent tcp connections: | 100 | max number of |
| | concurrent TCP requests |
| ports per telephony event | 2 | number of telephony |
| listening thread: | | ports to manage per |
| | telephony event listening |
| | thread |
| event slots per telephony port: | 10 | Number of simultaneous |
| | pending events for each |
| | telephony or VoIP port |
| number of sending threads: | 10 | number of threads used |
| | to send messages to |
| | control servers |
| local area code: | 650 | local area code where |
| | audio server is installed |
| proximity area codes: | 408, 415, | proximity area codes (no |
| 510 | long distance service) |
| dial local area code: | false | force dial local area code |
| | if number is in same area |
| | code |
| extension length: | 5 | in internal mode, how |
| | long are extensions |
| outside line sequence: | | sequence to obtain |
| | an outside line (only used |
| | when in internal mode) |
| disable caller id sequence: | *82, | how to disable caller |
| | ID blocking on outbound |
| | calls (not recommended) |
| disable call waiting sequence: | *70, | how to disable call |
| | waiting on outbound |
| | calls |
| long distance code: | 1 | code to dial for long |
| | distance numbers |
| dial type: | out | configured for dial-in or |
| | dial-out |
| allow private lines: | yes | allow private lines to be |
| | configured (if not, |
| | private lines are ignored) |
| connection type: | external | connected to PSTN |
| | (external) or PBX |
| | (internal) |
| line reservation time: | | number of minutes to |
| | reserve a line before |
| | freeing the line for |
| | another's use. |
| max active calls: | 1000 | number of active calls to |
| | support (work in |
| | conjunction with the |
| | authorization key) |
| authorization key: | 12QW- | controls which host and |
| ER45-SD89 | at what capability level |
| | the audio server is |
| | running (enterprise, |
| | workgroup or developer, |
| | see below) |
| max call inactive time: | 10 | how long before auto |
| | disconnect |
| heart beat interval: | 120 | how long to wait |
| | between each attempt to |
| | contact the associated |
| | control servers |
| generic audio file | xxx | Where the generic |
| message directory: | | messages are stored |
| | (i.e., you pressed . . . ) |
| audio message file format: | wave | The format of the audio |
| | files stored on the audio |
| | server. Telephony vendor |
| | specific |
| vocoder type: | G711, | If in VoIP mode, the |
| G723, | vocoder to use |
| G729, |
| or GSM |
| vocoder file: | filename.ext | if in VoIP mode the |
| | vocoder program file to |
| | use (optional) |
| voip interface: | adams1c | If in VoIP mode the |
| | network interface to use |
| | for VoIP traffic |
| rtp base port number: | 5000 | if in VoIP mode the first |
| | UDP port to use for |
| | RTP/RTCP traffic |
| ivr ports per dsp: | 4 | If in VoIP mode the |
| | number of channels |
| | (connections) each DSP |
| | can process |
|
The second configuration file, control_servers.as, lists the control servers that the audio server will support. For example:[0138]
control server:12,udp,82,adams1[0139]
This example states that: (a) the control server ID is 12; (b) UDP is the preferred protocol to use when making or responding to requests; (c)[0140]82 is the UDP and TCP port control server300 will be listening on; (d) the name of the primary IP interface to use when contacting this control server is adams1; and (e) no secondary IP interface has been specified.
The third configuration file, allowed_numbers.as, stores a list of allowed area codes, area code and prefixes, complete numbers and domains. If any of this information is specified then all requests to the audio server must be listed in this file or the call will be disallowed. It is highly unlikely that the “number” directive will ever be used as it drastically limits the numbers that can be dialed. It is more likely that the area code directive will be the only one used. This information is only consulted if the audio server is configured in dial-out mode. This information is transferred to control server
[0141]300 on startup. Control server
300 performs all the list checking. For example:
| |
| |
| area code:303 # denver, |
| area code:714 # orange county, |
| area code & prefix:650654 |
| number:6506549999 |
| domain: intensifi.org # VoIP only |
| |
The fourth configuration file, disallowed_numbers.as, stores the list of disallowed area codes, prefixes, area code and prefixes, complete numbers and domains. If any of this information is specified then all requests to the audio server will be checked against this information before the call is allowed. This information is only consulted if the audio server is configured in dial-out mode. This information is transferred to control server
[0142]300 on startup. Control server
300 performs all the list checking. For example:
|
|
| area code:800 | # No toll free numbers as caller id cannot be blocked. |
| area code:888 | # No toll free numbers as caller id cannot be blocked. |
| area code:900 | # No toll numbers |
| prefix:976 | # No toll numbers |
| area code & prefix:650506 # competitor |
| area code & prefix:650767 # time |
| number:6502937000 |
| domain: badcompany.com # VoIP only |
|
The fifth configuration file, directory_mapping.as, lists the directories to locate audio files for specific control server and web-server add-in component mappings. For example:[0143]
directory mapping:12,1,C:\Program Files\isound\Audio Server\audio\CS12\WS1[0144]
This example states: for control server ID #12 and web server add-in[0145]component ID #1, use C:\Program Files\isound\Audio Server\audio\CS12\WS1 as the root directory when searching for audio files to play.
The sixth configuration file, telephony_boards.as, lists the telephony protocols (telephony board vendor specific, natural Microsystems, Dialogic, etc.) to run on each installed telephony board. Examples:
[0146] | |
| |
| board:0,1ps0 #standard analog lines |
| board:0,wnk0 #T1 or E1 trunks |
| board:0,nocc,voip #board used for VoIP processing |
| |
This first example states: for board 0, use the lps0 protocol for all ports on the board. This sample is for Natural Microsystems boards which use analog interfaces in the United States.[0147]
This second example states: for board 0, use the wink 0 protocol for all ports on the board. This sample is for Natural Microsystems boards which use digital interfaces in the United States.[0148]
This third example states: for board 0, use the nocc protocol for all ports on the board. This sample is for Natural Microsystems boards which uses voice over internet protocol (VoIP) in any country.[0149]
The seventh configuration file, port_phone_numbers.as, lists the phone numbers for each board port combination, and whether or not the port is for a private line. For example:[0150]
phone number:1,0,650-654-9999,p # outside line connected[0151]
This example shows that[0152]board 1, port 0 has a telephone number of 650-654-9999 and that it is private. Private ports will never be reserved or dialed out on by control server300. If the port was not private (no ,p suffix) and the audio server and control server300 were configured for dial-in mode, the telephone number listed would be delivered to the user as the telephone number to dial to initiate an audio session. For digital telephony trunks (T1 or E1 at present) that have the same telephony number or extension for all ports (24 in the case of a T1) the telephone number is repeated or omitted for each subsequent board/port combination. If the telephone number is omitted, it is assumed that the most recent previously specified telephone number is to be used for the port in question. If the audio server is in VoIP mode, only entries that do not correspond to boards used for VoIP mode are actually processed. For boards configured for digital interfaces (T1 or E1), it is not normally possible to give each port a unique identifier (such as a telephone number) as these identifiers are shared across all ports (hunt group, etc.). In dial-out mode this is not an issue as the first unused port is simply used to initiate the connection (VoIP or telephony). In the case of in-bound connections (dial-in mode), it is not possible to know ahead of time on which physical port the call will arrive. In this case, the audio server maintains a list of expected connections. If any connections are expected, incoming calls are answered, and the access codes entered are compared with the expected access codes. If there is a match, the call is allowed to complete. If not, the call is rejected (dropped or disconnected.) Digital connections (T1 or E1) can be programmed to provide a direct inward dial number (DID) for each inbound call. In this case the audio server can be configured to expect certain DID number for each T1 or E1 trunk. These DID number can be given to users to dial in on (if configured in dial-in mode). If incoming calls contain previously reserved DID numbers the audio server will answer the call. If the incoming call does not contain a previously reserved DID number the call is rejected. The difference between using DID numbers and not is that with DID numbers that call only has to be answered if it is originating on a reserved DID number. If DID numbers are not used the call has to be answered and the user prompted for their access code before it can be determined if this is a legitimate call. Incoming connections are also dropped if no connections are expected and the port or audio server is not configured for private ports.
Inventive Interface Software[0153]
In accordance with the present invention, one can access and control audio files of[0154]embodiment1000 with any software that can run inside or outside of a web browser environment on a user's computer. Inside the web browser environment, standard HTML pages or Netscape plug-ins (Macromedia Flash, etc.) or Microsoft ActiveX controls can all have access to the audio feature set. Outside the web browser environment, preferably, any software that can emulate a web browser while making requests to a web server with web server add-in components1501-150ninstalled, can use and control the inventive audio environment. In further embodiments of the present invention, a direct interface to control server300 can enable use of the audio feature set without having to run inside a web browser. This interface can be initiated by using a software library linked into the user's application, or by sending correctly formatted messages directly to the control server (via its wire protocol), and responding to the messages the control server sends back.
In a preferred embodiment of the present invention, an inventive Java applet (isound.class) or an ActiveX control (isound.dll) and its associated inventive Javascript, VB Script, or ECMA script, runs in each web page to be enabled with inventive functionality. In the preferred embodiment, it uses standard HTTP requests and responses to communicate with web server add-in components[0155]1501-150nlocated atweb site10. Because of the use of HTTP and its associated TCP overhead, it is preferable to minimize the number of connects/disconnects (use HTTP keep-alive header) and to keep requests and replies small (single network packet).
In a preferred embodiment of the present invention, the inventive Java Applet (isound.class) is designed to run in any Java Virtual Machine (JVM) running at JDK 1.0.2 or better. The inventive ActiveX control (isound.dll) is designed to run in Internet Explorer V3.0 or better. Neither has a visual interface other than being able to set its background color. Their sole purpose is to relay commands and audio play/set requests to web server add-in components[0156]1501-150nrunning atembodiment1000. JavaScript or VBScript dedicated to visual animation (not to be confused with the command/request JavaScript or VB Script described below) running in the invention-enabled page calls the inventive Java applet or ActiveX control methods to process commands and requests. Two available functions of the inventive Java applet or ActiveX control are playAudioFile (takes the audio file and appropriate extension URL as an argument) and processCommand (takes the command as argument). An additional function of the inventive Java applet or ActiveX control is called internally when the applet's or ActiveX control's stop method is called. The applet's or control's stop method is called at the following times: (a) the web page where the applet or control is running is being destroyed and (b) the web page where the applet or control is running is being minimized. In either case, this internal method callsembodiment1000 to stop the playing of audio files.
In addition to the inventive Java Applet or ActiveX control, the same functions can be accomplished by having “invention controlling” JavaScript or VBScript embedded in the web page “Visit” URLs which correspond to the commands or correspond to audio files to be played. The normal technique is to use the JavaScript Image object (the Image object can be used to retrieve any content, not just images) and set its source (.src property) to the URL to be retrieved (“visited”). For example, to pause the audio the following JavaScript sequence might be used.
[0157] | |
| |
| var pauseISound = new Image(); |
| pauseISound.src = ’/isound/commands/pause' |
| |
The Java applet or ActiveX control method is normally preferred as it gives more control as to the request/response process. The JavaScript or VB Script method is intended only for browsers which do not support Java or JavaScript calling Java applet or ActiveX control methods. The only current known Java-capable example of this is Microsoft Internet Explorer running on the Macintosh.[0158]
The following is a sample configuration of the inventive Java applet in an HTML file (web page content). In this example, the inventive applet (isound.class) is located in the /isound/client directory off of the web server root directory.
[0159] |
|
| <applet name =“isoundA” code=“isound.class” codebase = |
| “/isound/client” width=“1” |
| height=“1”> |
| <param name=“isoundCommandsURL” value=“/isound/commands”> |
| <param name=“StopAudioCommand” value=“eject”> |
In this case the user's web browser is told to load the applet (isound.class) from the /isound/client directory off of the web server root directory. The web page that contains this code can be anywhere in the web server document root directory or one of its subdirectories.[0160]
The applet has two optional parameters: isoundCommandsURL and StopAudioCommand. isoundCommandsURL defines the location of the inventive audio commands directory relative to the web server root. The default value is: “/isound/commands”. If this is the location used on a web server, it does not need to be specified. StopAudioCommand is the inventive audio command to issue when audio is to be stopped if the user is leaving a page or the page is being minimized. The idea is to stop audio automatically when the user leaves the location where it is appropriate. The default is “eject” if no value is specified.[0161]
The inventive controlling JavaScript or VBScript performs similar finctions. A code sample is as follows:
[0162] |
|
| function isoundProcessCommand(isoundCommand) { |
| var now, URLToVisit, dummy; |
| var theApplet = null; |
| if (useApplet == true) { |
| if (isIE == true) { |
| document.isoundControllerID.processCommand(isoundCommand); |
| } else { |
| theApplet = |
| document.layers[‘appletsL’].document.applets[‘isoundController’]; |
| theApplet.processCommand(isoundCommand); |
| } |
| } else { |
| now = new Date(); |
| URLToVisit = new Image(); |
| URLToVisit.onerror = null; |
| URLToVisit.src = isoundCommandRoot + ‘/’ + isoundCommand + |
| ‘?’ + now.getTime() + document.location; |
| } |
| } |
|
The function isoundProcessCommand takes the inventive command to execute as a parameter. If the web page is to use Java applets' methods for control, the applets are called. If the web page is not to use the applet, a JavaScript Image object is constructed to “access” the appropriate isound command URL. Note that appending a question mark plus the value of the current time in seconds since Jan. 1, 1970 via the now.getTime( ) function call always forms a unique query string. This is to insure that the web browser does not use a cached response to a previous “access” of the same isound command URL. This should not normally be necessary as all requests to web server add-in components respond by telling the web browser, and any intervening equipment such as proxy servers, not to cache the response (uses pragma: no-cache and sets the expiration date to a time in the past). Unfortunately since some of these devices do not function as specified; the unique query string forces the web browser to access the web server each time the request is made as the number of seconds since Jan. 1, 1970 is constantly changing. The document.location reference appends the filename of the current web page to the request. This value is used by the web server add-in component and the control server to determine if the command is from the same page as the original audio file play or set request (below).
[0163] |
|
| function isoundPlayAudioFile(isoundAudioFile) { |
| var now, URLToVisit; |
| var theApplet = null; |
| if (useApplet == true) { |
| if (isIE == true) { |
| theApplet = document.isoundControllerID; |
| theApplet.playAudioFile(isoundAudioFile); |
| theApplet = |
| document.layers[‘appletsL’].document.applets[‘isoundController’]; |
| theApplet.playAudioFile(isoundAudioFile); |
| } |
| } else { |
| now = new Date(); |
| URLTo Visit = new Image(); |
| URLToVisit.onerror = null; |
| URLToVisit.src = isoundAudioFile + ‘?’ + now.getTime() + |
| document.location(); |
The function isoundPlayAudioFile takes the inventive audio file to play as a parameter. If the web page is to use Java applets' methods for control, the applets are called. If the web page is not to use the applet, a JavaScript Image object is constructed to “access” the appropriate isound command URL. Note that appending a question mark plus the value of the current time in seconds since Jan. 1, 1970 via the now. getTime( ) function call always forms a unique query string. This is to insure that the web browser does not use a cached response to a previous “access” of the same isound command URL. This should not normally be necessary as all requests to web server add-in components respond to tell the web browser, and any intervening equipment such as proxy servers, not to cache the response (uses pragma no-cache and sets the expiration date to a time in the past). Unfortunately since some of these devices do not function as specified; the unique query string forces the web browser to access the web server each time the request is made as the number of seconds since Jan. 1, 1970 is constantly changing. The document. location reference appends the filename of the current web page to the request. This value is used by the web server add-in component and the control server to determine if a command is from the same page as the original audio file play or set request.[0164]
Blended Background[0165]
In accordance with one embodiment of the present invention, which embodiment is useful for components embedded in web pages, a user application sets its background color to blend into the web page. This enables all components embedded in web pages which do not have any visual interface to blend into web pages, and not cause themselves to be noticed thereon.[0166]
Enterprise, Workgroup, and Developer Configurations[0167]
Embodiments of the present invention have three configurations: (a) enterprise (corresponding to[0168]embodiment1000 shown in FIG. 1 and described in detail above); (b) workgroup; and (c) developer. All configurations (embodiment1000 shown in FIG. 1) utilize computer telephony boards using a PCI bus interface to insure maximum capacity and throughput. Advantageously, PCI based boards allow a large number of boards to be installed in each audio server. In addition, users can record messages for later follow-up. Additionally the enterprise configuration integrates with call-center products to allow the user to “transfer” to a live person when and where appropriate. As described above, the enterprise can perform live monitoring and live re-configuration.
The workgroup configuration comprises two web servers and two audio servers. Each audio server in the workgroup has a maximum of two computer telephony boards installed. If these boards are digital, for example, T1, E1, ISDN, only one trunk per board is supported. This provides a maximum configuration of 96 ports in the United States where T1 trunks (24 ports per T1) are in common use. Additionally the workgroup edition does not have the capability to integrate with call center products to provide a transfer to a live person where applicable, however, the workgroup is capable of live monitoring, but not live reconfiguration.[0169]
In the developer configuration, all components, the web-server add-in components, the control server, and the audio servers all run on the same machine. Thus, the developer can only provide audio capability to a single web server at a time. One computer telephony board is all that is supported. If the selection is for a digital interface, for example, T1, E1 or ISDN, only one such trunk is supported. This allows for analog line ports counts of 4 or 8 ports; or digital line counts of 24 or 30 ports (T1 or E1). No matter how many physical ports are installed the developer configuration can only have two ports active at the same time. The developer configuration does have the capability to integrate with call center products to provide a transfer to a live person where applicable for testing. The developer edition is capable of live monitoring, but not live reconfiguration.[0170]
For example, although some embodiments of the present invention comprise components that run on different processors or computers, it is within the spirit of the present invention for some or all of the above-described components to be implemented as software modules that run on the same hardware. Further, although the web server add-in components were depicted as being separate, but associated with a web server, it should be clear to those of ordinary skill in the art that a web server may be embodied in a form to include a web server add-in component as a part thereof.[0171]
Stand-Alone Player[0172]
In accordance with one embodiment of the present invention, an inventive player is installed on a user machine or appliance, which player takes compressed multimedia content delivered via, for example, a network and plays it back at normal speed, or at any speed dictated by the user. In accordance with this embodiment of the present invention, the compressed presentation can be delivered: (a) in whole or in chunks; (b) live (for example, as a web request); or (c) as an e-mail attachment. Further, in accordance with one embodiment of this aspect of the present invention, the presentation contains multimedia content, thus no telephone call or VoIP session is required. If the user wants to connect live to a call center or to a person referenced, for example, within the presentation, the connection can be made using, for example, and without limitation, H.323 or other VoIP protocols such as Session Initiation protocol—(SIP) or media gateway protocol (MGCP). In most cases, Real Time Protocol (RTP) and real time control protocol (RTCP) are used to transmit the actual audio. Further, the player can be a standalone application, or it can be integrated into a web browser or an e-mail client using technologies such as, for example, Java or ActiveX. The compression/decompression algorithms can be any one of a number of compression/decompression algorithms that are well known to those of ordinary skill in the art.[0173]
As has been discussed above, one aspect of the present invention comprises a computer or an Internet appliance (embodiments of both are well known to those of ordinary skill in the art) which is connected to a data network (for example, and without limitation, the Internet and an internal Intranet) running a visual display application (for example, and without limitation, a web browser such as Netscape Navigator or Microsoft Internet Explorer) and a telephone (of any type) for playback of audio connected to the public telephone network (“PSTN”) or an internal telephone network such as (for example, and without limitation, an internal telephone network provided by a private business or branch exchange (“PBX”) or a Voice over Internet Protocol (VoIP) network (Internet or intranet)). As is well known to those of ordinary skill in the art, a web browser is a computer hardware/software/firmware application capable of processing and displaying information encoded in, for example, HTML, DHTML, VRML. SGML and XML languages. It is noted that the terms computer or Internet appliance is used in the broadest sense, including the manner in which the terms are known to those of ordinary skill in the art. It is further noted that the term data network is used in the broadest sense, including the manner in which the term is known to those of ordinary skill in the art. It is still further noted that the term visual display application is used in the broadest sense, including the manner in which the term is known to those of ordinary skill in the art. It is yet still further noted that the term telephone is used in the broadest sense, including the manner in which the term is known to those of ordinary skill in the art.[0174]
It should be noted that the present invention, in its broadest aspect, combines two or more separate networks into a unified tool for multimedia information delivery. In other aspects of the present invention, the unified tool provides at least an aspect (for example, a visual aspect) of the multimedia information over one of the separate networks and provides at least another aspect (for example a visual aspect) of the multimedia information over another one of the separate networks. In still other aspects of the present invention, the unified tool provides synchronized multimedia information delivery over the two or more separate networks.[0175]
Although embodiments of the present invention have been described wherein one of the media comprises visual display provided over a data network and another one of the media comprises audio display over a telephone network, it should be understood that the present invention is not limited to this. For example, it is within the spirit of the present invention to include embodiments wherein audio networks include radio or wireless or the Internet (VoIP for example). Additionally, the present invention contemplates use of other networks for multimedia transmission in the broadest sense of the term such as, without limitation, cable television, satellite networks and so forth. It should be clear to those of ordinary skill in the art how such further embodiments may be implemented by one of ordinary skill in the art without undue experimentation with reference to the detailed description set forth above.[0176]
It is within the spirit of the present invention that further embodiments include: (a) recording of information transmitted by users to the audio servers over the telephone network (in accordance with methods that are well known to those of ordinary skill in the art); (b) enable transfer of a user to a live operator or acceptance of user commands, by capture of commands issued over the telephone network by key presses of the telephone pad (in accordance with methods that are well known to those of ordinary skill in the art), and/or by capture of voice commands issued over the telephone network by voice recognition mechanisms (in accordance with methods that are well known to those of ordinary skill in the art), and/or capture of data commands issued using action request forms transmitted by the user's web browser. Lastly, in accordance with some such embodiments, it is contemplated that embodiment would cause information to be displayed on the user's computer screen in response to the user input.[0177]
Lastly, it is within the spirit of the present invention that the above-described embodiments (wherein interaction between, for example, a user appliance and an audio-capable apparatus produces multimedia presentations) include interactions involving user appliances such as, for example, wireless appliances (for example, wireless telephones) or other appliances having limited capacity displays such as, for example, small LCD screen displays. In addition to interactions that have been described above for controlling presentation of content (visual as well as audio), embodiments of the present invention, including embodiments described in detail above, include interactions wherein interactions for controlling the presentation are performed by audio. For example, to control presentation of audio files, the interaction can entail predetermined sequences of keypresses which produce audio (via a keypad on a telephone) or one spoken commands. The audio input can be analyzed in accordance with any one of a number of methods that are well known to those of ordinary skill in the art (including voice recognition techniques) to produce commands that can be provided to audio servers and/or or web server add-in components. Such audio input analysis can be provided, for example, by an audio server or by processing power or equipment available to an audio server. In accordance with such embodiments, such interactions can also be used to direct the display of visual content as well as audio content. For example, such audio commands can be used to direct the display to portions of visual content having numeric or alphanumeric designations or to subjects (interpreted by, for example, voice recognition techniques).[0178]
Features of[0179]Embodiment2000 that Will be Referred to Generally as IntenseConference and IntenseChat
In accordance with one embodiment of the present invention, a user can create a conference call without using a dedicated operator or service. In particular, to do this in accordance with the present invention, the user uses a local application (or a web browser based application) to list participants in the conference call in accordance with any one of a number of methods that are well known to those of ordinary skill in the art. As an option, the list may specify whether the participants are to be called, or whether they will call-in. The list may further specify the date and time of the conference call. Next, in accordance with this embodiment, the participants' telephone numbers, voice mail addresses, and/or e-mail addresses are keyed-in or looked up from a database accessible from the embodiment (for example, a local database, a database integrated with a contact manager, a corporate database, and so forth). Next, each participant is notified of the conference call particulars via e-mail and/or voice mail in accordance with any one of a number of methods that are well known to those of ordinary skill in the art. In particular, for the case of voice mail, a notification telephone call can go to a direct voice mail extension for the participant, or to the participant's normal telephone line. If the notification telephone call goes to the participant's normal line, and the participant answers, the participant is asked: (a) whether he/she wants to hear the conference call particulars at that time; (b) whether the conference call particulars should be forwarded by e-mail; or (c) whether the embodiment should call back in a moment to leave the conference call particulars (in which case the called participant will know not to answer the call, and let it go into voice mail). Further, the user can have the notification telephone call and the conference call directed to a different telephone number, if desired; in which case the different telephone number can be transmitted at that time. In accordance with this embodiment, a copy of the conference call can be created and stored in a file, and a transcription of the copy may be created, if requested, prior to setting up the conference call or during the call, by providing predetermined signaling over the telephone connection. In either case, the resulting copy may be transmitted to the user, for example, at a predetermined voice mail address, the transcription may be delivered to the user, for example, at a predetermined e-mail address, or the user may access the copy or the transcription directly by accessing the system for delivery. Still further, written material can be read during the telephone conference call using any one of a number of text to speech (TTS) methods that are well known to those of ordinary skill in the art. In accordance with this embodiment, commands to the conference call system can be given via voice input, or via input using a telephone keypad, or via input using a computer keyboard. During the conference, participants can view a computer interface, for example provided at a web site, to determine which participants are connected. A participant would access the web site and obtain a list of present participants and a list of all potential participants. A command button would be used by a user who wishes to participate. The command would be received, for example, an IntenseConference add-in and transmitted, for example, in turn, to a web server add-in component. The web server add-in component would place an appropriate request with an audio server. Lastly, in accordance with this embodiment, keyboard input received from a keyboard-only-user can be converted to speech using any one of a number of text to speech (TTS) methods that are well known to those of ordinary skill in the art, and likewise audio content can be transcribed to text for keyboard-only-clients using any one of a number of voice recognition methods that are well known to those of ordinary skill in the art.[0180]
In accordance with a variation of the above-described embodiment of the present invention, a chat can be set up in a manner similar to that described above with respect to setting up a conference call. The chat setup is advantageously used to set up ad-hoc conference calls, i.e., not pre-arranged calls like conference calls. In accordance with this embodiment, keyboard input received from a keyboard-only-user can be converted to speech using any one of a number of text to speech (TTS) methods that are well known to those of ordinary skill in the art, and likewise audio content can be transcribed to text for keyboard-only-clients using any one of a number of voice recognition methods that are well known to those of ordinary skill in the art.[0181]
FIG. 2 shows a block diagram of a web site that is enhanced by[0182]embodiment2000 of the present invention to provide the above-described features; referred to below as IntenseConference and IntenseChat. As shown in FIG. 2,web site2010 is enhanced with IntenseConference add-in2020 which receives requests from users over a network, for example, the Internet and/or an Intranet, to set up and/or attend and/or determine the status of a conference call. As further shown in FIG. 2, IntenseConference add-in2020 receives a list of participants from a user, which list may specify, among other things, whether the participants will be called to set up the conference or whether they will call in to the conference. As an option, IntenseConference add-in2020 may access a data base (for example, a company data base) to obtain participants' telephone numbers, voice mail addresses and/or e-mail addresses (these data may also be submitted with the list by the user). As further shown in FIG. 2, IntenseConference add-in2020 updatesconference data base2030. As further shown in FIG. 2,conference coordinator process2040 refers toconference data base2030 to transmit conference notification messages toe-mail server2050. Then,e-mail server2050 transmits e-mail notification messages to the conference attendees. As further shown in FIG. 2,e-mail server2050 may also be enhanced with IntenseConference add-in2060 which, like IntenseConference add-in2020, receives requests from users to set up and/or attend a conference call. IntenseConference add-in2060, like IntenseConference add-in2020, updatesconference data base2030. As further shown in FIG. 2,conference coordinator process2040 refers toconference data base2030 to transmit conference notification messages to audio conference server add-in2070 inaudio server2080.Audio server2080 then sends voice mail notification messages to conference attendees.
In order to effectuate the conference, prior to the set-up time, IntenseConference add-in[0183]2020 obtains relevant conference information such as, without limitation, topic, user names, telephone connection information, and so forth fromconference data base2030. The conference information is then transmitted toconference server2070 inaudio server2080.Audio server2080 utilizes equipment such as, for example, computer telephony boards2090 to place calls to, or receive calls from, the conference attendees, for example, overPSTN2100, through PBX2110, over a network VoIP2120, and so forth to create a conference connection. As shown in FIG. 2,conference server2070 may comprise voice recognition engine2130 and/or recording/speech-to-text engine2140 for use in a manner that was described in detail above. Various transcriptions may be saved, for example, inconference data base2030 for later access and/or retrieval using IntenseConference add-in2020 or2060 as an intermediary. It should be understood that any part of the audio portion of the conference may be converted to text by using speech-to-text engine2140 for transmission to an attendee who cannot, for example, perceive the audio. In this case, the user may connect to a data port onaudio server2080. Likewise, a user may enter text on a keyboard, transmit it toaudio server2080 through the data port, and a text-to-speech engine will convert it to speech. Similarly, a document may be converted to speech for use in the conference, by, for example, havingconference server2070 retrieve it fromconference data base2030. Lastly, users may interact with IntenseConference add-in2020 during the conference to obtain information such as, for example, participant status.
As further shown in FIG. 2, IntenseChat add-in[0184]2150 enhancesaudio server2080 to enable users to dial-in to a common connection for an on-going conference.
Features of[0185]Embodiment3000 that Will be Referred to Generally as IntenseDetour
In accordance with one embodiment of the present invention, predetermined web sites and/or predetermined directories of predetermined web sites are masked so that predetermined users cannot access content contained therein. In accordance with this embodiment, a mask can be used (a) to exclude from viewing or (b) to permit viewing of content by predetermined organizations or predetermined personnel in predetermined organizations. In accordance with one such embodiment, for example, a list of users whose output is masked is maintained so that it is accessible by, for example, a web server add-in component or by a control server with which a web server add-in component communicates. For example, in accordance with this one such embodiment, a user can be specified, for example, to receive: (a) no content, (b) different content from other users, or (c) targeted content. Advantageously, in accordance with this one such embodiment, a predetermined user may be easily detected when he/she attempts to connect from an office because, for example, his/her IP address is associated as having been registered to the predetermined user. In this case, “undesirable” users may have their access screened. However, a problem may arise if the undesirable user, for example, goes home with his/her computer, and connects via an ISP from which he/she cannot be detected because he/she used an IP address that is different from the registered one. To solve this problem, in accordance with one aspect of this one such embodiment, whenever a request for content first comes from an “undesirable” user, he/she is sent an identifier by, for example, a web server add-in component, the identifier being, for example, an HTTP cookie, which identifies him/her as such. The identifier could be generated by any component such as a control server, or could be obtained from any other system with which the inventive embodiment can interact. This cookie (received while the user was connected at the office) will be identified whenever he/she tries to connect later (using his/her computer), and he/she will be given the same masked content he/she would have received at the office. Additionally, in accordance with another aspect of this one such embodiment, a list of telephone numbers or telephone number subsets (area code and prefix) is maintained for undesirable users. If an undesirable user is detected via his/her telephone number, he/she is thusly flagged for future requests, and a connection thereto is disallowed. The detection of the telephone number may be made, for example, by a web server add-in component, a control server (see for example, embodiment[0186]1000), or an audio server (see for example, embodiment1000).
In addition, in accordance with one embodiment of the present invention, a web server add-in can route users to different content based on, for example, browser type and/or unique user identification. Advantageously, this embodiment of the present invention is more efficient and secure than an embodiment that performs a similar function by sending code in the form of the web pages (embodied in HTML, Javascript, and so forth) to make decisions based on browser type or an identification embedded in the user's browser, which decisions are made in accordance with any one of a number of methods that are well known to those of ordinary skill in the art.[0187]
In accordance with one embodiment of the present invention, web server response headers can be augmented (for example, the server name/OS name can be changed and/or the response header case can be changed) so that a hacker will not know what type of web server is in use. Advantageously, this makes hacking the web site more difficult.[0188]
FIG. 3 shows a block diagram of a web site that is enhanced by[0189]embodiment3000 of the present invention to provide the above-described features; referred to below as IntenseDetour. As shown in FIG. 3, IntenseDetour server-side add-in3010 detects the user's web browser type whenever a request is transmitted thereto to web site3020. If a more optimal set of content exists for the request, the request is modified to be redirected to the “best” content for the browser. This determination related to “best” content may be based, for example, on predetermined lists. Then, the modified request is transmitted toweb server3030 for retrieval of “redirected”web pages3040. If there is no modification of the request, the unmodified request is transmitted toweb server3030 for retrieval ofstandard web pages3050.
In accordance with one alternative of this embodiment of IntenseDetour, if response headers are to obfuscated, all response headers are modified so that it is not easy to determine the web server or the operating system in use.[0190]
In accordance with another alternative of this embodiment of IntenseDetour, predetermined areas (for example, domains) of a network, for example, the Internet and/or an Intranet, are blocked. In this case, IntenseDetour add-in[0191]3010 consultsdata base3060 to determine the type of response a user is to permitted to receive. In one alternative of this embodiment, IntenseDetour add-in3010 sends a cookie that records blocking identification information back to the user. Advantageously, this will enable the user to be blocked even though the user may later connect from an unblocked domain. Appropriate entries indata base3060 enable selective blocking, for example, to restrict user access to predetermined web sites or to predetermined data bases.
Features of[0192]Embodiment4000 that Will be Referred to Generally as IntenseID
In accordance with one aspect of the another embodiment of the present invention, an inventive web browser add-in is added to user browser software. The web browser add-in provides a unique user id to identify the user as an individual person and/or to identify the user's browser. The unique user id can be generated using any one of a number of methods that are well known to those of ordinary skill in the art. Whenever the user accesses the web site, the unique user id is transferred thereto and is interpreted by a web server add-in component or the web server itself. The unique user id can then be used to mask content sent to and from web sites the user visits. Alternatively, the unique user ID can be used to allow access to content, or it can be used to provide personalized content. Advantageously, in accordance with this embodiment of the present invention, the user is given control over how he/she is identified to specific web sites and what information is sent to him/her.[0193]
FIG. 4 shows a block diagram of a web site that is enhanced by[0194]embodiment4000 of the present invention to provide the above-described feature; referred to below as IntenseID. As shown in FIG. 4, in accordance with one embodiment of IntenseID, a user's web browser in a user's device such as, for example,user computer4010, has been enhanced by client-side plug-in4015. In accordance with this embodiment of the present invention, client-side plug-in4015 manages cookies sent from web servers at standard web sites such as, for example,standard web server4020. Client-side plug-in4015 manages the cookies to enable the user to control the information that is returned whenever cookies are sent back to the originating web server. Client-side plug-in4015 does this by storing cookies in IntenseID data base4030 (for example, associated with client-side plug-in4015), and by modifying the cookies when they are stored, and/or by modifying the cookies prior to returning them to the originating web server.
As also shown in FIG. 4, in accordance with another embodiment of IntenseID,[0195]web server4040 is augmented with IntenseID add-in4050. Whenweb server4040 has been augmented with IntenseID add-in4050, the user's web browser is notified thereof by, for example, an appropriate notification in, for example, an HTTP header. If the user's web browser does not use client-side plug-in4015, IntenseID add-in4050 does not interact with user messages. However, if the user's browser uses client-side plug-in4015, encrypted messages are sent back and forth between IntenseID add-in4040 and client-side plug-in4015. Then, in all following cases, the user controls which information is sent to specific servers and/or specific domains.
If the user enables it, client-side plug-in[0196]4015 will send a unique identifier (generated by the client) to uniquely identify the user. Advantageously, this unique identifier can be used by the web server to uniquely identify users that visit the web site.
Those skilled in the art will recognize that the foregoing description has been presented for the sake of illustration and description only. As such, it is not intended to be exhaustive or to limit the invention to the precise form disclosed.[0197]
Features of[0198]Embodiment5000 that Will be Referred to Generally as IntenseSpeed
In accordance with one embodiment of the present invention, for efficiency and speed of operation, any and all web content can be preloaded before it is needed and/or have its HTTP headers augmented, for example, with Expires and Cache-Control headers to indicate for how long the content is valid. This can be done for all types of web content, whether configured as any one of HTML, Javascript, Java, ActiveX Control, VBScript, ECMA Script, GIF images, JPEG images, PNG images, Macromedia Flash and Director movies, and so forth. In accordance with this one embodiment of the present invention, this functionality is packaged as a server component (which server component, for example, augments headers) and a client component (which client component, for example, requests content pre-loading). Each component is optional, i.e., it is not required that they be used together. For users that only want to pre-load web content, the client component is all that is needed. For web sites that only want to augment headers, but not pre-load web content, only the server component is needed. In accordance with one aspect of this embodiment of the present invention, the pre-loads can be stopped whenever the embodiment detects that the user has chosen a different direction of the web site (or presentation) so that previously requested pre-loads no longer make sense. For example, this may occur whenever the user leaves the web site, or whenever a predetermined number of pre-loaded pages has been reached, or when the user has branched to a predetermined section of the web site, and so forth.[0199]
In accordance with one embodiment of the present invention, a user application, for example, the user's web browser, can navigate a web page to a predetermined location when a predetermined number of files have been pre-loaded. This capability can be built into the web browser, or a signal can be sent from the web server that it is doing the pre-loading. This allows a web page author to verify that certain content is in the web browser cache before navigating to a web page that needs it for proper display. This activity can be performed by the pre-loading application, in the form of an applet, an ActiveX control, VBScript, or Javascript, and so forth or the web server add-in component could redirect the user's web browser to another web page after the last requested file of a batch had been sent to the user.[0200]
In accordance with one embodiment of the present invention, the applet, for example, can be programmed to start automatically whenever a web page is loaded by the user's web browser, or it can be programmed to start after a predetermined delay. Alternatively, the applet can be programmed so that it will start only after it is sent a command, for example, from a web server add-in component or from other applets, ActiveX controls, VBScript, or Javascript, and so forth. Lastly, the applet can be programmed to pause and resume operation in response to commands sent, for example, from a web server add-in component or other applets, ActiveX controls, VBScript or Javascript, and so forth. Advantageously, this last option enables traffic to be handled over a link to a web site in accordance with a priority scheme to ensure that the link will not be overused when other traffic has higher priority, i.e., traffic such as, for example, audio triggering commands that have higher priority.[0201]
Preferred embodiments of the present invention, utilize an inventive method and apparatus for interaction between a web browser and a web server. The inventive method and apparatus are discussed in detail below.[0202]
In the prior art, whenever a user's web browser requests information from a web server, the scenario is as follows: (a) the user's web browser requests information from the web server over a network link (one or more Internet links and/or one or more Intranet links); (b) the user's web browser waits for the information to arrive; (c) the user's web browser reads (displays) the information to the user; and (d) the cycle is repeated. The read (display) information step can take quite a long time and, during this long time, the network link back to the web server is dormant. Further, information arriving over the network usually contains large amounts of “dead” time, i.e., dead time from a computer's perspective. Web sites are also contracting for network capacity regardless of whether it is actually used or not. This unused bandwidth could be used to provide a better experience for its customers.[0203]
As a result of the above, given their understanding that current information transmission techniques involve substantial network delays, most web authors create web pages with a great deal of information. This is done, so that a user is rewarded with a great deal of information to offset his/her dislike for the wait he/she will most likely experience in obtaining that information. Unfortunately, it can take a great deal of time to fully absorb all the information on these crowded web pages.[0204]
As one can readily appreciate from the above, a need exists in the art for method and apparatus for efficient information transmission between user interfaces such as, for example, web browsers and web servers.[0205]
In addition to above-identified problem of obtaining information from a web server, whenever a user requests that information be re-displayed, in accordance with the prior art, the user's web browser will ask the originating web server if it is safe to use a local copy of the information or whether there is a need to have the web server re-send the information. As one can readily appreciate from this, a network “conversation” must take place between the user's web browser and the originating web server for each piece of information to be re-displayed.[0206]
As one can readily appreciate from the above, a need exists in the art for method and apparatus for efficiently utilizing information to reduce and/or eliminate network conversations arising due to re-display requests of previously requested web content.[0207]
Embodiments of a first aspect of the present invention (relating to interaction between a user interface such as, for example, a web browser and a web server) advantageously satisfy the above-identified need in the art and provide method and apparatus for efficient information transmission between user interfaces such as, for example, web browsers and web servers. Advantageously, embodiments of such method and apparatus will enable web site authors to develop web sites having series of screens with logical flows that better present information. Further, such efficient information transmission will enable a user to progress from screen to screen to obtain desired information without delays. In accordance with one embodiment of a method in accordance with the first aspect of the present invention (relating to interaction between a user interface such as, for example, a web browser and a web server), whenever information is first requested from a web server by a user interface such as, for example, a user's web browser, the web server transmits the information to the user and the user stores (pre-loads) the information in the web browser's local storage, i.e., “cache”, or other storage that is accessible by the web browser. Further, in accordance with a preferred embodiment, such transmission occurs in the background before the information is needed by the web browser for display to the user.[0208]
Embodiments of a second aspect of the present invention (relating to interaction between a user interface such as, for example, a web browser and a web server) advantageously satisfy the above-identified need in the art and provide method and apparatus for efficiently utilizing information to reduce and/or eliminate network conversations arising due to re-send requests. In accordance with the second aspect of the present invention (relating to interaction between a user interface such as, for example, a web browser and a web server), the web server gives information an expiration date and time. Then, when the information is needed for display, the user's web browser displays it from the stored copy as long as the date and time, at the time of display, is earlier than the expiration date and time of the copy. Advantageously, embodiments of the second aspect of the present invention (relating to interaction between a user interface such as, for example, a web browser and a web server) minimize network bandwidth requirements for a web user.[0209]
As one can readily appreciate from the above, embodiments of the present invention (relating to interaction between a user interface such as, for example, a web browser and a web server) are advantageous in that the same network connection can be used to transfer multiple files if the file size for each is known instead of destroying and recreating the connection for each requested file. Since destroying and creating and destroying connections is very expensive in terms of network and time requirements; elimination of these steps enables the same network to support many more users without requiring expensive upgrades. In addition, there is less loading on web servers that provide information, thereby enabling them to support many more users without requiring expensive upgrades or additional servers.[0210]
Pre-Load[0211]
A preferred embodiment of the present invention (relating to interaction between a user interface such as, for example, a web browser and a web server) is embodied in two inventive components. As shown in FIG. 5, in the preferred embodiment, first component[0212]500 is implemented as a Java applet or ActiveX control that is downloaded from a web server (for example, web server1001) and runs in Java or ActiveX control enabled web browser25, for example, Netscape Navigator/Communicator or Microsoft Internet Explorer. First component500 requests files from the web server and verifies that they are loaded into a cache associated with the user's web browser. In accordance with the preferred embodiment of the present invention (relating to interaction between a user interface such as, for example, a web browser and a web server), the Java applet or ActiveX control has no visual interface, i.e., all of the tasks it performs occur in the background.
In accordance with this embodiment of the present invention (relating to interaction between a user interface such as, for example, a web browser and a web server), an embodiment of first component[0213]500, for example, the inventive Java applet or ActiveX control, is included in any Hyper Text Markup Language (HTML) document (web page), where needed. A preferred location for first component500 is a web page that presents the user with many choices (such as, for example, a top level menu), or in the first page of a sequence of pages (such as, for example, a presentation). For placement in a top level menu web page, in accordance with a preferred embodiment of the present invention (relating to interaction between a user interface such as, for example, a web browser and a web server), the Java applet or ActiveX control is written so that it pre-loads all web pages (and embedded images therefor) for each choice that a user might likely make. For placement in the first page of a sequence of pages, in accordance with a preferred embodiment of the present invention (relating to interaction between a user interface such as, for example, a web browser and a web server), the Java applet or ActiveX control is written to pre-load all following pages (and embedded images therefor). As a practical matter, care should be taken not to load too many pages/images as this may actually decrease performance and give erroneous readings as to which sections of a web site have been visited by a user. The web content to be preloaded can be specified directly by the author of the web site, it can be determined automatically from web site logs, or it can be determined by a combination of the two.
In operation, first component[0214]500 contains the names of files for example, up to 100 files, (for example, as applet parameters) to request from the originating web server that transferred it to the user's web browser. These file names can be specified directly or they can be set by other components of, for example, embodiment1000 (see the description below in connection with FIG. 5) that analyze web server log files and insert the appropriate filenames in the appropriate files. For example, if ten (10) pages are normally accessed from a given page, the web site author can determine this fact, and enter the ten (10) filenames as a parameter (filexx) to the IntenseSpeed Java applet or ActiveX control; or a web server add-in component can perform the web site log analysis and enter the filenames to pre-load as parameters (filexx) to the pre-loading Java applet or ActiveX control. This task can be performed using any one of a number of methods that are well known to one of ordinary skill in the art of analyzing web server logs.
In accordance with the preferred embodiment, the Java applet or ActiveX control can normally only request files from the originating web server because of Java and ActiveX security requirements. In accordance with a preferred embodiment, the Java applet or the ActiveX control then requests the files from the originating web server, one at a time, by a separate execution thread (threading is optional). The separate execution thread is used preferably to verify that the file requests only occur in the background, and do not slow the web browser as it displays requested web pages. Additionally, the user's web browser can tell the Java applet or ActiveX control to continue requesting files even though the page where the Java applet or ActiveX control is running is being destroyed. In this manner, the Java applet's or the ActiveX control's requesting thread can be told to continue requesting files until it is done, no matter what the user has requested. In response to the requests, in a preferred embodiment, the requested files are loaded into the web browser's local storage (cache) because browser (uniform resource locator) URL methods are used or WinInet functions are used (in an ActiveX implementation). It is also within the scope of the present invention (relating to interaction between a user interface such as, for example, a web browser and a web server) to transfer the files using lower level TCP/IP protocols from within the Java applet, but by doing this, the user's web browser would not know to load the transmitted files into its cache without taking further action. Such further action may be implemented in accordance with one of many methods which are known to those of ordinary skill in the art. Only by using built-in web browser URL methods or WinInet methods is one assured (without taking further action) that the requested files will be loaded into the cache, and thus be available to the user's web browser when it is subsequently asked to display them. In accordance with the preferred embodiment, the Java applet is complied with any JDK 1.0.2 or better compiler such as those supplied by Sun, Microsoft or Symantec, and the ActiveX control is compiled with Microsoft Visual C++, Visual Basic, or the equivalent.[0215]
Time Dates[0216]
In a preferred embodiment of the present invention (relating to interaction between a user interface such as, for example, a web browser and a web server),[0217]second component600 is a module that is integrated with the web server providing the files requested by the user's web browser.Second module600 sets an expiration date and time of static files and provides further performance enhancing information. The structure and application programming interface (API) of this web server sidesecond component600 changes based on the type of web server in use. For example: (a) with Netscape Enterprise and FastTrack web servers,second component200 is implemented as a Netscape Application Programming Interface (NSAPI) add-in; (b) with Microsoft's Internet Information Server (IIS),second component600 is implemented as an Internet Server Application Programming Interface (ISAPI) add-in; and (c) with Apache from the Apache group,second component600 is implemented as an Apache module following the specifications of the Apache module API (C-API). In all cases, it is preferred (but not required) to implementsecond component600 using the C++ programming language. On Microsoft platforms, Microsoft's Visual C++ is the preferred compilation language and environment and on Unix or Linux platforms, GNU C/C++ is the preferred compilation language and environment.
In accordance with the present invention (relating to interaction between a user interface such as, for example, a web browser and a web server), for each static request that arrives at the web server,[0218]second component600 inserts, for example, a Hyper Text Transfer Protocol (“HTTP”) “Expires” header for a certain date/time in the future (the “expiration date/time”), and optionally includes other performance enhancing HTTP headers that the web server does not normally include for static files. In practice it is usually best to set the expiration date/time to at most a day in advance.
In operation, files specified as parameters to the inventive Java applet or ActiveX control are all requested soon after the web page using the inventive applet or ActiveX control is loaded by the user's web browser. From that point on, the user's web browser that initiated the request via the inventive Java applet or ActiveX control will not request updated status or try to reload any of the previously requested files until after the expiration date/time or the previously requested files are forced out of the web browser's cache. As should be clear to those of ordinary skill in the art, files can be forced out of the web browser's cache if more files are inserted into the cache than will fit. Note, on some versions of Microsoft's Internet Explorer (MSIE) browser, a verification of status request (HTTP conditional GET) may still occur. This is because of a poor implementation on Microsoft's part, as they did not follow the HTTP specification correctly. However, even with the buggy MSIE implementation, embodiments of the present invention (relating to interaction between a web browser and a web server) are still useful as they instruct MSIE to only perform a conditional get and not just to blindly reload the entire requested file even though it is not needed. The ActiveX implementation of the embodiment of the present invention can work around this limitation which hampers Java applets in an MSIE environment. This is because ActiveX controls have direct access to the WinInet functions which control the MSIE browser cache.[0219]
The following is an embodiment of first component
[0220]500 in the form of a Java applet in an HTML file (web page content). In this embodiment, the applet entitled “ispeed.class” is located in a directory /ispeed/client which is appended to a web server root directory.
|
|
| <applet name =“ispeedA” code=“ispeed.class” codebase = “/ispeed/client” |
| width=“1” height=“1”> |
| <param name =“files” value=“26”> |
| <param name =“file1” value=“/introduction/introduction2.html”> |
| <param name =“file2” value=“/images/happy_face_1.gif”> |
| <param name =“file3” value=“/images/happy_face_2.gif”> |
| <param name =“file4” value=“/images/happy_face_3.gif”> |
| <param name =“file5” value=“/introduction/introduction3.html”> |
| <param name =“file6” value=“/images/no_downloads.gif”> |
| <param name =“file7” value=“/images/no_plugins.gif”> |
| <param name =“file8” value=“/introduction/introduction4.html”> |
| <param name =“file9” |
| value=“/images/real_player_download_instructions.gif”> |
| <param name =“file10” value=“/introduction/introduction5.html”> |
| <param name =“file11” value=“/introduction/introduction6.html”> |
| <param name =“file12” value=“/introduction/introduction7.html”> |
| <param name =“file13” value=“/introduction/introduction8.html”> |
| <param name =“file14” value=“/introduction/introduction9.html”> |
| <param name =“file15” value=“/introduction/introduction10.html”> |
| <param name =“file16” value=“/introduction/introduction11.html”> |
| <param name =“file17” value=“/images/lightbulb.gif”> |
| <param name =“file18” value=“/introduction/introduction12.html”> |
| <param name =“file19” value=“/images/checkbox.gif”> |
| <param name =“file20” value=“/images/arrow_right.gif”> |
| <param name =“file21” value=“/introduction/introduction13.html”> |
| <param name =“file22” value=“/introduction/introduction14.html”> |
| <param name =“file23” value=“/introduction/introduction15.html”> |
| <param name =“file24” value=“/introduction/introduction16.html”> |
| <param name =“file25” value=“/introduction/introduction17.html”> |
| <param name =“file26” value=“/introduction/introduction18.html”> |
| <param name =stop_on_stop_event” value=“true”> |
| </applet> |
|
In accordance with the present invention (relating to interaction between a web browser and a web server), the web page tells the web browser to load the applet (ispeed.class) from the /ispeed/client directory appended to the web server root directory. The web page that contains this code can be anywhere in the web server document root directory or one of its subdirectories.[0221]
In accordance with the above-described embodiment of the inventive applet, the applet loads twenty six files via the files parameter. Further, each file to be loaded is specified by the fileXX parameter. Note that absolute file names (denoted) by the leading slash are required in the above-described embodiment, however it should be clear to those of ordinary skill in the art that embodiments of the present invention are not thusly limited and include embodiment which load files from the same directory or sub-directory of the web page from which the applet is loaded (this is termed relative loading).[0222]
Also note the optional “stop_on_stop_event” parameter. If this parameter is specified and its value is true, the applet will stop requesting files be loaded into the web browser's cache after an applet stop event is received. The stop event occurs when the web page is being unloaded from the web browser. If the “stop on stop event” parameter is not specified, loading will continue until complete, even if the page where it is loaded is being destroyed or unloaded.[0223]
The following details the steps the Java applet or the ActiveX control takes whenever the user's web browser loads the Java applet or the ActiveX control: (a) read the files parameter to determine the number of files to load; (b) size an array to handle the number of files to be pre-loaded; (c) read the specific filexx parameters and load them into the array at the appropriate index (files are loaded in the order specified); and (d) determine whether the “stop_on_stop_event” parameter is specified with a value of true (if so set an appropriate flag).[0224]
The following details the steps the Java applet or the ActiveX control takes whenever the user's web browser starts the Java applet or the ActiveX control: (a) start a downloading thread function to load the files specified in the filename array (see step c above) and (b) exit the start function.[0225]
The following details the steps the Java applet or the ActiveX control takes on a stop event, i.e., whenever the user's web browser is destroying or hiding the web page where the applet or control is located: (a) if “stop_on_stop_event” was specified as true, set a flag to tell the loading thread to stop after the next requested file is downloaded and (b) exit the stop function.[0226]
The following details the steps the Java applet or ActiveX control takes whenever the user's browser executes the loading function which may or may not run in a separate thread. For each file in the array: (a) form a URL to the originating web server based on the file name/location; (b) tell the user's web browser to use its cache to satisfy the request (if in cache); (c) open the connection to the web server using a Java URLConnection object or WinInet function, respectively; (d) read the file contents into a function local buffer 128 bytes-4 kilobytes at a time and discard buffer contents after each read until all file contents have been read (this step forces the user's web browser to request and download the file into its local cache); (e) after each file, pause a tenth of a second before continuing(optional); and (f) if the stop flag has been set (via the stop event function described in detail above), exit; if not, advance to the next file in the list and continue with step a until all requested files have been attempted.[0227]
The following is an embodiment of[0228]second component600. Note that, in accordance with the present invention (relating to interaction between a user interface such as, for example, a web browser and a web server), the specific configuration ofsecond component600 is different based on the particular web server with which it is associated. Specifically, there are separate embodiments ofsecond component600 for each supported web server and operating system. This is because each of these web servers takes a different approach to answering web browser requests. For example, a Netscape web server allows optional add-ins such assecond component600 to be called for each request or only for specific requests (based on location or type). A Microsoft IIS Web Server requires an optional code for each request regardless of the location or type of the requested file. This can be mitigated by requesting that the optional code only be called during specific request handling phases. Finally, optional Apache modules can be configured to be called for all requests or just requests for a specific server, document directory or document type. In that case, the Apache modules must be recompiled and relinked for each optional module which is installed.
The following is an embodiment of inventive
[0229]second component600 using a Netscape FastTrack Web Server on Microsoft's Windows NT operating system. The file is normally named obj.conf and is located in the web server specific configuration directory. In this example, the web server add-in module, entitled “ispeed.dll” is located in the C:\Program Files\ispeed\bin directory. Configuration command lines specific to the present invention are underlined.
|
|
| Init fn=flex−init access=“C:/Program Files/Netscape/Server/httpd-adams1/logs/access” |
| format.access“%Ses−>client.ip% − %Req−>vars.auth−user% [%SYSDATE%] \“%Req− |
| >reqb.clf−request%\” %Req−>srvhdrs.clf−status% %Req−>srvhdrs.content−length% %Req− |
| >headers.if−modified−since%” |
| Init fn=load−types mime−types=mime.types |
| Init funcs=“ISD−−init,ISD−service” fn=load−modules shlib=“C:/Program |
| Files/ispeed/bin/ispeed.dll” |
| Init fn=ISD−init expiration_delta_time=240 |
| <Object name=default> |
| NameTrans fn=pfx2dir from=/ns−icons dir=“C:/Program Files/Netscape/Server/ns−icons” |
| NameTrans fn=pft2dir from=/mc−icons dir=“C:/Program Files/Netscape/Server/ns−icons” |
| NameTrans fn=document−root root=“C:/Program Files/Netscape/Server/docs” |
| PathCheck fn=nt−uri−clean |
| PathCheck fn=find−pathinfo |
| PathCheck fn=find−index index−names=“index.html,home.html,index.htm,home.htm” |
| ObjectType fn=type−by−extension |
| ObjectType fn=force−type type=text/plain |
| Service method=(GET|HEAD) type=magnus−internal/imagemap fn=imagemap |
| Service method=(GET|HEAD) type=magnus−internal/directory fn=index−common |
| Service method=GET type=*˜magnus−internal/* fn=ISD−service |
| Service method=(GET|HEAD) type=*˜magnus−internal/* fn=send−file |
| AddLog fn=flex−log name=“access” |
| </Object> |
| <Object name=cgi> |
| ObjectType fn=force−type type=magnus−internal/cgi |
| Service fn=send−cgi |
| </Object> |
|
The first underlined line above indicates that the Netscape FastTrack web server is to load the IntenseSpeed dynamic link library (dll) from the specified directory. The Netscape web server is also told to be aware that two functions in this dll (ISD-init and ISD-service) may be called from this dll.[0230]
The second underlined line above initializes second component[0231]600 (calls ISD-init) to set a expiration date240 minutes in advance (four hours) for any static information that is requested via the “expiration_delta_time parameter”. Also in the above embodiment for Netscape servers, the expiration time applies to all documents (files) in any directory on the web server. However, a preferred embodiment enables the expiration time to be specified on a directory by directory basis if desired. Note that, in the preferred embodiment, for efficiency, this value is initialized once at web server startup time and not for each request. In another embodiment of thesecond component600, configuration styles are specified for later reference on a web server-wide or directory by directory basis. These styles specify different expiration times and approaches. The main approaches are based on time of request, time of modification or absolute time. Examples: style1=” ALL request plus two days three hours”; style2=” ALL modification plus two weeks one hour”; style3=” ALL fri Jan. 25, 2001 10:23:12 GMT”. Instead of the keyword ALL, different file types can be specified in Multi-purpose Internet Mail Exchange (MIME) type format (ex: text/html or image/gif”). Each directory where IntenseSpeed is applied would then reference the predefined style. Note that some styles are predefined for common expiration types (for example: 1 week, 1 quarter, etc.).
The third underlined line above calls the ISD-service function just before the built-in Netscape function send-file. Netscape's send-file is called for any static file being sent by the web server. The requirement with Netscape servers is that any dynamic content (changes on each request) be served by some other function. In accordance with the present invention (relating to interaction between a web browser and a web server), the ISD-service function inserts an HTTP “Expires” header and a Cache-Control header in the response (to be actually sent by Netscape's send-file) and then exits. Netscape's send-file then sends the requested file with all the headers (including the recently inserted “Expires” header and Cache-Control headers) back to the requesting user's web browser. The ISD-service function also optionally inserts other headers such as “Last-Modified-Date”, “Content-Length” and “Date” if the web server does not normally send them. For Netscape servers, this is not necessary as Netscape servers send all of this information for each static file request.[0232]
Thus, in accordance with the present invention (relating to interaction between a web browser and a web server),[0233]second component600 transmits the following information, or information from which the following information can be derived, along with each file requested by the user's web browser: (a) the size of the requested file; (b) the date and time that the item was last modified; (c) the current date and time according to the web server. Further, other embodiments of first component500 determine these items of information for files sent from web servers that do not already include this information.
The following details the steps[0234]second component600 takes upon being loaded: (a) determine the future expiration date/time from the appropriate initialization parameter or style; (b) verify this parameter as valid; and (c) set its value in a global value which will persist across all requests.
The following details the steps[0235]second component600 takes for each static request as it arrives: (a) calculate (if not an absolute expiration) and insert HTTP “Expires” and “Cache-Control” headers based on the global value stored in the initialization function above and the current date/time (one of ordinary skill in the art may refer to the IETF HTTP RFC and Microsoft's MSDN library for complete details); (b) insert the “Expires” header and the Cache-Control header into the HTTP response; and (c) determine whether other headers (“Last-Modified-Date, Content-Length, Date”) should be inserted in the response based on a compile time flag. If so, calculate and insert them, otherwise do not.
Although embodiments of first component[0236]500 were described as comprising a Java applet or an ActiveX control, it should be clear to those of ordinary skill in the art that the present invention (relating to interaction between a user interface such as, for example, a web browser and a web server) is not limited thusly limited. For example, embodiments of first component500 may be embodied in equivalents of applets, many of such equivalents being well known to those of ordinary skill in the art (one example being plugins of all sorts, including, without limitation, Microsoft ActiveX plugins, Javascript, ECMAScript, VBScript). In addition, embodiments of first component500 may also be embodied in software that is loaded, for example, from the web server and runs in the user's web browser. As should be readily appreciated by those of ordinary skill in the art, the software may be embodied in any suitable language such as, for example, in JavaScript, ECMAScript or VBScript.
FIG. 5 shows a block diagram of a web site that is enhanced by[0237]embodiment5000 of the present invention to provide the above-described feature; referred to herein as IntenseSpeed. As shown in FIG. 5, web page5010 is displayed on user device5020 (for example, an appliance or a computer such as a personal computer) by, for example, a web browser. In accordance withembodiment5000, web page5010 has been authored to include a Java applet, an ActiveX control, Javascript, VBScript, or a browser plug-in version of an IntenseSpeed client component,IntenseSpeed client component5060. Whenever a user makes a request toweb server5030 for a web page over network5025 (for example, the Internet, an Intranet, and so forth) using, for example, a Hyper Text Transfer Protocol (“HTTP”), standard-processweb server software5040 inweb server5030 looks up the request to determine: (a) whether the web page exists, and (b) whether the user is authorized to receive it. Such standard-processweb server software5040 is well known to those of ordinary skill in the art, some examples of which are Netscape, MS IIS, Apache, Domino and so forth. If the requested web page exists, standard-processweb server software5040 transmits the requested page back touser device5020 overnetwork5025 using HTTP. If IntenseSpeed server-side component5050 is installed and configured inweb server5030, IntenseSpeed server-side component5050 augments the HTTP response headers of the requested web page with expiration, cache-control size, and date headers (where not provided natively by standard process web server software5040).
The requested web page is displayed by the user's web browser and the IntenseSpeed client component[0238]5060 (for example, a Java applet, an ActiveX control, Javascript, VBScript, or browser plug-in, and so forth) begins to run on user'sdevice5020. There are many options for embodiments ofIntenseSpeed client component5060. In a first option,IntenseSpeed client component5060 operates on one or more lists of web content (HTML, DHTML, jpeg, gif, applets, and so forth), for example, list5070 (a list of web content identifiers) and/or list5080 (a list of links to web content), to be pre-loaded into the cache of the user's web browser. In accordance with the first option, list5070 and/or list5080 is specified: (a) explicitly in web page5010 by the web page author; or (b) by an external process that analyzes (i) web pages and/or (ii) web server logs at a web site. As shown in FIG. 5,backend analysis process5140 analyzesweb server logs5120 and/orweb pages5150, and inserts lists of web content identifiers and/or links to web content into web pages5150 (web pages5150 being accessible by web server5030). In a second option,IntenseSpeed client component5060 contacts a backend server component over network5025 (for example, usage add-incomponent5090 residing inweb server5030 or backend usage process5100). In response, the backend server component transmits the list of files to pre-load into the cache of the user's web page. As shown in FIG. 5, in one alternative of the second option, the list of files to pre-load is based upon usage data stored in usage database5110. As further shown in FIG. 5, the usage data obtained from usage database5110 is generated, for example, by an analysis ofweb server logs5120, for example, by backendusage analysis package5130. As should be clear to those of ordinary skill in the art, all backend processes described above can run on the same machine or on different machines.
As those of ordinary skill in the art readily appreciate, the web content that comprises the inventive client side software and/or web server content are typically stored on computer readable media at the client and/or server.[0239]
In accordance with another embodiment of the present invention, a mechanism is provided to load a web browser's cache outside of the web browser's runtime environment. In accordance with this embodiment, a separate, high performance application requests the web content, and loads it into the web browser's cache while leaving the web browser's cache in a state that is readable by the web browser. This embodiment of the present invention is useful for the following reason. A web browser typically attempts to display web content as it is being retrieved. Although this is useful for providing the user with an impression that something is happening, it delays the overall completion of the response. An external application, that operates in accordance with this embodiment of the present invention is advantageous because it can operate faster than the web browser since it does not have to spend any processing time on displaying content.[0240]
Features of[0241]Embodiment6000 that Will be Referred to Generally as IntenseSpeedSpiking
In accordance with one embodiment of the present invention, a seeding mechanism is provided by directing simulated Internet users to request web content, even though they do not need it themselves. When this is done, intervening caching servers in the Internet notice the web content as it is being requested and cache it. In accordance with this embodiment, the caching algorithm of caching servers in use (Inktomi for example) is determined, and simulated Internet users (geographically focused computers) are directed to make requests for this web content in a manner, and at a frequency, that will cause the caching servers to view the requested web content as popular. As a result, the caching servers will add the requested web content to its cached content database. Additional requests are made over time to continue tricking the caching servers into believing that the requested web content is popular, and that it should continue to be cached. As a result, reception of requested content is quicker when a real user requests the content.[0242]
FIG. 6 shows a block diagram of a web site that is enhanced by[0243]embodiment6000 of the present invention to provide the above-described feature; referred to below as IntenseSpeedSpiking. As shown in FIG. 6,IntenseSpeedSpiking Controller6005 sends messages over Internet6010 to one or more ofspikers6020,6030, and6040. As further shown in FIG. 6, spikers6020,6030, and6040 are disposed at Internet Service Provider (“ISP”) Points of Presence (“POP”)6050,6060, and6070, respectively. As still further shown in FIG. 6, a typical ISP POP comprises a caching server, a cache, and a spiker connected to an ISP LAN. In response to the messages received fromIntenseSpeedSpiking Controller6000, one or more ofspikers6020,6030, and6040 send requests for web content to customer web site6080. In accordance with this embodiment, spikers6020,6030, and6040 send such requests in a fashion and/or frequency (methods for determining such fashion and such frequency are well known to those of ordinary skill in the art) that one or more ofcaching servers6110,6120, and6130 take notice, and cache the responses to the requests from spikers6020,6030, and6040. Advantageously, in accordance with this embodiment of the present invention, users connected to the ISP POP which comprises spikers get a faster response when requesting web content.
Those skilled in the art will recognize that the foregoing description has been presented for the sake of illustration and description only. As such, it is not intended to be exhaustive or to limit the invention to the precise form disclosed.[0244]