WO2003093957A2 - Systeme de surveillance pour ordinateurs universels - Google Patents

Systeme de surveillance pour ordinateurs universels Download PDF

Info

Publication number
WO2003093957A2
WO2003093957A2 PCT/GB2003/001869 GB0301869W WO03093957A2 WO 2003093957 A2 WO2003093957 A2 WO 2003093957A2 GB 0301869 W GB0301869 W GB 0301869W WO 03093957 A2 WO03093957 A2 WO 03093957A2
Authority
WO
WIPO (PCT)
Prior art keywords
document
data processing
xsd
rules
data
Prior art date
Application number
PCT/GB2003/001869
Other languages
English (en)
Other versions
WO2003093957A3 (fr
Inventor
Richard Martin Chandler
Original Assignee
Monactive Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Monactive Limited filed Critical Monactive Limited
Priority to AU2003227898A priority Critical patent/AU2003227898A1/en
Publication of WO2003093957A2 publication Critical patent/WO2003093957A2/fr
Publication of WO2003093957A3 publication Critical patent/WO2003093957A3/fr
Priority to US10/976,301 priority patent/US20050149847A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/302—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3051—Monitoring arrangements for monitoring the configuration of the computing system or of the computing system component, e.g. monitoring the presence of processing resources, peripherals, I/O links, software programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3089—Monitoring arrangements determined by the means or processing involved in sensing the monitored data, e.g. interfaces, connectors, sensors, probes, agents
    • G06F11/3093—Configuration details thereof, e.g. installation, enabling, spatial arrangement of the probes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/12—Network monitoring probes

Definitions

  • This invention relates to a monitoring system for general-purpose computers, such as computer workstations and servers, connected via a data communications network to common resources.
  • a plurality of computer workstations will be connected to common resources in the network.
  • the workstations may be ones themselves having a fully operative application execution environment, such as a conventional personal computer running applications on a native operating system, such as Microsoft WindowsTM, or may be thin client computers using the resources of a network server, such as a CitrixTM server, to run application sessions on their behalf.
  • a network manager will be tasked with ensuring that both the hardware and software resources within the network are operating correctly, being used effectively, and within a set of more or less formal rules for network resource utilisation.
  • Network resource utilisation may for example be monitored to ensure that the appropriate software licences are in place and that unauthorised software is not being used on the network. It is useful to a network manager to be able to monitor network resource utilisation from a remote terminal, without having to monitor the activities at each workstation separately.
  • US patent 5,987,135 describes a system and method for controlling and monitoring remote distributed processing systems from one or more control processing systems by downloading agent-application programs from the control processing systems to remote control middleware modules on the distributed processing systems, where the control processing systems have a library of available agent-applications for carrying out various monitoring and control tasks, such as determining which applications are run, determine the version of installed software and current software fixes, etc.
  • monitoring is typically carried out repeatedly and continually on the network. Depending on the type and frequency of monitoring carried out, the amount of data generated and resources used can be relatively large.
  • a network resource utilisation monitoring system that has the ability to collect and process large amounts of data in a secure and reliable fashion whilst reducing the impact on network resources. It would also be desirable to provide such a system having the capability to add new monitoring functions with relative ease and reliability.
  • the system should be adaptable such that generic monitoring and control functions are provided by such a system whilst allowing the addition of customised monitoring modules to such a system.
  • a method of monitoring processes on one or more general purpose computers comprising: providing a host data processmg module; adaptively updating the host module with one or more additional data processing modules; and processing a document comprising a plurality of separate data portions, said data portions being intended for processing by different data processing modules, the document processing comprising parsing the document in accordance with a plurality of rules so as to validate the document, wherein the method comprises retrieving a subset of rules, in respect of at least one said data processing module, and building said plurality of rules from said subset.
  • Each adaptable data processing module thus performs some processing (e.g. of a task) in accordance with a different portion of the validated document. Since these data portions are embedded within a single document, an advantage of embodiments of the invention is that a single document can be sent and/or stored on behalf of and/or processed by the plurality of data processing modules, thereby increasing efficiency of processing and network resource utilisation.
  • the plurality of rules is embodied in a schema and each subset of rules is provided by a sub-schema.
  • the document, schema and sub-schema are specified using the extensible Mark-up Language (XML), thus enabling the document to conveniently include a reference to the plurality of rules intended to be used for parsing this document. The reference is identified during the parsing of the document, which means that the rules used to validate the document are explicitly linked to the document itself.
  • the method includes holding a framework for the plurality of rules, and building said plurality of rules using a structure specified by said framework.
  • the framework may be a schema wrapper.
  • Figure 1 is a schematic illustration of components of a network monitoring system, in accordance with an embodiment of the invention
  • Figure 2 is a schematic illustration of software components in a monitoring agent for a general-purpose computer, in accordance with an embodiment of the invention
  • FIG. 3 is a schematic illustration of software modules for a general- purpose computer and a control console in accordance with an embodiment of the invention
  • FIG. 4 is a flow diagram showing processing carried out during document processing in accordance with an embodiment of the invention.
  • Figure 5 is a schematic illustration of a first type of schema built in accordance with an embodiment of the invention.
  • Figure 6 is a schematic illustration of a second type of schema built in accordance with an embodiment of the invention.
  • a data processing system includes a monitoring software platform installed on a plurality of general-purpose computers 2, 4, 6 connected via a data communications network 8 to a common control unit 10.
  • the data communications network 8 may take the form of a private network, a public network (such as the Internet), or a virtual private network.
  • the general purpose computers may be in the form of conventional personal computers running applications on a native operating system, such as Microsoft WindowsTM, or may be network servers, such as CitrixTM servers, providing the resources to thin client workstations (not shown) to run application sessions on their behalf, or may take the form of other types of data processing device such as handheld devices including personal digital assistants (PDAs), smartphones, etc.
  • the user stations 2, 4, 6 each have user software applications installed thereon, such as word processing software, web browser applications, e-mail applications, image processing applications, and various other types of known user applications which are executed on the user stations in response on start- up of the user station, or when selected by the user from an initialisation menu provided by the user station.
  • Each user station 2, 4, 6 also includes a monitoring software platform application in the form of an adaptable monitoring agent 3, 5, 7 installed thereon, to be described below in further detail.
  • the control unit 10 which may for example take the form of a network server with an associated management terminal (not shown) is provided with a database 12 for storing data sent to the console 10 by each of the monitoring agents 3, 5, 7.
  • the control unit also includes monitoring software platform applications in the form of a control console 14, to be described in further detail below, and a reporting console 16 installed thereon. Note that the functions of the control unit may be distributed over a plurality of physical data processing units, which may be located remote from one another and connected via network links.
  • the control console 14 interoperates with the monitoring agents 3, 5, 7 under the instruction of a network administrator to retrieve selected monitoring data from the user stations 2, 4, 6 and to input the data into the database 12.
  • the reporting console 16 is used by the network administrator to present and manipulate the monitoring data and to generate summary reports derived from the monitoring data using in-built processing, manipulation and reporting functions.
  • Each monitoring agent 3, 5 7 includes a plurality of components, of which relevant components are shown in Figure 2.
  • An agent host object 20 has a coordinating function, whereby documents containing data to be shared between other modules of the agent are processed and distributed, and whereby data are collected from the other modules for the purpose of collecting and storing persistent state, held in local state store 34 (which is part of the local storage capabilities of the user station; it may for example form part of a hard drive storage medium provided in the user station) and for posting collected monitoring data to the control unit 10.
  • a communications module 22 handles the delivery of information to and from the control unit 10.
  • a scheduler module 26 takes schedule information from the agent host 20, which is in turn received from the console 14, and builds a schedule that is used to trigger events in the agent, such as initialising a module and instructing the module to carry out a specified monitoring task at scheduled date/times, and triggering the posting of monitoring data to the console 14 at scheduled date/times.
  • a first plugin monitoring module 28 carries out specified monitoring tasks relating to the hardware components of the user station, under the control of scheduler 26 and agent host 20.
  • a second plugin monitoring module 30 carries out specified monitoring tasks relating to the user software applications installed on the user station, under the control of scheduler 26 and agent host 20.
  • a third plugin monitoring module 32 carries out further specified monitoring tasks relating to user station, under the control of scheduler 26 and agent host 20.
  • the plugin monitoring modules 28, 30, 32 are examples of a plurality of customised plugin modules that may be installed on the user station by the network administrator, using console 14, to adapt the agent to specific monitoring.
  • the plugin monitoring module(s) may be written by the platform developer or a third party developer using an application programming interface (API) provided with the monitoring software platform, whereby the generic control functions, such as the scheduling and communications functions, of the platform are reused.
  • API application programming interface
  • the console 14 When instructed by the network administrator to transmit configuration data and/or software updates to an agent on a user station 2, 4, 6, the console 14 generates a broadcast document, structured as an XML document, containing a plurality of document portions for processing and distribution to various of the different agent modules by the agent host 20.
  • the agent host 20 When storing persistent state in the form of configuration data for various of the different agent modules, the agent host 20 generates a configuration document containing a plurality of document portions containing configuration data from various of the different agent modules and stores the same in local state store 34, for subsequent processing and redistribution to the different agent modules by the agent host. This is carried out for example periodically and/or during the shut down procedures for the user station.
  • agent host 20 When posting monitoring data to the console, agent host 20 generates a session document containing a plurality of document portions containing monitoring data from several of the different agent modules, and posts the document to the console 14 via communications module 22. This is carried out at scheduled date/times, preferably during relatively inactive periods of network usage (e.g. around midnight).
  • FIG. 3 illustrates several of the agent modules 20, 22, 26, 28 as installed in one of the monitoring agents 3, 5, 7, along with counterpart modules 34, 36, 38, 40 installed in the control console 14.
  • the console modules include a console host 34, a console communications module 36, a console scheduler module 38, and a console plugin module 40.
  • the counterpart modules construct document portions for transmission to respective agent modules on each user station 2, 4, 6, under the control of rules in the console 14, and instructions received from the network administrator, and are used to validate respective document portions received from respective agent modules on each user station 2, 4, 6, and process the received monitoring data for storage in database 12.
  • Each agent module 20, 22, 26, 28 includes a software code part, labelled 20a; 22a; etc., defining the functions carried out by the module when executed, and schema portions, respectively labelled 20b, 20c, 20d; 22b, 22c, 22d; etc., and the agent host 20 performs validation of documents when received for processing thereby, as will be described in further detail below.
  • the schema portions include broadcast document schema portions, labelled 20b, 22b, etc., configuration document schema portions, labelled 20c, 22c, etc., and session document schema portions, labelled 20d, 22d, etc.
  • Each console module 34, 36, 38, 40 includes a software code part, labelled 34a; 36a; etc., defining the functions carried out by the module when executed, and schema portions, respectively labelled 34b, 34d; 36b, 36d; etc., and the console host 34 performs validation of documents when received for processing thereby, as will be described in further detail below.
  • the schema portions include broadcast document schema portions, labelled 34b, 36b, etc., and session document schema portions, labelled 34d, 36d, etc.
  • schema wrappers The schema portions 20b, 20c, 20d and 34b, 34d stored in the agent host 20 and the console host 34 are referred to herein as schema wrappers. These define the structure of a schema used to validate a given type of document received by the respective host. A schema is built using the wrapper schema of the appropriate type along with sub-schemas, which are inserted into the schema wrapper, of the appropriate type. These sub-schemas are the schema portions 22b, 22c, 22d; etc., and 36b, 36d, etc. stored in the remaining agent modules .
  • the network administrator selects an appropriate plugin module addition function on the console side, and the plugin is sent to the appropriate one or more monitoring agents 3, 5, 7 as a software update which is processed by the agent host 20.
  • the agent host 20 validates the received file and stores the plugin in a data store, such as a hard drive, on the user terminal 2, 4, 6.
  • a corresponding entry, along with an identifier allowing the plugin module to be launched, is written to the registry of that user terminal 2, 4, 6 for subsequent lookup.
  • Figure 4 shows steps carried out by the agent host 20 in order to process a received document.
  • the document may be a broadcast document, a configuration document, or a session document (to be transmitted by the monitoring agent 3, 5, 7 to the console 14). It should be appreciated that the description hereof also applies to the console host 34 in relation to the processing of received broadcast documents (to be transmitted to one or more monitoring agents) or session documents.
  • the document is received.
  • the document may be received over the network interface or from a local function.
  • a schema comprising a schema portion corresponding to the type of received document (broadcast, session, configuration) and sub-schema portions, is created.
  • the agent host 20 needs to retrieve the relevant sub-schemas.
  • the agent host 20 first queries the registry of the user station on which it runs to obtain the list of entries identifying the currently stored agent platform modules and its current plugin modules. The agent host 20 then proceeds to initialise all monitoring platform modules that are not currently running in the user station, at step 102, and queries the respective modules in turn, at step 104, requesting their respective sub-schemas. After receiving their responses, the agent host 20 may transmit an instruction (not shown as a separate step) to each plugin module not currently carrying out a monitoring task to close down. Generally, the communications module 22 and the scheduler module 26 are left running along with the agent host 20 whilst the user station is operative, since their functionality may be called upon at any time. On the other hand, plugin modules are generally closed down by the scheduler module 26 after carrying out their scheduled monitoring tasks, to reduce user station resource utilisation by the monitoring system. Once all the required sub-schemas have been retrieved, the agent host
  • the 20 uses the wrapper schema (schema portions) to build, at step 106, a schema containing the sub-schemas retrieved at step 104.
  • This step essentially involves placing the retrieved sub-schemas from each module in a predetermined part of the wrapper.
  • the sub-schemas can be inserted in an order corresponding to the order in which the module identities are retrieved from the registry, or in accordance with alphabetical ordering, etc.
  • the wrapper schema does not include actual identifying information for each plugin module, the final schema is built using input from each of the plugin modules in turn.
  • the agent host 20 stores the built schema in memory. To validate a document, the agent host 20 then uses a document validation function provided by a parser used by the agent host 20 to validate the entire document contents using the freshly built schema, at step 108. On validation of the document contents, the various different document portions are distributed to the respected agent modules, step 110.
  • a similar process is carried out by the console host 34 in building up schemas for processing documents received from agent hosts across the network (e.g. session documents). Note that the schema building process may be carried out whenever a document is to be processed. More preferably, any required schemas are built on start-up of the user station or the console system, and stored for use until the station or system is shut down, or a new plugin module is loaded.
  • the document received at step 100 may be an extensible Mark-up Language (XML) document
  • the schema created at step 106 may be an XML schema
  • the parser used in step 108 to validate the created schema may be an XML parser.
  • XML Schema standard which is incorporated herein by reference, is a working draft of the W3C Schema Working Group. A description of this standard can be found in the document "XML Schema: Formal Description", W3C Working Draft, 20
  • MicrosoftTM XML parser version 4.0 may be used. As is known in the art, for an XML document to be validated it must inform the reader which schema should be used; accordingly the documents received at step 100 include an identifier corresponding to the schema subsequently created at step 106.
  • the broadcast document sent from the console to a monitoring agent the local configuration document and locally- stored session history for the monitoring agent, and the document that is posted from the monitoring agent to the console.
  • the posted document is a latest available version of the locally-stored session document; hence both the locally stored and posted session documents share the same schema.
  • XML documents sent across the network can be compressed and encrypted to increase network transmission speeds and security.
  • the content of the tag is between the '>' and the ' ⁇ '. If no content is required, then the end tag can be omitted. Attributes appear inside the opening tag brackets, thus for example:
  • attributes have string values, but they can have dates, times, or any form, and they can be validated by the XML schemas used.
  • Element and attribute identifiers reside in namespaces. If a tag comes from a particular namespace rather than the default then it may be used as follows:
  • 'mmm' is the full name of the namespace
  • 'nnn' is a shortened namespace name that is used within a document instance to indicate which XML Schema an element belongs to.
  • the 'nnn' part can be null, in which case the schema is opened up into the default namespace.
  • bespoke schemas can be defined by including a further
  • the xmlns reference comprises three levels: the word 'monactive' defines the root of a namespace tree; the second level indicates that the entity using the schema is to be a monitoring agent; and the third level indicates the use for which the monitoring agent is going to put the document
  • the top-level tag and the attributes associated therewith could comprise :
  • the 'schema' tag from the 'xsd' namespace, with a "targetNamespace” attribute having a value 'monactive:agent:broadcast' informs the XML parser that an XML schema is being defined, and that the name of the schema is specified in attribute "targetNamespace" (i.e. monactive:agent:broadcast)
  • the present invention provides a system whereby a schema can be both known in order to validate the documents, but unknown, such that a module can change its own portion of a schema while no other module knows about, or relies on, anything inside it. order to allow a flexible architecture, the present invention employs what is referred to herein as a 'wrapper schema', which at the highest level sets out an overall structure of a schema, and 'sub-schemas' which are inserted into the wrapper and are defined by each module defines in accordance with a set of rules.
  • Figure 5 illustrates an example of a "flat" structured schema created at step 106 by the agent host 20 or the console host 34.
  • the configuration and broadcast schemas follow this general form.
  • the structure of the built schema includes a top level part 200 derived from a broadcast or config wrapper schema.
  • the next level down includes a shared part 202 derived from a shared sub-schema, including a section part 204 in the next level of the hierarchy, a host part 206 derived from a host sub-schema, a comms part 208 derived from a comms sub-schema 208, a scheduler part 210 derived from a scheduler sub-schema, and one or more plugin parts 212 (only one is shown in Figure 5) corresponding to each plugin module and derived from each respective submodule schema.
  • Each plugin part may include a section part
  • Figure 6 illustrates an example of a "block" structured schema created at step 106 by the agent host 20 or the console host 34.
  • the session schema follows this general form. Each module can write its own session data many times in the same agent session. Over time a module will write many sessions to the agent host, and the agent host will gather up these module sessions into one agent session, essentially grouped in accordance with the time they were written to the agent host. Thus, each block part includes a description of the time period over which the session data were collected.
  • the structure of the built schema includes a top level part 300 derived from a session wrapper schema.
  • the next level down includes a shared part 302 derived from a shared sub-schema, including a section part 304 in the next level of the hierarchy, and a session part 305 having in the next level of the heirarchy a host part 306 derived from a host sub-schema, a comms part 308 derived from a comms sub-schema 308, a scheduler part 310 derived from a scheduler subschema, and one or more plugin parts 312 (only one is shown in Figure 6) corresponding to each plugin module and derived from each respective submodule schema.
  • Each plugin part may include a section part 314 structured in the same manner as the section part 304 appearing in the shared part 302.
  • wrapper schemas above refer to a shared area into which standard form data can be stored:
  • simple text strings scan be stored in an entry section.
  • a string is given an "id” which is used to refer to it (see parts in italics).
  • a group of text strings can be related together using a relation section and optionally associated with another text string.
  • a hierarchical construct can be represented as a string divided into substrings by a divider, and the substrings connected together using the "id” and a parent id ("pid” ... see parts in italics).
  • tags allow, in the XML document being validated, storage of a simple string of text associated with an "id” that may be referred to later in the document, while “heir” tags allow storage of hierarchical strings, like paths or URLs.
  • An “id” is associated with a string, “parented” refers to another "heir” that belongs in front of this string in the hierarchy being modelled.
  • a “rel” tag allows any “IDREF's to be related together as attribute "id”s and optionally bound to another string. The "IDREF”s and the string form a unique pair.
  • the "upgrade” element is an optional element in a broadcast document. It lists the new modules to download, what the name is (which also identifies what other plugin sections there are in the schema), where they are located (remote_filename) and what they should be called locally
  • ⁇ xsd:restriction base "xsd:string”>
  • ⁇ xsd:pattern value "[@+](20[0-9] ⁇ 2 ⁇ )?([01 *][0-9*])?([0123*][0-9*])?([0-
  • the scheduler section conveys is the schedule itself. This defines which events happen to named modules at what time.
  • the schedule element will define what events are to be fired on which objects at which time.
  • the plugin module subschemas will follow a similar pattern as the existing host, communications and scheduler subschemas.
  • agent modules may conduct control functions in relation to the user stations, namely instead of passively monitoring the functioning of the user station, the modules may be used to install user software, alter settings, remove undesirable software, etc. on the user station.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Quality & Reliability (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Document Processing Apparatus (AREA)

Abstract

Les modes de réalisation de l'invention ont trait à un système de surveillance pour ordinateurs universels, ainsi qu'à un procédé de surveillance des différents processus dans un ou plusieurs ordinateurs universels. Ce procédé consiste à: fournir un module principal de traitement de données; mettre à jour de manière adaptative le module principal avec un ou plusieurs autres modules de traitement de données; et traiter un document comprenant une pluralité de parties de données séparées, lesquelles doivent être traitées par différents modules de traitement de données, le traitement de documents consistant à analyser le document conformément à un certain nombre de règles pour le valider. Ce procédé consiste également à extraire un sous-ensemble de règles, conformément à au moins un des modules de traitement de données, et à établir lesdites règles à partir de ce sous-ensemble. Par ailleurs, l'invention concerne un procédé d'exécution de documents à l'aide d'un ensemble adaptable de modules de traitement de données qui agissent sur différentes parties du document. Un seul document peut être alors envoyé et/ou stocké pour le compte de la pluralité de modules de traitement de données et/ou traité par cette même pluralité de modules, ce qui permet d'augmenter l'efficacité de traitement ainsi que l'utilisation des ressources de réseau.
PCT/GB2003/001869 2002-05-03 2003-05-01 Systeme de surveillance pour ordinateurs universels WO2003093957A2 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
AU2003227898A AU2003227898A1 (en) 2002-05-03 2003-05-01 Monitoring system for general-purpose computers
US10/976,301 US20050149847A1 (en) 2002-05-03 2004-10-29 Monitoring system for general-purpose computers

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB0210242.4 2002-05-03
GB0210242A GB2388214B (en) 2002-05-03 2002-05-03 Monitoring system for general-purpose computers

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US10/976,301 Continuation US20050149847A1 (en) 2002-05-03 2004-10-29 Monitoring system for general-purpose computers

Publications (2)

Publication Number Publication Date
WO2003093957A2 true WO2003093957A2 (fr) 2003-11-13
WO2003093957A3 WO2003093957A3 (fr) 2004-05-21

Family

ID=9936078

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2003/001869 WO2003093957A2 (fr) 2002-05-03 2003-05-01 Systeme de surveillance pour ordinateurs universels

Country Status (3)

Country Link
AU (1) AU2003227898A1 (fr)
GB (1) GB2388214B (fr)
WO (1) WO2003093957A2 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2417637A (en) * 2004-06-14 2006-03-01 Siemens Ag Performing administration in a communications system
US8301751B2 (en) * 2005-06-30 2012-10-30 International Business Machines Corporation Generation of a master schedule for a resource from a plurality of user created schedules for the resource

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5987135A (en) * 1997-07-25 1999-11-16 Prc Inc. System and method for controlling and monitoring remote distributed processing system
US6125390A (en) * 1994-04-05 2000-09-26 Intel Corporation Method and apparatus for monitoring and controlling in a network
US20010047410A1 (en) * 2000-05-26 2001-11-29 Isochron Data Corporation System and apparatus for the remote monitoring and control of a computing component

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6476828B1 (en) * 1999-05-28 2002-11-05 International Business Machines Corporation Systems, methods and computer program products for building and displaying dynamic graphical user interfaces
FR2802676B1 (fr) * 1999-12-16 2002-02-08 Bull Sa Procede et dispositif de deploiement d'une supervision distribuee
NZ503392A (en) * 2000-03-14 2001-11-30 New Zealand Post Ltd Transformation of web browser interface by downloaded agent program
CA2303705A1 (fr) * 2000-03-29 2001-09-29 Jacek Kisilewicz Adaptateur interne de connexions avant et arriere de carte son pour ordinateur

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6125390A (en) * 1994-04-05 2000-09-26 Intel Corporation Method and apparatus for monitoring and controlling in a network
US5987135A (en) * 1997-07-25 1999-11-16 Prc Inc. System and method for controlling and monitoring remote distributed processing system
US20010047410A1 (en) * 2000-05-26 2001-11-29 Isochron Data Corporation System and apparatus for the remote monitoring and control of a computing component

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"XML Schema Part 1 : Structures " W3C RECOMMENDATION , [Online] 2 May 2001 (2001-05-02), XP002271881 Retrieved from the Internet: <URL:http://www.w3.org/TR/xmlschema-1/> [retrieved on 2004-02-27] *

Also Published As

Publication number Publication date
AU2003227898A8 (en) 2003-11-17
AU2003227898A1 (en) 2003-11-17
WO2003093957A3 (fr) 2004-05-21
GB2388214B (en) 2005-09-28
GB2388214A8 (en) 2005-02-16
GB0210242D0 (en) 2002-06-12
GB2388214A (en) 2003-11-05

Similar Documents

Publication Publication Date Title
CA2495339C (fr) Structure a base d&#39;etiquettes permettant la distribution des metadonnees de mise a niveau dans un systeme de distribution des mises a niveau
Dolan NEOS Server 4.0 administrative guide
US7062765B1 (en) System and method for updating information via a network
US7853609B2 (en) Update distribution system architecture and method for distributing software
US6986133B2 (en) System and method for securely upgrading networked devices
US8438559B2 (en) Method and system for platform-agnostic software installation
US6895586B1 (en) Enterprise management system and method which includes a common enterprise-wide namespace and prototype-based hierarchical inheritance
EP1636711B1 (fr) Système et procédé de distribution de licences d&#39;utilisation de logiciels dans un environnement informatique en réseau
US8151256B2 (en) Platform independent registry framework
US20050234931A1 (en) Managing client configuration data
US20030208533A1 (en) Method and apparatus for managing web services within a computer network system
US20030140115A1 (en) System and method for using virtual directories to service URL requests in application servers
US20080184201A1 (en) Universal schema for representing management policy
US20040034853A1 (en) Mobile download system
US20070266390A1 (en) Automated management of application-specific tasks from the Internet via distributed task manager agents in a local area network
US20060085461A1 (en) System &amp; method for using web based applications to manipulate data with manipulation functions
JP2006012152A (ja) ネットワークを監査するためのシステムおよび方法
US20050149847A1 (en) Monitoring system for general-purpose computers
US20090265586A1 (en) Method and system for installing software deliverables
US20070174697A1 (en) Generic, WSRF-compliant checkpointing for WS-Resources
WO2003093957A2 (fr) Systeme de surveillance pour ordinateurs universels
US7805507B2 (en) Use of URI-specifications in meta-data driven instrumentation
Learmonth et al. Towards modernising data collection and archive for the Tor network
Ashford et al. OSS design patterns: a pattern approach to the design of telecommunications management systems
Martin Writing Operators withthe Controller-Runtime Library

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SC SD SE SG SK SL TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 10976301

Country of ref document: US

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase in:

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP