Source: http://www.google.com/patents/US20030204579?dq=%22virtual+interaction+configuration%22
Timestamp: 2016-07-01 01:08:32
Document Index: 24654888

Matched Legal Cases: ['art 14', 'art 15', 'art 14', 'art 14', 'art 14', 'art 14', 'art 14', 'art 4', 'art 14', 'art 14', 'art 14']

Patent US20030204579 - Methods and applets for providing and contributing to an it network ... - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsThe invention is directed to methods for providing a network management service for a user's IT network by a network management service provider over the Internet. One of these methods comprises: sending mobile code to the user via the Internet, said mobile code, when running at the user's side, acts...http://www.google.com/patents/US20030204579?utm_source=gb-gplus-sharePatent US20030204579 - Methods and applets for providing and contributing to an it network management serviceAdvanced Patent SearchPublication numberUS20030204579 A1Publication typeApplicationApplication numberUS 10/132,418Publication dateOct 30, 2003Filing dateApr 26, 2002Priority dateApr 26, 2002Also published asUS7603450Publication number10132418, 132418, US 2003/0204579 A1, US 2003/204579 A1, US 20030204579 A1, US 20030204579A1, US 2003204579 A1, US 2003204579A1, US-A1-20030204579, US-A1-2003204579, US2003/0204579A1, US2003/204579A1, US20030204579 A1, US20030204579A1, US2003204579 A1, US2003204579A1InventorsManfred LutzOriginal AssigneeHewlett-Packard CompanyExport CitationBiBTeX, EndNote, RefManPatent Citations (5), Referenced by (29), Classifications (9), Legal Events (4) External Links: USPTO, USPTO Assignment, EspacenetMethods and applets for providing and contributing to an it network management service
DESCRIPTION OF THE DRAWINGS [0017] In the accompanying drawings: [0018] [0018]FIG. 1 shows a high-level architecture diagram of a system for providing a network management service over the Internet, including a user's IT network to be managed; [0019] [0019]FIG. 2 illustrates a first part of the processing of an exemplary network management request using the Telnet protocol; [0020] [0020]FIG. 3 illustrates the second part of the processing of the network management request of FIG. 2; [0021] [0021]FIG. 4 illustrates the processing of another exemplary network management request using the SNMP protocol; [0022] [0022]FIG. 5 shows an applet window output generated during the processing of FIG. 4; [0023] [0023]FIG. 6 is a state diagram of an applet; [0024] [0024]FIG. 7 is an example of a report page received as the result of the network management processing illustrated in FIG. 4; [0025] [0025]FIG. 8 is a timing diagram of a network-management-service HTTP session.
DESCRIPTION OF THE PREFERRED EMBODIMENTS [0026] [0026]FIG. 1 shows a high-level architecture diagram of a preferred embodiment of a system for providing a network management service, including a user's IT network to be managed. Before proceeding further with the description, however, a few items of the preferred embodiments will be discussed. [0027] In order to make the following description of preferred embodiments more comprehensible, systems and methods for providing a network management service over the Internet are described in an “integrated” view, i.e. in a manner which includes both the equipment and method steps of the service provider's side and the user's side, including the Internet between them. However, usually, but not necessarily, the service provider and the user will belong to different organizations situated at distinct locations, so that it is appropriate to claim systems and methods separately as they appear in the service provider's perspective, or, alternatively, the user perspective. Furthermore, in at least some of the preferred embodiments, mobile code in the form of an applet is sent to the user by traveling signals over the Internet. Such an applet can be considered as a separable product which incorporates a gateway functionality between the user's network and the service provider. Thus, it is appropriate to direct separate claims to an applet. [0028] The user's IT network to be managed is usually, but not necessarily, a non-public computer network (intranet), but it may also be a telecommunication network. The IT network may comprise network elements, such as routers, hosts, servers, workstations, desktop computers, peripheral devices such as printers and scanners, and operating systems, middleware and applications running on these devices. All these items can be network elements to be managed. [0029] The “management” of a network or network elements comprises a variety of tasks, such as diagnosis tasks, status detection, configuration checks, software version checks, error correcting or fixing tasks, setting tasks , and network-element-recognition tasks. Software update tasks may also be included provided that the required software updates are available in or transferred to the user's network. [0030] In order to be accessible by the service provider, the user's network elements have to be actuated for network management, for example they have to be reachable by SNMP, Telnet or DMI. [0031] In the preferred embodiments, the network to be managed (which is preferably a TCP/IP network) is connected to the Internet. Networks or part of networks which have no access to the Internet require conventional internal management architectures in which the management server is located within the (isolated) intranet. [0032] The term “mobile code” does not mean that the code actually moves while it is executing. Rather, the code is replicated, communicated to the user in the form of traveling signals over the Internet, and then executed there. An obstacle to the idea of mobile code is the differing representations and the interfaces between a program and the infrastructure across computing platforms. This obstacle is addressed by the Java technology in the form of Java programs called applets. Applets are programs that run inside a web browser. The code for an applet is stored on a web server and downloaded into the browser whenever a web page that contains the applet is accessed (see, for example, C. Horstmann, Computing Concepts with JAVA 2 Essentials, second edition, 1998, pages 139 to 142). Alternatively, but less preferred, it is also possible to keep the applet at the user's site after its first use and to reload the stored code rather than transmitting it each time the user sends a corresponding request. In alternative embodiments, the service provider's web page can enable the user to either download the applet from the service provider and execute it, or, when the required applet is already stored at the user's side, to cause the stored applet to be executed in the user's web browser. Web browser programs with Java applets are able to execute on multiple platforms, such as on PCs, Mackintoshes, UNIX workstations, and special web devices. Although the term “applet” was created in the context of the JAVA programming language, it is herein not used in the limited meaning of a JAVA applet, but rather stands for any mobile code embedded in or referenced by a web page, such that the mobile code is executed in the web browser when the web page is downloaded. For example, the C# programming language by Microsoft also provides such an applet functionality. In the future, there may be further suitable programming languages which enable the definition of applets. [0033] Usually a firewall gateway is arranged between an intranet and the Internet, and the firewall filters out (i.e. discards) incoming IP datagrams which cannot be assigned to a previous HTTP request originating from within the intranet. Accordingly, the firewall would filter out SNMP or Telnet commands coming from outside. [0034] Conventionally, network management is carried out by use of a network management station which is located within the intranet and communicates with the network elements with a network-management-protocol supported by the network and the network elements, such as SNMP or Telnet in a TCP/IP intranet. [0035] In contrast, in the disclosed embodiments, the network management server is located outside the network to be managed, at a network management service provider's site. The communication between the management server and the network elements to be managed is carried out over the Internet. To this end, network management commands are sent to the user via the Internet through the firewall in an encapsulated form. They are decapsulated by the applet running in the user's web browser. The applet then initiates the execution of a network management command in the user's network by forwarding it to the respective network element. In turn, the applet then receives result data from the network element in response to the command and forwards it to the network management server over the Internet. As will be explained below in more detail, an encapsulated network-management-protocol request is sent to the user as a web response (i.e. an HTTP response) to a corresponding web request (i.e. HTTP request) originating from the user. Therefore, from the perspective of the firewall, the incoming IP datagrams carrying the network management request are a response to an HTTP request returning to the origin of the request. Such datagrams can normally pass the firewall. [0036] In order to carry out network management steps, the applet needs to open files in order to read them and, optionally, write into them. (Actually, the applet needs to establish network connections to network elements; however, this is abstracted in UNIX to the opening of a file). In order to avoid the risk that an applet might do some kind of damage to a web visitor (for example, an applet could infect the visitor's host with a software virus), an applet is normally only authorized to establish a connection to its server over the Internet. In the preferred embodiments, the applet is therefore privileged so that it can establish the required network connections. The privilege can be achieved by signing the applet. The signature tells the user where the applet comes from. In order to authorize the applet for the required file access, the user has to accept the signed applet, either individually or generally. (see, for example, Horstmann, page 142). [0037] In the preferred embodiments, the applet mainly functions as a translator between web traffic and network-management protocol commands and messages. Preferably, the applet has no “knowledge” about the user's network, and no knowledge about the rules applied at the service provider's site, either. This has the advantage that the size of the applet's code can be kept relatively small, so that it can be easily loaded over the Internet. Different versions of the applet may be provided, for example versions depending on the actual network-management protocol to be used. For example, there may be different applet versions for SNMP and Telnet commands. [0038] In the preferred embodiments, data is transmitted over the Internet in an encrypted form, for example using HTTPS, in order to ensure that passwords and other sensitive data (such as host names) are kept secret. It is also possible to store such secret data momentarily in the user's browser rather than transmitting them. In this case, however, the applet combines the network-management protocol command received from the service provider (then without this data) with the stored data before executing the command. [0039] In the preferred embodiments, a network management service is performed in the framework of a session made up of HTTP requests and responses (Unless otherwise specified, “HTTP” is used in a broad sense in this description, which includes HTTPS and other similar protocols enabling web traffic). In HTTP the individual requests/responses are not related to one another. HTTP is therefore also called a stateless protocol. Due to HTTP's stateless nature, session management is carried out by the service provider. The individual HTTP requests/responses which together form a network management session are bound together under the control of the session management, for example by including a unique session identifier to each HTTP response belonging to a particular session in such a manner that the session identifier is returned by the user's web browser with the next request to the service provider. The session identifier can be included in a cookie, a URL or a hidden field in an HTML document sent to the user. It should be noted that, in the preferred embodiments, the number of turns (i.e. request-response pairs) may be not fixed since it may depend on the contents of a management response received during the management session under consideration. For example, it may depend on a management response received in the session whether and what further network information is required. [0040] In the preferred embodiments, a network management session proceeds in the following way: First, the user who wishes to obtain a network management service enters a start page of the service provider (in technical terms, the user sends an HTTP GET request with a request-URI (Uniform Resource Identifier) pointing to a start document of the service provider, whereupon the service provider returns the start document identified by the request-URI to the user; the start document is then displayed in the user's web browser, thus forming the “start page”). A session identifier indicative of the particular session now started is included in the start page. [0041] By actuating (clicking on) a hyperlink in the start page, the user sends another HTTP GET request to the service provider with which he confirms the request for a network management service. Optionally, a user authentication may be required at that stage to provide advanced personalized services. Then, the user has to enter authentication data (e.g. name and password) and send an HTTP POST request together with the authentication data). In the preferred embodiments, the service provider then returns an HTTP response in the form of an analyzer selection page. [0042] The analyzer selection page enables the user to pre-select one of several analyzers to be used in the subsequent service management carried out by the service provider. For example, the user may pre-select an analyzer which uses a certain management protocol (e.g. SNMP or Telnet) and works only on certain network elements (for example, on Cisco routers and switches). Such an analyzer pre-selection is advantageous (but not necessary) since it enables the applet which will be transferred to the user to be kept small. After having selected a certain analyzer in the analyzer selection page, the user sends the analyzer selection information with a further HTTP request to the service provider by activating a hyperlink in the analyzer selection page. [0043] In the preferred embodiments, as a next step, the service provider returns an analyzer initialization page as an HTTP response. The analyzer initialization page displayed in the user's browser enables the user to specify the network device or devices which shall be subjected to the network management and to enter network-specific authentication information (e.g. a device password) which is required to perform the network management with the specified device(s). The user then sends this authentication data to the service provider together with another HTTP request by activating a corresponding hyperlink in the analyzer initialization page. By sending this HTTP request, the user actually starts the network management process. It is likewise possible that the network-specific authentication data is stored at the user's site rather than being transmitted over the Internet, and is combined with the next response from the service provider (the authentication is then only performed after the applet has been started). [0044] Thereupon, the service provider returns, as an HTTP response, an applet page in which the code of the applet or a link to a location is included from where the applet code is to be fetched. When the applet page is loaded in the user's browser, the applet is started (i.e. initialized). In the preferred embodiments, the following network management steps are performed automatically under the control of an application for carrying out the network management service at the service provider's side, without intervention by the user. This application is also called “the analyzer”. [0045] In alternative embodiments, the applet is not transferred each time the user loads the applet page. Rather, the applet (or several versions of applets) can be stored at the user's side when the user loads the applet page for the first time. When the user then again loads the applet page, the already stored applet can be loaded in the user's browser. [0046] Depending on the particular web browser used, the user may then be required to expressly authorize the applet to open files (i.e. network connections) at the user's side. [0047] In some of the preferred embodiments, after the applet has been started, it sends an HTTP request to the service provider indicating that it is waiting for a network management request from the service provider. In alternative preferred embodiments, a network management request can be already contained in the applet page in the form of parameters; the applet then immediately carries out the first network management step. In the more preferred embodiments in which the applet is waiting, the analyzer returns an HTTP response containing an XML-encoded network management request. The applet decapsulates or unpacks the network-management-protocol request and sends it to the network device of the user's network, as specified in the request. Then, the applet waits for a response to the network-management-protocol-command from the network device. Upon receipt, the applet encapsulates or packs the response to the network-management-protocol-command from the network device in an XML-encoded network management response and sends it to the analyzer with an HTTP POST request. Then, the applet waits for a further network management request or an end-of execution instruction from the analyzer. [0048] The service provider's analyzer analyzes the network management response received from the user. The analyzer then returns an HTTP response which either includes a further network management request (whereupon the above-described operation of the applet is started again) or an end-of-execution instruction, if the network management procedure should be terminated. In this case, the analyzer also prepares a report about the results of the network management procedure which has been carried out. The report or a link to a report page is included in the HTTP response which contains the end-of-execution instruction. If the response includes a link to the report page, the applet sends a corresponding HTTP request to get the actual content of the report. Finally, the applet displays the report in the user's browser, and then terminates. In the disclosed embodiments, this is the end of the network management session. [0049] In the preferred embodiments, the network protocol commands sent to the network devices by the applet and their response received by the applet are displayed in the applet window of the user's browser so that the user can monitor all network management activities. [0050] Although it is generally preferred that the network management requests are generated automatically by the analyzer, and also the analysis and report generation is performed automatically by the analyzer at the provider's side, it is likewise possible for a human operator to define the network management requests at the service provider's side (and thereby to effectively log into the user's network remotely) and/or analyzes the results and prepares the final report. The network management requests defined by a human operator are encapsulated in the same manner as the above-described automatically generated requests. The manual intervention is transparent for the user, therefore no change is required at the user's side to enable it. [0051] In the preferred embodiments, the analyzer is grouped in two different functional parts, an application logic part and a presentation part. The two parts may be physically assigned to different hosts or only logically to different tasks. In the most preferred embodiments, the application logic part is assigned to an application host, and the presentation part to a presentation host which is the or one of the service provider's web servers. The representation part can be realized by any software system which can actively generate web pages, such as a servlet (using Java Server Pages by Sun Microsystems) or a corresponding Active Server Pages Program (Microsoft). The application logic part on the application host is responsible for the generation of the network management requests and the analysis of the network management results. On the other hand, the presentation part (the servlet) transforms a network management request received from the application logic part in a concrete request with regard to the particular network device to be addressed and the particular network-management-protocol to be used. The network management results received by the servlet are, in turn, translated in a protocol-independent representation and forwarded to the application logic part. Thus, in the preferred embodiments, the communication between the application logic part and the presentation part is carried out on a more abstract level than the communication between the presentation part and the user's applet over the Internet. Preferably, the data exchange between the application logic part and the presentation part is also based on XML. However, due to the different levels of abstraction, the two communication “layers” use different XML Document Type Definitions (DTDs) (see http://www.w3.org/tr/rec-xml) or XML Schemas (see www.w3.org/XML/Schema). [0052] Returning now to FIG. 1, it shows a high-level architecture diagram of a system for providing a network management service over the Internet. The system can be subdivided into three parts: (i) a service provider computer system 1; (ii) a user's network 2; and (iii) the Internet 3. [0053] Traffic between the user's network 2 and the Internet 3 passes through a gateway computer 4 which forms part of the user's network 2. A firewall gateway 5 is interposed between the gateway computer 4 and the Internet 3. As a prerequisite, a web client program, called browser 6, has to be installed (which is the case with all current operating systems) and started on the gateway computer 4. Upon loading a network-management-service applet page in the web browser 6, an applet 7 is run in the browser 6. Assigned to the applet 7 is an applet window 8 displayed in the graphical user interface of the web browser 6. [0054] The gateway computer 4 is networked with all network devices 9 a, 9 b of the user's network 2, or at least with all network devices which have access to the Internet 3. Commands and messages of a network management protocol (such as SNMP, Telnet, DMI, WBEM) can be transmitted within the user's network from the gateway computer 4 to the network devices 9 a, 9 b, and vice versa. The firewall 5 may be configured such that it discards all incoming IP datagrams apart from such IP datagrams representing HTTP responses which can be assigned to previous HTTP requests sent from the user's network 2 into the Internet 3. Therefore, management-protocol commands directed from the Internet 3 into the user's network 2 would be discarded by the firewall 5. [0055] The service provider system 1 comprises a web server host 10 and an application logic host 11. A web server program called “web server” 12 is installed on the web server host 10. The web server 12 receives HTTP requests from users from the Internet 3 and returns corresponding responses to the respective users via the Internet 3. An analyzer application, called “analyzer” 13 has two parts and is shared between the application logic host 11 and the web server host 10: An application logic part 14 is installed on the application logic host 11, and a presentation part 15 which runs as a servlet, implemented by Java Server Pages, within the web server 12 on the web server host 10. The application logic part 14 is responsible for the generation of network management requests and the analysis of network management results. It is implemented as a Java program, although any other (preferably object-oriented) suitable programming language can be used. The communication between the application logic part 14 and the servlet 15 will be explained in detail below. A user interface 16 enables an operator to communicate with the application logic part 14 if network management steps are to be carried out manually or any other manual intervention is required. [0056] It should be noted that no special network management software has to be installed nor any special network management devices are required in the user's network 2 for the network management. The only dedicated software required is the applet 7 running within the standard web browser 6. This applet, however, does not need not to be stored persistently within the user's network 2, but can be loaded via the Internet 3 each time the corresponding applet page is accessed by the user. [0057] [0057]FIGS. 2 and 3 illustrate the processing of an exemplary network management request using the Telnet protocol. In a first step S1, the application logic part 14 generates a network management request and forwards it to the servlet 15 in the form of an XML document, called abstract request document 21. In XML, every start tag, such as <request>, must have a corresponding end tag, such as </request>. Otherwise, a tag must be an empty tag, a tag that has an explicit slash at the end of it, as in <systeminfo/>. In the disclosed embodiments, the start and end tags are used to indicate “metacontent”. Metacontent is information about the contents bracketed between a start and an end tag. For example, the <request> tag indicates that the contents between its start and end tags is a network management request. Likewise, the <command> tag indicates that the content between its start and end tags is a network management command. In contrast, empty tags provide content rather than metacontent. For example, the <systeminfo> tag indicates itself that the network management command to be carried out is “systeminfo”. The systeminfo command is a command by which a network device shall return its system information. The XML document 21 is a logical (or abstract) representation of the systeminfo management command, since it does not specify concrete details required for the actual execution of the command (this will become clear in the next step where these details are added). The set of tags which can be used in the abstract communication between the application logic part 14 and the servlet 15 are defined in an XML DTD or Schema, which is called here an abstract DTD or Schema. [0058] In step S2, the servlet 15 receives the abstract XML request 21 and transforms it in a different, more concrete XML representation, which is called concrete XML document 22. In this transformation process, on the one hand, content is added and, on the other hand, content received from the application logic part 4 is transformed. The added content is, for example, information regarding the management protocol to be used (here: Telnet, indicated by the <http TelnetIn> tag as well as network-device-specific information, indicated by the <LoginInfoIn> tag. The translated content is here the logical systeminfo command which is translated in the corresponding Telnet command “sh version”. The XML DTD or Schema on which the concrete XML request is based, called concrete XML DTD or Schema, is different from the abstract DTD or Schema. On the one hand, it comprises additional metacontent tags, for example the above-mentioned tags indicating protocol-related and device-related contents. On the other hand, tags with the same meaning preferably have a different representation in the two DTDs or Schemas. For example, the <command> tag of the abstract DTD corresponds to the <CommandIn> tag of the concrete DTD. Furthermore, empty tags of the abstract DTD may be transformed in a pair of start and end tags for bracketing specific contents in the concrete representation. For example, the <systeminfo/> tag of the abstract XML document 21 is transformed in the sh version content bracketed between the <CommandLineIn> start and end tags. The concrete XML document 22 is then sent as an HTTP response to the user's gateway computer 4 via the Internet 3. [0059] In step S3 the received HTTP response is processed in the user's gateway computer 4 by the web browser 6 with the applet 7 which functions as a network management gateway. The applet 7 “translates” the received concrete XML management request 22 into a corresponding network-management-protocol command and forwards it within the user's network 2 to the network device 9 indicated in the XML management request 22. In the example of FIG. 2, the applet 7 translates the XML management request 22 into the Telnet command “sh version” and forwards it to the indicated network device (not expressly shown in the exemplary XML request 22 of FIG. 2), using the login information indicated by the contents of the <LoginInfoIn> tag of the XML request 22. [0060] In step S4 (FIG. 3) the network device 9 receives the Telnet “sh version” command, executes it and returns the requested version information (in the example of FIG. 3: “Cisco IOS 12.0.7(T)”) as a Telnet response to the applet 7 via the user's network 2. [0061] In step S5, the applet 7 translates the device's Telnet response in an XML document, called concrete XML response 23. The concrete XML response 23 corresponds to the original concrete XML request 22 apart from the following: (i) In order to differentiate input from output instead of the < . . . In> start and end tags, < . . . Out> tags are used; (ii) The response received from the network device 9 is added, it is bracketed between output start and end tags, here named <OutputLine>. Then, the applet 7 sends an HTTP POST request with the concrete XML response 23 in the body of the HTTP POST request to the web server 12 over the Internet 3. [0062] In step S6, the servlet 15 (which is part of the web server 12) transforms the concrete XML response 23 into a logical representation of the system information provided by the network device 9, called abstract XML response 24. The abstract XML response 24 corresponds to the abstract XML request 21, apart from a replacement of the original empty tag, which indicated the network management command, by corresponding metacontent start and end tags bracketing the content of the response to the command. In the example of FIG. 3, the empty tag <systeminfo/> has been replaced by <systeminfo> bracketing Cisco 12.0.7(T) . The servlet 15 forwards the abstract XML response 24 to the application logic part 14 running on the application logic host 11. Finally, the application logic part 14 analyzes the abstract XML response 24 and provides the user with a report (not shown in FIG. 3). [0063] [0063]FIG. 4 illustrates the processing of another exemplary management request based on the SNMP protocol. In FIG. 4 the steps corresponding to steps S1 and S6 of FIGS. 2 and 3 are not shown. [0064] In step T1 (which corresponds to step S2), a concrete XML management request 22′ is sent to the applet 7′. In the example of FIG. 4, the concrete XML request 22′ indicates that the request is to be carried out using the SNMP protocol. Correspondingly, the tags comprised in the concrete XML request 22′ are SNMP-specific, in contrast to the tags of the concrete XML request 22 of FIG. 3 which are Telnet-specific. In particular, the fact that the SNMP protocol shall be used is indicated by the <SnmpoverHttp> tag. The name of the network device and the port number to be addressed as well as the password required to access the network device are bracketed between <HostName>, <Port> and <RoCommunity> start and end tags. The <GetIn> start and end tags indicate that an SNMP GET command shall be carried out with an object identifier (Oid), as specified in the <OidWanted Code= . . . /> tag. [0065] The applets 7, 7′ may be management protocol specific, i.e. the applet 7 of FIGS. 2 and 3 may be programmed such that it can only process Telnet-specific requests and responses, whereas the applet 7′ of FIG. 4 can be programmed such that it can only process SNMP-specific requests and responses. In alternative embodiments, the applet is programmed such that it can process more than one or even all network management protocols of interest. [0066] In step T2 (which corresponds to step S3) the applet 7′ translates the concrete XML request 22′ into an SNMP Get request and sends it to the network device 9′ indicated in the concrete XML request 22′. [0067] In step T3 (which corresponds to step S4), the network device 9 returns an SNMP Get response reply to the applet 7′ including the requested information, indicated by the OID code received with the SNMP Get request. [0068] In step T4 (which corresponds to step S5), the applet 7′ translates the SNMP response from the network device 9 in a concrete XML management response 23′. Between an <GetOut> start and end tag the <OidWanted Code . . . > tag is repeated and the returned Oid value is included between <OidValue> start and end tags. [0069] [0069]FIG. 5 shows an applet window 8 output generated during the processing of FIG. 4. The applet window 8 has two panes, a command pane 25 and an output pane 26. In the command pane 25, the network-management-protocol command sent to the network device 9 is displayed. In the output pane 26 the network-management-protocol-response received from the network device 9 is displayed. The display of the management requests and the corresponding responses takes place in “real time” (i.e. simultaneously) with the processing carried out by the applet 7. It enables the user to monitor the network management activities carried out in the user's network. [0070] [0070]FIG. 6 is a state diagram of the applet 7. After having been loaded and initialized, the applet 7 waits in state U1 for a network management request from the analyzer 13. When it receives such a request in the form of an HTTP response to a previous HTTP request, together with a session identifier, it reads the concrete XML request 22 in step U2 so as to arrive in a “request received” state U3. Then, in step U4, the applet 7 sends a network-management-protocol request (e.g. an SNMP request) to the network device 9. In state U5, the applet 7 waits for a network-management-protocol response (e.g. SNMP) response from the network device 9. Upon receipt of the response from the device 9, the applet 7 generates in step U6 the concrete XML response 23 so as to arrive in a “XML response generated” state, named U7. Then, in step U8, the applet 7 sends the concrete XML response 23 to the web server 12 as an HTTP POST request. Together with the HTTP POST request, it also returns the session identifier (ID). Then, the applet 8 arrives again in the waiting state U1, where it waits for another request from the analyzer 13. [0071] Depending on the kind of requests received from the analyzer 13, the sequence of states and steps U1 to U8 can be run through only once or repeatedly. If the applet in the waiting state U1 receives another network management request, it again runs through steps U1 to U8 and then again waits in the waiting state U1. If, however, it receives an end-applet tag (e.g. <EndApplet>) in step U9, the applet initiates a result page to be displayed (state U10) and then terminates. [0072] [0072]FIG. 7 shows an example of such a result page displayed in the user's web browser 6 after the network management processing illustrated in FIGS. 4 and 5 has been performed. In this exemplary result page, it is indicated that the IOS version, which has been found in the processing according to the examples of FIGS. 4 and 5 is “no general deployment release”, and that the general deployment release version is another version (“IOS Version 11.3, Release 11”). Thus, as a result of this exemplary network management service, it has been found that the user uses a “wrong” IOS version, and the user is informed about that: As a next step, the user could, for example, have the correct IOS version installed. [0073] [0073]FIG. 8 is a timing diagram of a network-management-service HTTP session. The provider's server 12 with the analyzer 13, the user's browser 6 with the applet 7 and the user's network device 9 are drafted on the left-hand side, in the middle and on the right-hand side of FIG. 8, respectively. The communication within the analyzer 13, i.e. between the servlet 15 and the application logic part 14 is not represented in FIG. 8 for simplicity. [0074] In step V1 the user sends from his browser 6 an HTTP request for a network-support-service start page to the server 12. Upon receipt of the start page request, the server 12 considers a network-support-service session to be started and assigns a session identifier to this session. In step V2, the server 12 returns the start page as an HTTP response to the user's browser 6. The session identifier is included in this and all subsequent HTT responses sent to the user and all HTTP requests sent from the user to the service provider which enables a session manager within the server 12 to correctly assign all pertinent requests to the present session. The start page is then displayed in the user's browser 6. User authentication for personalized services is optional; FIG. 8 illustrates an embodiment with user authentication. Accordingly, the user then enters authentication data and sends in step V3 an HTTP POST request together with the authentication data to the server 12. In step V4 the server 12 returns an analyzer selection page as an HTTP response which is then displayed in the user's browser 6. The user then selects a specific type of analyzer (e.g. an IOS version analyzer for Cisco devices) and sends, in step V5, the analyzer selection information as an HTTP POST request to the server 12. In step V6 the server 12 sends an analyzer initialization page as an HTTP response to the user which is then displayed in the user's browser 6. The user then enters data specifying what network device is to be subjected to network management and also enters network-specific authentication information (e.g. a required device password). In step V7, the user sends the entered information as an HTTP POST request to the server 12. The analyzer 13 then selects an applet 7 which is appropriate for the selected analyzer type and the specified network devices. The server 12 sends, in step V8, a corresponding applet page as an HTTP response to the user. The applet page contains the code of the applet 7 or a link to an URL from where the code can be loaded. The applet 7 is loaded in the user's browser 6, and the applet is initialized (if necessary, after having been fetched from the location specified by the URL). In step V9, the applet then sends an HTTP request to the server 12 indicating that it has been initialized. Thereupon, the applet enters the waiting state U1 of FIG. 6. [0075] In step V10 the server 12 sends an HTTP response with an encapsulated network management request (for example, the correct XML request 22′ of FIG. 4) to the applet 7. Thereupon, the applet 7 runs through the steps and states shown in FIG. 6. First, in step V11, the applet 7 decapsulates the received management request and sends a corresponding network-management-protocol request (in the present example: the SNMP request shown in FIGS. 4 and 5) to the network device 9 within the user's network (steps U2 to U4 in FIG. 6). The applet 7 then enters the waiting state U5 of FIG. 6. The network device 9 then complies with this request by returning in step V12 a network-management-protocol response (here: the SNMP response shown in FIGS. 4 and 5) to the applet 7. The applet 7 translates the network-management-protocol response into an XML response (for example, the concrete XML response 23′ of FIG. 4) and sends, in step V13, an HTTP POST request with the XML response to the server 12 (steps U6 to U8 in FIG. 6). The applet 7 then enters the waiting state U1 of FIG. 6. The analyzer 13 analyzes the XML response. If a further network management request has to be carried out, another network management request is prepared and sent to the applet as an HTTP response, so that steps V10 to V13 are executed again. If, however, no further management step is required, the analyzer 13 generates a report page based on the XML response or responses received in the present session. In step V14 the server 12 sends an HTTP response to the applet 7 which includes a reference to the report page which is preferably stored in the server 12 and an “end applet” tag. In step V15 the applet 7 sends a “HTTP GET” request to the referenced location of the report page. In step V16, the requested report page is sent to the user as an HTTP response and the applet displays the report in the user's browser 6. Then the user can terminate the applet by pressing an Exit button. This is the end of the network management HTTP session. [0076] With the preferred embodiments, no additional network-management hardware or costly network management software is required. Therefore, the preferred embodiments are an attractive solution for “low end” network management (i.e. management of small networks). The threshold for network users of seeking professional network support is lower than it was previously the case. Thus, a general purpose of the preferred embodiments is to provide improved methods for providing and contributing to an IT network management service as well as applets therefor. [0077] All publications and existing systems mentioned in this specification are herein incorporated by reference. [0078] Although certain methods and products constructed in accordance with the teachings of the invention have been described herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers all embodiments of the teachings of the invention fairly falling within the scope of the appended claims either literally or under the doctrine of equivalents. Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS6363421 *May 31, 1998Mar 26, 2002Lucent Technologies, Inc.Method for computer internet remote management of a telecommunication network elementUS6529938 *Aug 6, 1999Mar 4, 2003International Business Machines CorporationMethod, system, and program for executing operations on a client in a network environmentUS6785734 *Apr 10, 2000Aug 31, 2004International Business Machines CorporationSystem and method for processing control information from a general through a data processor when a control processor of a network processor being congestedUS6920492 *Jun 18, 2001Jul 19, 2005Hewlett-Packard Development Company, L.P.Process for controlling devices of an intranet network through the webUS6944183 *Jun 12, 2000Sep 13, 2005AlcatelObject model for network policy management* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS7529825Dec 2, 2003May 5, 2009Cisco Technology, Inc.Server-side XML-based development environment for network device management applicationsUS7636941 *Mar 10, 2004Dec 22, 2009Microsoft CorporationCross-domain authenticationUS7950055Oct 19, 2009May 24, 2011Microsoft CorporationCross-domain authenticationUS7971240Apr 20, 2009Jun 28, 2011Microsoft CorporationSession key security protocolUS7987258 *Oct 3, 2003Jul 26, 2011Fraunhofer-Gesellschaft zur F�rderung der angewandten Forschung e.V.Network measurement configuration apparatusUS8032620 *Jun 24, 2004Oct 4, 2011Marlin ScottMethod and system for improved in-line management of an information technology networkUS8195792 *Jun 5, 2012Microsoft CorporationInterfacing distinct services for providing web based document manipulation accessUS8655998 *Dec 2, 2003Feb 18, 2014Cisco Technology, Inc.Client-side XML-based development environment for network device management applicationsUS8689311 *Mar 30, 2011Apr 1, 2014Microsoft CorporationCross-domain authenticationUS8799643 *Sep 14, 2012Aug 5, 2014The Nielsen Company (Us), LlcSystem and method for monitoring secure data on a networkUS8972554 *Sep 30, 2010Mar 3, 2015The Nielsen Company (Us), LlcMethods and apparatus to measure mobile broadband market shareUS9009796Nov 18, 2010Apr 14, 2015The Boeing CompanySpot beam based authenticationUS9319469Dec 19, 2011Apr 19, 2016Microsoft Technology Licensing, LlcHost agnostic integration and interoperation systemUS20040103320 *Nov 3, 2003May 27, 2004Guy StorerMultiple network accessUS20050005004 *Oct 3, 2003Jan 6, 2005Hitachi, Ltd.Network measurement configuration apparatusUS20050204041 *Mar 10, 2004Sep 15, 2005Microsoft CorporationCross-domain authenticationUS20060015597 *Jun 24, 2004Jan 19, 2006Marlin ScottMethod and system for improved in-line management of an information technology networkUS20060173997 *Jan 10, 2006Aug 3, 2006Axis Ab.Method and apparatus for remote management of a monitoring system over the internetUS20080313267 *Jun 12, 2007Dec 18, 2008International Business Machines CorporationOptimize web service interactions via a downloadable custom parserUS20090204808 *Apr 20, 2009Aug 13, 2009Microsoft CorporationSession Key Security ProtocolUS20100042735 *Oct 19, 2009Feb 18, 2010Microsoft CorporationCross-domain authenticationUS20100185747 *Jan 16, 2009Jul 22, 2010Microsoft CorporationInterfacing distinct services for providing web based document manipulation accessUS20110179469 *Jul 21, 2011Microsoft CorporationCross-domain authenticationUS20120084430 *Sep 30, 2010Apr 5, 2012Shi LuMethods and apparatus to measure mobile broadband market shareUS20130013914 *Sep 14, 2012Jan 10, 2013Todd Tao ZhouSystem and Method for Monitoring Secure Data on a NetworkUS20140101718 *Dec 10, 2013Apr 10, 2014Microsoft CorporationCross-domain authenticationUS20150019861 *Aug 4, 2014Jan 15, 2015The Nielsen Company (Us), Llc.System and Method for Monitoring Secure Data on a NetworkUS20150170174 *Feb 24, 2015Jun 18, 2015The Nielsen Company (Us), LlcMethods and apparatus to measure mobile broadband market shareEP2573998A3 *Sep 3, 2012Aug 28, 2013The Boeing CompanyMethod and devices for smart agent download* Cited by examinerClassifications U.S. Classification709/223, 709/219International ClassificationH04L12/24Cooperative ClassificationH04L41/0266, H04L41/0253, H04L41/048European ClassificationH04L41/02G1, H04L41/02G3, H04L41/04C1Legal EventsDateCodeEventDescriptionApr 26, 2002ASAssignmentOwner name: HEWLETT-PACKARD COMPANY, CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:LUTZ, MANFRED;REEL/FRAME:012847/0538Effective date: 20020417Jun 18, 2003ASAssignmentOwner name: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P., COLORADFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HEWLETT-PACKARD COMPANY;REEL/FRAME:013776/0928Effective date: 20030131Owner name: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P.,COLORADOFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HEWLETT-PACKARD COMPANY;REEL/FRAME:013776/0928Effective date: 20030131Mar 8, 2013FPAYFee paymentYear of fee payment: 4Nov 9, 2015ASAssignmentOwner name: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, TEXASFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P.;REEL/FRAME:037079/0001Effective date: 20151027RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services