MXPA06001712A - Generic collection and delivery of telemetry data - Google Patents

Abstract

The present invention extends to generic collection and delivery of telemetry data. A telemetry component receives telemetry data, through a common telemetry interface that is accessible to a plurality of applications, from an application. The received telemetry data is aggregated with any existing telemetry in a telemetry database. In response to a detected event, the telemetry component sends the telemetry data, via a corresponding telemetry stream, to a telemetry service. The telemetry service receives the telemetry message, via the corresponding telemetry stream, from the telemetry component. The telemetry service extracts telemetry data and identifies one or more pluggable telemetry handlers that have registered for the telemetry data. The telemetry service dispatches the extracted telemetry data to the one or more identified pluggable telemetry handlers. The telemetry service acknowledges receipt of the telemetry data to the telemetry component.

Description

GENERIC COLLECTION AND DELIVERY OF DATA OF TELEMETRY CROSS REFERENCE TO RELATED REQUESTS Not applicable.

BACKGROUND OF THE INVENTION 1. The Field of the Invention The present invention relates to gathering computer diagnostic information and, more particularly, to the generic collection and delivery of telemetry data. 2. Background and Relevant Technique Computer systems and related technology affect many aspects of society. In fact, the ability of the computer system to process information has transformed the way we live and work. For example, computer systems typically include software applications to perform task hosting (for example, word processing, programming, and database management) that were performed manually prior to the arrival of the computer system. A computer system can also include maintenance, diagnostic, and security applications (eg, recovery applications, health checkers, antivirus applications, firewalls, etc.) that help ensure that the computer system remains, or can be returned, to an appropriate operational state. For example, an antivirus application can detect and remove computer viruses before any damage is done to the computer system. Many computer systems are typically also coupled to each other and to other electronic devices to form both wired and wireless computer networks in which computer systems and other electronic devices can transfer electrical data. As a result, many tasks performed on a computer system (eg, voice communication, accessing email, controlling home electronics, web browsing, and printing documents) include the exchange of electronic messages between a number of computer systems and / or other electronic devices through wired and / or wireless computer networks. Networks have in fact become so prolific that a simple computer-enabled computing system can communicate with any of the millions of other computing systems distributed throughout the world in a conglomeration of networks often referred to as "the Internet." Such computer systems may include desktop, laptop, or personal tablet computers; personal digital assistants (PDAs); phones; or any other computer or device capable of communicating in a digital network.

Due at least in part to the proliferation network count, many software vendors provide network-based updates for their applications. This makes upgrades available for large numbers of users in a low cost way (for example, as opposed to manufacturing and shipping CDs). For example, a vendor can include the latest versions and / or improvements for their applications on a company website on the Internet. That way, any user (with Internet access) can access the website and download updates to their computer system. Updates downloaded later can be installed in the computer system. Some vendors integrate network-based update capabilities into their applications. For example, applications may include an "update" control that, when selected, connects to a known network location and reviews updates. Even other applications automatically check for updates without requiring the selection of an "update" control. In any case, these applications can then present a list of available updates (either before or after the updates are downloaded) to a user for selection. Any of the selected updates later, if appropriate, can be downloaded and installed in the computer system. Some applications, particularly maintenance, diagnostic, and insecurity applications, too (often in response to user approval) can send limited application-specific data back to the software vendor for analysis. For example, an antivirus application can send a list of viruses that have been detected and / or removed from a computer system to the vendor of the antivirus application. In this way, a SPAM blocking application (advertising bombardment or garbage) can send a list of email addresses to a vendor for inclusion in a blocked list. Based on the application-specific data, vendors can gain some insight into how their applications are made. Vendors may also be able to provide more complete updates and respond more quickly to vulnerabilities identified in their applications. However, each application typically includes an owner mechanism (for example, owner interface, owner protocol, etc.) to send application-specific data back to a vendor. In that way, there is typically no way for an application developed by a vendor to send application-specific data to a variety of other vendors. This is unfortunate because application-specific data from an application can be valuable in solving problems with or providing updates to other applications. For example, it may be valuable for a vendor to block SPAM application and know that improper configuration of the particular version of a firewall may allow the transfer of email messages through other unused ports. However, there is an efficient way to transfer the specific firewall data for the SPAM blocking application vendor, since the vendor property mechanism of SPAM blocking application to send application-specific data is not compatible with the vendor's mechanism of firebreaking. It is also unfortunate because every time a new product is developed by any vendor, software developers must learn the idiosyncrasies of proprietary mechanisms. In addition, there is no easy and generic mechanism to place the data loaded from a component of an application into multiple data repositories, where different data repositories can have different reasons, methods, and criteria to analyze the data. In addition, there is no efficient way to filter application-specific data for a particular purpose and be used by a particular vendor. For example, even if the specific firewall data were delivered to the SPAM block application vendor, there are typically no mechanisms to reduce specific firewall data to data related to email. That is, the specific firewall data would also include data related to web-based communication, file transfers, etc., have little, if any, importance for the vendor of the SPAM blocking application. Therefore, systems, methods, and computer program products for generic collection and telemetry data delivery would be advantageous.

COMPENDIUM OF THE INVENTION The above problems with the prior art will be overcome by the principles of the present invention, which are directed towards methods, systems, and computer program products for generic collection and telemetry data delivery. A telemetry component receives telemetry data, through a common telemetry interface that is accessible to a plurality of components of an application or for a plurality of applications, of an application in a computer system. The telemetry component adds the telemetry data received with any of the telemetry data existing in the telemetry database. The telemetry component detects a sent telemetry event. The computer system includes an appropriate portion of the telemetry data added in a telemetry message. The telemetry component sends a telemetry current, through the telemetry message, for a telemetry service in response to the sent telemetry event detected. A telemetry service sends the telemetry current, through the telemetry message, from the telemetry component. The telemetry service extracts telemetry data of a specified type from the telemetry message. The telemetry service identifies one or more connectable telemetry controllers that have been registered for telemetry data of the specified type. The telemetry service sends the extracted telemetry data to one or more of the identified connectable telemetry controllers. The telemetry service sends a knowledge or component of telemetry, knowledge indicating that the telemetry service received the telemetry message, or an error condition, that portions of the telemetries were received and did not need to be retransmitted, and that portions were not received and must be retransmitted if appropriate. The telemetry component receives the knowledge of the telemetry service. These and other objects and features of the present invention will be more fully apparent from the following description and appended claims, or may be learned by the practice of the invention as mentioned hereinafter.

BRIEF DESCRIPTION OF THE DRAWINGS To further clarify the foregoing and other advantages and features of the present invention, a more particular description of the invention will be presented through reference to specific embodiments thereof which are illustrated in the accompanying drawings. It is appreciated that these drawings only illustrate typical embodiments of the invention and therefore will not be considered limiting their scope. The invention will be described and explained with further specification and detail through the use of the accompanying drawings in which: Figure 1 illustrates an example of a computer architecture that facilitates the generic collection and delivery of telemetry data through an interface common. Figure 2 illustrates a flow chart illustrating a method for the generic collection and delivery of telemetry data through a common interface. Figure 3 illustrates an operating environment suitable for the principles of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED MODALITIES The above problems with the prior art are overcome by the principles of the present invention, which are directed towards methods, systems, and computer program products for generic collection and delivery of telemetry data. A telemetry component receives telemetry data, through a common telemetry interface that is accessible to a plurality of components of an application or for a plurality of applications, of an application in a computer system. The telemetry component adds the telemetry data received with any of the telemetry data existing in the telemetry database. The telemetry component detects a sent telemetry event. The computer system includes an appropriate portion of the telemetry data added in a telemetry message. The telemetry component sends a telemetry current, through the telemetry message, for a telemetry service in response to the sent telemetry event detected. A telemetry service receives the telemetry current, through the telemetry message, from the telemetry component. The telemetry service extracts telemetry data of a specified type from the telemetry message. The telemetry service identifies one or more connectable telemetry controllers that have been registered for telemetry data of the specified type. The telemetry service sends the extracted telemetry data to one or more of the identified connectable telemetry controllers. The telemetry service sends knowledge to the telemetry component, knowledge indicating that the telemetry service received the telemetry message, or an error condition, that portions of the telemetry were received and did not need to be retransmitted, and that portions were not received and must be retransmitted if appropriate. The telemetry component receives the knowledge of the telemetry service.

Modes within the scope of the present invention include computer-readable media for transporting or having executable instructions by computer or data structures stored therein. Such computer-readable media can be any available medium, which is accessible through a general-purpose computer system or special purpose. By way of example, and not limitation, such computer readable media may comprise physical storage media such as RAM, ROM, EPROM, CD-ROM or other storage of optical disk, magnetic disk storage or other magnetic storage devices, solid state storage devices, or any other means that may be used to transport or store desired program code media in the form of computer executable instructions, computer readable instructions, or data structures and which may be accessed by a general-purpose computer system or special purpose. In this description and in the following claims, a "network" is defined as one or more data links that allow the transport of electronic data between computer systems and / or modules. When transferring or providing information on a network or other communication connection (either wireline, wireless, or a combination of wireline or wireless) to a computer system, the connection is properly seen as a computer readable medium. In that way, any connection is properly called a computer readable medium. Combinations of the above should also be included within the scope of computer readable media. Computer executable instructions include, for example, instructions and data that cause a general purpose computer system or special purpose computer system to perform a certain function or group of functions. Computer executable instructions may be, for example, binary instructions, intermediate format such as assembly language, or even source code. In this description and in the following claims a "computer system" is defined as one or more software modules, one or more hardware modules, or a combination thereof, which together work to perform operations on electronic data. For example, the definition of a computer system includes the hardware components of a personal computer, as well as software modules, such as the computer operating system of the individual computer. The physical design of the modules is not important. The computer system may include one or more computers coupled through a network. Similarly, a computer system can include an individual physical device (such as a mobile phone or Personal Digital Assistant "PDA") where internal modules (such as a memory and processor) work together to perform operations on electronic data . Those skilled in the art will appreciate that the invention can be practiced in network computing environments with many types of computer system configurations, including, personal computers, laptops, portable devices, multiprocessor systems, microprocessor-based or programmable electronics. for the consumer, network PCs, minicomputers, macrocomputers, mobile phones, PDAs, pagers, and the like. The invention can also be practiced in distributed system environments where local and remote computer systems are linked (either through reinforced wire data links, wireless data links, or a combination of reinforced wire data links). or wireless) through a network, both perform tasks. In a distributed system environment, the program modules can be located in both local and remote memory storage devices. Figure 1 illustrates an example of a computer architecture 100 that facilitates the generic collection and delivery of telemetry data through a common interface. As illustrated, the computer architecture 100 includes computer systems 101, 124, 126, 127 and 131. A series of three vertical periods (a vertical ellipsis) before, between, and after the computer systems 124, 101 and 126, indicates that other computer systems may also be included in the computer architecture 100. The computer systems 101, 124, 126, 127 and 131 may be connected to a network such as, for example, a Local Area Network ("LAN") , Wide Area Network ("WAN"), or even the Internet. Accordingly, computer systems 101, 124, 126, 127 and 131 can receive data from and send data to one another as well as to other connected network computer systems (not shown). For example, computer systems 101, 124, 126, 127 and 131, as well as other networked computer systems, can create message-related data and exchange message-related data (e.g., Internet Protocol datagrams ("IP ") and other higher-layer protocols that use IP datagrams, such as, Transmission Control Protocol (" TCP "), Hypertext Transfer Protocol (" HTTP "), Simple Mail Transfer Protocol (" SMTP ") , etc.) in a network. For example, computer systems 101, 124, 126, 127 and 131 can create SOAP covers or exchange SOAP covers in a corresponding network.

The computer systems 101 include telemetry component 122, applications 102, 103 and 104 and database 123.

Generally, the telemetry component 122 is configured to gather application telemetry data and store telemetry data gathered in the telemetry database 123. The telemetry component 122 includes the telemetry interface 121 to interfere with the applications ( and other software components) to receive telemetry data. The telemetry interface 121 may be a common telemetry interface that is made available to application developers.

In this way, application developers can include corresponding compatible telemetry interfaces in developed applications. For example, applications 102, 103 and 104 include telemetry interface 112, 113, and 114 respectively. The telemetry interfaces 112, 113 and 114 may be telemetry interfaces developed for compatibility with the telemetry interface 121. Accordingly, each of the applications 102, 103 and 104 may be configured to be compatible to send telemetry data to the telemetry component. telemetry 122. Applications can be configured to generate one or more different types of telemetry data. The telemetry data may include several different types of more general telemetry data, such as, for example, Quality of Service ("QoS") telemetry data, coverage time telemetry data, system health telemetry data. of computer, catastrophic failure telemetry data, etc. The most general telemetry data may be of interest to a variety of different application developers / vendors. For example, antivirus vendors, firewall vendors, and recovery vendors may be interested in catastrophic failure data to be used in making their applications more cumbersome. The telemetry data can also include several different types of more adapted telemetry data, such as, for example, antivirus telemetry data, firewall data telemetry, SPAM blocking telemetry data, recovery telemetry data, etc. The adapted telemetry data may be of interest to a small subgroup or only an individual application developer / seller vendor. For example, telemetry data indicating the date / time of a detected virus can only be of interest to an antivirus developer / vendor. Telemetry data can include account telemetry data. For example, telemetry may include an account of how many viruses have been detected in the computer system 101 or how many times the computer system 101 has been restarted in a specific period of time. The telemetry data may also include snapshot telemetry data indicating the status. For example, snapshot telemetry data may include system resources available at a particular time (for example, when a "snapshot" is taken). The telemetry component 122 can identify different types of telemetry data and store (or form) telemetry data by type in telemetry data base 123. For example, the telemetry component can identify QoS data received from applications 102, 103 and 104 and can add the received QoS data with previously stored QoS data. Other types of more general telemetry data as well as different types of adapted telemetry data may be added in the telemetry database 123.

In response to an event, such as, for example, expiration of a chronometer, a request for a telemetry service, detection of a catastrophic failure, etc., the telemetry component 122 can send (or deform) telemetry data to the service of telemetry 132. Telemetry data can be transmitted in several different telemetry streams. For example, the telemetry component 122 can send a first type of telemetry data (e.g., start time telemetry data) in the. stream 141 and second type of telemetry data (e.g., recovery telemetry data) in stream 143. Although not expressly illustrated, it should be understood that each computer system 124 and 126, as well as any other computer Network-connected computers can be configured in a manner similar to computer 101. That is, computer systems 124 and 126, as well as other networked computer systems, can include one or more applications that send telemetry data through the network. a telemetry interface common to a telemetry component. The telemetry component can identify different types of telemetry data and store the telemetry data appropriately in one of the corresponding telemetry databases. In response to some event, the telemetry components can send telemetry data (for example, in appropriate telemetry streams). For example, each of the computer systems 101, 124 and 126 can send QoS telemetry data to the telemetry service 132 through corresponding QoS telemetry streams, the start-time telemetry data to the telemetry service 132. through corresponding telemetry currents of corresponding start time, etc. Computer system 131 includes telemetry service 132, telemetry consumer record database 133, and rear end components 134, 136 and 137. Although Figure 1 illustrates rear end components 134, 136 and 137 as being included in the computer system 131, it should be understood that the back end components 134, 136 and 137 may be distributed through more than one computer system. For example, the back end components 134, 136 and 137 may be located in part in the computer system 101 and located in the one or more part of another computer architecture of computer systems 100. Generally the telemetry service 132 is configured to receive telemetry messages from one or more computer systems (e.g., computer systems 124, 101 and 126). For example, the telemetry service can receive telemetry messages through telemetry currents 141 and 143, through corresponding currents of computer systems 124 and 126, and through corresponding currents of other networked computer systems. The back end components, such as, for example, back end components 134, 136 and 137, may record one or more different types (eg, QoS, start time, maintenance, etc., of telemetry data. telemetry service 132 can receive the registers and store the registers in a telemetry client registration database 133. When a telemetry message is received, a telemetry service 132 identifies the type of telemetry data contained in the telemetry message The telemetry service 132 then checks the telemetry consumer record database 133 for downstream components that have been registered for the identified type of telemetry data.The telemetry service 132 then distributes the telemetry data contained therein to the telemetry data base. the back end components recorded In response to proper reception of a telemetry message, the telemetry service a 132 can send a knowledge back to the telemetry component that issued the telemetry message. The back end components can store telemetry data for subsequent use. For example, a back end component of QoS can store QoS telemetry data in a QoS database, a start time analysis database can store start time telemetry data in an analysis database start time, a rear end of a firewall can store telemetry data from fire breaks in a database of fire breaks, etc. Alternatively or in combination with storage components, back end can send electronic messages to a developer / vendor. For example, in response to multiple detections of a previously known virus, an antivirus endpoint component can send an alert to the antivirus application vendor. In that way, it can generally be that a telemetry service is a central receiving point for telemetry data from the telemetry components in a plurality of other networked computer systems. The communication between a telemetry service and telemetry components can be assured using two forms of authentication and marked messages. For example, communication between telemetry component 122 and telemetry service 132 can be secured using two-way authentication in the Secure Facts Design ("SSL") protocol. A telemetry service may also stifle (for example, by sampling a subset of available telemetry components) the reception of telemetry data by telemetry stream so that manageable sample numbers are processed. For example, telemetry service 132 may sample a specific number of telemetry components (e.g., a smaller number than all available telemetry components) for QoS telemetry data per hour as well as maintain a manageable group of telemetry data. of QoS. In that way, sampling can reduce the likelihood that a significant amount of resources from computer system 131 will be consumed to process QoS telemetry data (or consumed to process any other type of telemetry data). The telemetry data may include a series of name / value pairs. In some modalities, name / value pairs are understandable for an application that generates name / value pairs and a corresponding back end component. For example, the application 102 and the back end component 134 may understand one or more name / value pairs included in a telemetry message 151. However, the telemetry component 122 and the telemetry service 132 may not understand (not worry about) one or more name / value pairs. In some modalities, telemetry is targeted for a specific computer system. For example, the telemetry component 122 may send in telemetry message 156 or telemetry service 128. The telemetry message 156 may include telemetry data (e.g., name / value pairs) that may be useful to a user of the system. of computer 127 when diagnosing problems in the computer system 101. In response to receiving the message with objective 156, the telemetry service 128 can send ACK 157 (a knowledge indicating that the message with objective 156 was received) to the telemetry component 122. On an ACK 157 there may be a target message (potentially from a different component of the computer system 127) based on a telemetry message 156 being from the computer system 101. The telemetry service 128 may also be telemetry data. currently received in a user inferióase. Figure 2 illustrates a flow chart illustrative of a method 200 for generic collection and delivery of telemetry data through a common interface. The method 200 will be described with respect to the components and data in the computer architecture 100. The method 200 includes an act of receiving telemetry data from an application through the common telemetry interface (act 201). For example, the telemetry component 122 can receive telemetry data 116 through the telemetry interface 121. The telemetry data 116 can be generated in one or more applications 102., 103 and 104 and sends common telemetry interface 112, 113, and 114 respectively. In that way, the telemetry data 116 may include name / value pairs, name / value counters, custom telemetry and / or incomplete data representing different types of telemetry data. The telemetry data can be represented in the form of Extensible Markup Language ("XML"), or, for example, for name / value pair data, they can be represented as row parameters for mergers that implement the telemetry interface. The method 200 includes an act of adding telemetry data received with any of the telemetry data existing in a telemetry database (act 202). For example, the telemetry component 122 may add telemetry data 116 in the telemetry database 123. The telemetry data 116 may therefore be added to the telemetry data type. For example, some portions of telemetry data 116 may be aggregated with existing QoS telemetry data, some aggregated portions with existing start-time telemetry data, some portions added with recovery telemetry data, etc. Adding telemetry data can include updating meter telemetry data and replacing snapshot data. For example, when a new virus is detected, the number of viruses detected may increase. Similarly, when a new snapshot of system resources is taken, an old snapshot of system resources can be replaced. Method 200 includes an act of detecting and sending a telemetry event (act 203). For example, the telemetry component 122 can detect a corresponding sent telemetry event for the telemetry data in the telemetry base 123. A sent telemetry event can be, for example, expiration of a stopwatch, a request from a telemetry service. telemetry, a catastrophic failure, etc. Method 200 includes an act of including an appropriate portion of the telemetry data added in a telemetry message (act 204). The appropriate portion of aggregated telemetry may be telemetry data in response to and / or designed by the telemetry event sent. For example, the telemetry component 122 may include a portion of telemetry data from the telemetry database 123 in the telemetry message 151. The telemetry data included may be of a specified type, such as, for example, QoS telemetry data, start-time telemetry data, snapshot telemetry, custom telemetry data, etc. The specified can be included in response to the sent telemetry event detected. For example, the telemetry component 122 may include QoS telemetry data in the telemetry message 151 in response to a request for QoS telemetry data from the telemetry service 132. The telemetry data may be formatted in accordance with a scheme. The following objective message sending request and XML schema definition documents ("XSD") of telemetry load define illustrative examples for requests for sending the message and sending telemetry data: 1. < ? xml version = "1.0" that encodes = "utf-16"? > 2. < xs: Default scheme of Attribute form = "disqualified" Default of Form of item = "qualified" xmlns: xs = "..." > 3. < xs = element name = "Telemetry" > 4. < xs: Mixed complex type = "fa! so" > 5. < xs: sequence minFocus = "0" > 6. < xs: selection maxOpcurs = "unlimited" > 7. < xs: element name = "Current" > 8. < xs: Complex type > 9. < xs = sequence > 10. < xs = element maxOccurs = "unlimited" name = "Property" > 11. < xs = Complex type > 12. < xs: attribute name = "Name" type = "xs: row" uses = "required" / > 13. < xs: attribute name = value "type =" xs: row "uses = "required" / > 14. < xs: attribute name = "time stamp" type = "xs: row" uses = "required" / > 15. < / xs: complex type > 16. < / xs: element > 17. < / xs: sequence > 18. < xs: attribute name = "ID" type = "xs: row" uses = "required" / > 19. < / xs: Complex type > 20. < / xs: element > 21. < xs: element name = "Incomplete current" > 22. < xs: mixed complex Tlpo = "true" > 23. < xs: attribute name = "ID" type = "xs: row" uses = "required" / > 24. < xs: attribute name = "time stamp" = "xs: row" uses = "required" / > 25. < / xs: Complex type > 26. < / xs: element > 27. < / xs: choice > 28. < / xs: sequence > 29. < xs: attribute name = "cver" type = "xs: row" uses = "required" / > 30. < xs: attribute name = "pver" type = "xs: unchecked byte" uses = "required" / > 31. < xs: attribute name = "time stamp" type = "xs: row" uses = "required" / > 32. < xs: attribute name = "Telemetry GUID" type = "xs: row" uses = "required" / > 33. < / xs: Complex type > 34. < / xs: element > 35. < xs: element-name = "Request to Send Message with Objective" > 36. < MESSAGE SENDING REQUEST FORMAT > 37. < / xs: element > 38. < / xs: scheme > The data definitions between lines 3 and 34 define a telemetry element. The data definitions between lines 7 and 20 define a current element that can be included in a telemetry element. Line 10 defines a property element that can be included in the current element and indicates that zero or more property element can be included in the current element. Lines 12-14 define attributes of Name, Value, and Time Stamp respectively of the property element. Line 18 defines an ID attribute for the current element. The data definitions between lines 21 and 26 define an element of Incomplete Current. Lines 23 and 24 define an attribute of Time Stamp Id and attribute respectively for the element of Incomplete Current. Line 6 represents one or more current elements and / or one or more elements of Incomplete Current may be included in a telemetry element. Lines 29-32 define telemetry element attributes (versions, time stamp, and GUID) that can be used to identify the telemetry element. Lines 35-37 represent those additional message delivery request forms that can also be defined. These target message sending request formats can be used to format targeted message requests that are on loaded telemetry data. For example, the telemetry message 156 may include telemetry data together with a target message request requesting that telemetry service 128 that analyzes the included telemetry data. The telemetry message 151 and / or 153 may also include targeted message requests directed to modules in the computer system 131. Thus, the data for other modules related to telemetry may be included in an ACK message. of telemetry that eliminates the need to send the data in a separate message. This load potentially conserves the wide band of network. The telemetry component 122 may be configured to appropriately include a targeted message request in a telemetry message. The telemetry services 132 and 128 may be configured to send any of the target message requests to the appropriate modules. Accordingly, a telemetry message (eg, a SOAP message) may include a telemetry element containing one or more current elements, one or more Incomplete Current elements, and one or more target message requests. The following portion of XML represents an illustrative telemetry message formatted according to the illustrative formats in the target message sending request and the telemetry loading XSD document: 40. Tememetry cver = "1" pver = "1"time stamp =" "Telemetry GUID =" ">; 41. < Current ID = "<row>" > 42. < Property Name = "" Value = "" Time Stamp = "" / > 43. 44. < / Current > 45. < Incomplete Current ID = "<row>" time stamp = "" > 46. < INCOMPLETE DATA > 47. < / Incomplete current > 48. < Incomplete Current ID = "Custom Telemetry" time stamp = "" > 49. < Session Stream = "Port Update" Provider = "Fire Cut" time stamp = "" / > 50. < Parameter Name = "Port Start" Value = "1024" / > 51. < Parameter Name = "Port End" Value = 1048"/> 52. <Parameter Name =" Scope "Value =" All "/> 53. < / Session> 54. < / Incomplete Current > 55. < / Telemetry > 56. < Request for Sending Message with Purpose > 57. < MESSAGE REQUEST DATA > 58. < / Solitude of Message Submission &Objective > lines 40 to 55 represent a telemetry element, these attributes and the corresponding attribute values cver = "1" "pver =" 1"time stamp =" "Telemetry GUID =" "can be used to identify the element of telemetry Although not explicitly illustrated in the previous XML portion, the timestamp and GUID telemetry attributes have corresponding values. In addition, the values of "1" for the attributes of cver and pver are illustrative values and the values for cver and pver can vary through different versions of client and protocol.

Lines 41-44 represent a current element. The corresponding value attribute and ID = "<row>" identifies a specified stream (eg, stream 141 or stream 143) that is associated with the telemetry data contained in the stream element. Line 42 represents a property element. The corresponding attribute and values Name = "" Value = "" respectively, identify a name / value pair. The corresponding attribute and value time = "" indicates a time when the name / value pair was obtained. Line 43 represents at least one other property element that may be contained in the current element represented in lines 41-44. Lines 45-47 represent an element of Incomplete Current. The corresponding attributes and values D = "> row >" and time stamp = "" respectively, identify a specified current (eg, current 141 or current 143) that is associated with the telemetry data contained in the element of incomplete current and indicate a time when the telemetry data contained in the Incomplete Current element was obtained. Line 46 generally represents such incomplete telemetry data, such as, for example, volume XML or binary data, are contained in the Incomplete Current element. The binary data may be encoded, for example, in a base 64 row. Incomplete Row elements may also be used to send Custom Telemetry. Lines 48-54 represent another element of Incomplete Current. The corresponding attributes and values ID = "Custom Telemetry" time stamp = "" identify a custom telemetry current (eg, current 141 or current 143) that is associated with the telemetry data contained in the Incomplete Current element. and indicate a time when the telemetry data contained in the Incomplete Current element was obtained. Lines 49-53 illustrate a session element. The session element may have meanings for an application (e.g., application 102) that generates the custom telemetry data and a corresponding rear end component (back end component 134) that receives the custom telemetry data. However, the session element may be unimportant for intermediate modules that transfer the usual telemetry data (e.g., telemetry component 122 and telemetry service 132. Attributes and values Corresponding Current = "Port Update" Provider = "Fire Cut" time stamp = "" indicates that custom telemetry is more specifically associated with the Port Update stream of a firewall provider and indicates a time when the data of custom telemetry contained in the session item were obtained. Lines 50 and 51 represent ports that vary by a number of 1024-1048 that are updated. Lines 56 through 58 represent a Message Request with Objective. Line 57 represents message request data that can be loaded together with the telemetry data on lines 40-55 in a telemetry message. Method 200 includes an act of sending a telemetry stream, through the telemetry message, to a telemetry service (act 205). For example, telemetry component 122 can send current 141, via telemetry messages 151, to the telemetry service 132. Similarly, the telemetry component 122 can send the stream 143, via the telemetry message 153, to the telemetry service 132. Each of the telemetry messages 152 and 153 may include one or more current and / or incomplete current elements corresponding to currents 141 and 143 respectively. The method 200 includes an act of receiving the telemetry current, through the telemetry message, from the telemetry component (act 207). For example, telemetry service 132 can receive stream 141, through the telemetry message 152, from the telemetry component 122. Similarly, the telemetry service 132 can receive stream 143, through the telemetry message 153, from the telemetry component 122. The method 200 includes an act of extracting data from a type of telemetry. specified from the telemetry message (act 208). For example, telemetry service 132 may extract QoS telemetry data from telemetry message 151. Similarly, it may be that telemetry service 132 extracts customary fire-cut telemetry data from message 153. Method 200 includes an act of identifying one or more connectable telemetry controllers (act 209). For example, the telemetry service 132 can identify that the back end components 134 and 137 have recorded QoS telemetry data. Similarly, the telemetry service 132 can identify that the back end component 136 has recorded the usual fire-fighting telemetry. Generally, the back end components may include an interface for accessing specific types of telemetry data to which the back end component has registered. A back end component may also include an interface that is specialized for accessing name / value pairs. In some embodiments, the telemetry service 132 reviews previously received records contained in the database in the telemetry consumer record 133. From time to time, the back end components may register an interest in the telemetry data from telemetry streams. specific, for example, by indicating a current ID value to the telemetry service 132. The telemetry service 132 can record records in the telemetry consumer record database 133. When the telemetry data is received, the service of telemetry 132 may compare the current ID value (eg, the "<row>" portion of ID = "<row>") of the received telemetry data to the registered current ID values. When a match is identified, the telemetry data is sent to the back end component that sent the record. Method 200 includes an act of sending telemetry data to one or more controllers (act 210). For example, the telemetry service 132 can send QoS telemetry data contained in the telemetry message 151 to back end components 134 and 137. Similarly, the telemetry service 132 can send data from the chime fi ame signal to the component. back end 136. Method 200 includes an act of sending a knowledge that indicates the receipt of telemetry data (act 211). For example, the telemetry service 132 may send ACK 152 indicating the receipt of telemetry data contained in the message of íemetry 151. Similarly,, the security service 132 can send the ACK 154 indicating the receipt of damage to goods contained in message 15e. Similarly, for example, in an error condition, the security service 132 can send an indication of which portions The damage from the damage was received and did not need to be remitted, and portions were not received and must be retransmitted if appropriate. The ACK 154 may also indicate whether or not the service of item 132 is capable of processing portions of the message of item 151. The knowledge may be formed according to a scheme. The following message reply with objective and XSD document of knowledge of ílemetry defines illustrative formats to send a knowledge of íemetry: 60. <;? xml version = "1.0" that encodes = "utf-16"? > 61. < xs: Predetermined scheme of Business form = "disqualified" Predeer of Form of element = "qualified" xmlns: xs = "..." > 62. < xs: name of element = "Telemefría answer" > 63. < xs: Complex type > 64. < xs: sequence > 65. < xs: name of the element = "Acdks de Corrienie" > 66. < xs: Mixed complex type = "false" > 67. < xs: sequence minFocus = "0" > 68. < xs: elemenio minOccurs = "0" maxOccurs = "limited" name = "Current Ack" > 69. < xs: Complex type > 70. < xs: attribution name = "ID" íipo = "xs: row" use = "required" / > 71. < xs: first name = "answer" ipo = "xs: row" use = "required" / > 72. < / xs: Complex type 73. < / xs: elemenfo > 74. < xs: elemenío minOccurs = "0" maxOccurs = "ilimiíado" name = "Ack de Corrienie lncompleío" > 75. < xs: Complex type 76. < xs: name of company = "ID" ipo = "xs: row" use = "required" / > 77. < xs: first name = "answer" ipo = "xs: row" use = "required" / > 78. < xs: name of company = "ismap of time" íipo = "xs: row" uses = "required" / > 79. < 7xs: Complex type > 80. < / xs: elemenío > 81. < / xs: sequence > 82. < / xs: Complex type > 83. < / xs: elemenío > 84. < / xs: sequence > 85. < / xs: Complex type > 86. < / xs: elemenío > 87. < / xs: sequence > 88. < xs: name of company = "see" íipo = "xs: Byie not marked" use = "required" / > 89. < xs: name of company = "GUID de ílemeíría" íipo = "xsifila" uíiliza = "required" / > 90. < / xs: Complex type > 91. < / xs: element > 92. < xs: element name = "Message Send Response with Objective" > 93. < MESSAGE SENDING RESPONSE FORMATS > 94. < / xs: element > 95. < / xs: scheme > The definitions of damage between lines 62 and 91 define an element of Telemery Response. The definitions of damage between lines 65 and 83 define an element of Correspondence Acks that may be included in a response item of ememery. Lines 68-73 define an element of Ack de Corrienie that can be used to recognize the receipt of energy data from a stream. Lines 70 and 71 define an account of ID and payment of Respect Respectively for the item of Ack de Corrienie. Lines 74-80 define an element of the Corrientes Incompleía Ack that can be used to recognize the receipt of damage caused by an incomplete stream. Lines 76-78 define an ID exchange, Respirony exchange, and payment of the same time period, respectively, for the item in the Current Currency Incomplete. Lines 92-94 represented that the response forms of message sending with additional objeïve can also be defined. These responses can be used to format targeted message responses that are loaded along with telemetry knowledge. For example, ACK 157 may include knowledge of fuel quality (diesel damage in message 156) June with a message response with an objective that indicates the results of analyzing diesel data (through the fuel service 128). The ACK 152 and / or ACK 154 also includes target message responses directed to modules in the computer system 101. In this way, the data for other modules related to non-telemetry can be included in an ACK that eliminates the need to send the data in a separate household. The potential load retains network bandwidth. The telemetry services 132 and 128 may be configured to appropriately include a message response with objection to an ACK. The lelemetry component 122 may be configured to send any of the targeted message responses to the appropriate modules. Accordingly, a telemetry knowledge (e.g., a SOAP message) may include a Telemetry Response element that contains one or more Correspondence Ack elements, one or more Corrienie Ack elements, and one or more responses. of objeivo message. The following portion of XML represents an illusive ACK formatted according to the illustrative formats in the target message response and the telemetry knowledge XSD document: 100. < Telemery response: see = "1" = eemetry GUID = "" > 101. < Current Acks > 102. < Ack de Corrienie ID = "<row>" Answer "Accept / Withdraw" / > 103. < Row Current Ack ID = "<row>" Response = "Accept / Remove" time stamp = "" / > 104. < / Current Acks > 105. < / Telemetry Response > 106. < Response to Message Submission with Objective > 107. < MESSAGE RESPONSE DATA > 108. < / Message Delivery Reply with Objective > Lines 100-105 represent a Telemetry Response element. The corresponding attributes and attribute values see = "1" GUID telemetry = "" can be used to identify the Telemetry Response element. Lines 101-104 represent an element of Current Acks. Line 102 represents a Current Ack element. The corresponding attributes and values ID = "<row>" and Response = "Accept / Re-send" (on line 101) denote a specific stream (for example, run 141 or run 143) and indicate whether the damage received from the stream is being run or is going to be forwarded. Line 103 represents an element of Ack of Incomplete Current. The corresponding attributes and values ID = "<row>" and response = "accept / remove" (on line 102) identify a specified incomplete stream (for example, run 141 or run 143) and indicate whether those received by you of the incomplete stream are accepted or will be forwarded. The attribute and value corresponding to the fime = "" field (in line 102) indicate a time when the response was formulated. Lines 106-108 represented a Message Reply with Objection. Line 107 represented message response damages that can be loaded in June with the telemetry response on lines 100-105 in an ACK. Method 200 includes an act of receiving a knowledge that indicates receipt of the telemery message (act 206). For example, the heating element component 122 can receive the ACK 152 and / or ACK 154. Alfernally, for example, when there is no error condition, the structural element 122 can receive an indication that portions of heating damage were received. and did not need to be refransmiiidos, and that portions were not received and should be remitted if appropriate. Therefore, the modalities of the present invention facilitated the generic collection of illicit damage. The applications can send telemetry data through a common telemetry interface to an electronics component that stores the data of a telemetry in a database of telemetry. Compounds of possible adverse effects will record damage to the environment and the inverse with a service of intelligence to receive appropriate disasters. Objective messages can be loaded from email messages and knowledge to preserve network bandwidth. Figure 3 illustrates a suitable operating environment for the principles of the present invention. Figure 3 and the following discussion provide a brief general description of a suitable compilation environment in which the invention can be implemented. Although not required, the invention will be described in the general coniection of computer-executable instructions, as program modules, being executed by computer systems. Generally, the program modules include ruíinas, programs, objeíos, componies, daírios esírucíuras, and the like, that perform particular tasks or implement types of damages absíracíos paríiculares. Computer executable instructions, associated damage manuals, and program modules represented examples of the program code means for executing Acios of the methods described here. With reference to Figure 3, an illusory system for implementing the invention includes a general purpose computing device in the form of computer systems 320, including a processing unit 321, a system memory 322, and a common system conductor. 323 which couples various system components including system memory 322 to processing unit 321. Processing unit 321 can execute executable computer instructions designed to mimic features of computer system 320, including features of the present invention. The common conductor of system 323 can be any of several types of common-conduct streams including a common memory conduit or memory driver, a common peripheral conductor, and a common local drive that uses any of a variety of common conductor architectures. The system memory includes lecfura only memory ("ROM") 324 and alloy access memory ("RAM") 325. A basic send / exit system ("BIOS") 326, which contains the basic routines that help to transfer information about elements of the computer system 320, as long as the boot, can be stored in the ROM 324. The computer system 320 can also include the magnetic hard drive 327 for reading from and writing to the magnetic hard disk 339, magnetic disk unit 328 for reading from or writing to the removable magnetic disk 329, and optical disk unit 330 for reading from or writing to the removable optical disk 331, such as, for example, a CD-ROM or other optical means. The magnetic hard disk drive 327, magnetic disk unit 328, and optical disk unit 330 are connected to the common system driver 323 through the hard disk drive inverse 332, magnetic disk unit 333, and injector of optic unit 334, respectively. The units and their associated computer-readable media provide non-dynamic storage of computer-executable instructions, damage manuals, program modules, and other data for computer system 320. Although the illustrative environment described herein uses magnetic hard disk 339, the magnetic removable disk 329 and removable optical disc 331, other types of computer-readable media can be used to store damage, including magnetic chambers, memory cards, digital differential disks, Bernoulli cariuchos, RAMs, ROMs, and the like. The program code code means comprising one or more program modules may be stored on the hard disk 339, magnetic disk 329, optical disk 331, ROM 324 or RAM 325, including an operating system 335, one or more programs of application 336, other program modules 337, and program datas 338. A user may enter commands and information into computer system 320 via keyboard 340, signaling device 342, other enirate devices (not shown), such as for example, a microphone, joystick, gamepad, scanner, or the like. These and other feeder devices may be connected to the processing unit 321 through the t / output module 346 coupled to the common system conductor 323. The logic t / output interface 346 essentially represented any of a wide variety of different ts. , such as, for example, a serial port interface, a PS / 2 inrush, a parallel port, or a Universal Serial Drive ("USB") injector, or an inferium of the Electrical Engineer Institute. and Electronics ("IEEE") 1394 (that is, a fire cut filter), or can even logically represent a combination of interphase differentials. A monitor 347 or other presening device is also connected to the common system driver 323 through the video t 348. Other peripheral output devices (not shown), such as speakers and printers, may also be connected. to the computer system 320. The computer system 320 is connectable to networks, such as, for example, a computer network extended in office or extended in a company, a home network, an intranet, and / or Internet. The computer system 320 can also cause damage to external sources, such as, for example, computer systems, removable applications, and / or databases of data on networks. The computer system 320 includes the network t 353, from which the computer system 320 receives damage from external devices and / or transmission to external sources. As illustrated in Figure 3, the network interface 353 facilitated the damage inadvertently with the remounted computer system 383 through the link 351. The network interface 353 can logically represent one or more sofware and / or hardware modules as such. as, for example, a Network Initiative Card and Network Conferencing Specification Group ("NDIS") correspond. The link 351 represented a portion of a network (for example, a segmenío of Eíherneí) and the computer system remora 383 represented a node of the network. Similarly, computer 320 includes the forward / exit interface 346, whereafter the computer system 320 receives damage from externals and / or transmissions to ex-ternal fuens. The signal / frame inlay 346 is coupled to the modem 354 (eg, a standard modem, a cable modem, a digital subscriber line modem ("DSL")) through link 359, whereby the Computer system 320 receives damage from and / or damage to ex-ternal sources. As illustrated in Figure 3, the input / output interface 346 and the modem 354 facilitate the exchange of damage with the removed computer system 393 through the link 352. The link 352 represented a portion of a network and the system computer remoreo 393 represented a network mode. While Figure 3 represented a suitable operational environment for the present invention, the principles of the present invention can be employed in any system that is capable of, by appropriate modification if necessary, implementing the principles of the present invention. The ambience illustrated in Figure 3 is only illusive and by no means represented even a small one of the wide variety of environments in which the principles of the present invention can be implemented. According to the present invention, the modules, including applications, e-mail, e-mail components, e-mail services, and post-erasure components as well as associated damages, including e-mail, e-mail messages, messages with objection, and knowledge, they can be stored and exceeded from any of the computer readable media associated with the computer system 320. For example, the portions of the modules and portions of associated program data may be included in the operating system 335, application programs. 336, program modules 337 and / or program datas 338, for storage in system memory 322. When a storage device, such as, for example, magnetic hard disk 339, is coupled to computer system 320, modules fail. and associated program data can also be stored in the device. of massive storage. In a networked environment, the illusive program modules relating to computer system 320, or portions thereof, may be stored in memory storage devices such as memory, system and / or mass storage devices associated with system memory systems. computador remo Remo 383 and / or computer system remoiles 393. The execution of these modules can be done in different environments as previously described. The present invention can be represented in other specific forms without appearing in its spirit or essential characteristics. The modalities described are going to be considered in all aspects only as illustrative and not restrictive. The scope of the invention, therefore, is indicated by the appended claims rather than by the foregoing description. All the changes that occur within the meaning and range of equivalence of the claims will be covered within their scope.

Claims (21)

1. - In a computer system that includes a component of telemetry, a data base of telemetry, and a plurality of applications, a method of telemetry data delivery, the method comprises: an element of the telemetry component that receives telemetry data. of an application in the computer system, the telemetry data being received through a common telemetry interface that is accessible for the plurality of applications; an act of adding the telemetry data received with any of the existential data items in the data base; an action to detect a telemetry event sent; an attempt to include an appropriate portion of the telemetry data added in a telemetry message; an act of sending a telemetering stream through the telemetry message to a telemetry service in response to the detected telemetry event; and an act of receiving a knowledge of the telemery service, knowledge indicating that the telemetry service received the message of telemetry.

2. The method according to claim 1, wherein the unit that compose the system that receives the damages of an application in the computer system comprises an obligation to receive damages from the insolvency service.

3. The method according to claim 1, wherein the system wherein the component of the system that receives the damages of a system application in the computer system comprises a value of receiving at least a pair of name / value.

4. The method according to claim 1, wherein the action to defer a shipment of goods sent includes an action to determine the expiration of a chronometer.

5. The method according to claim 1, wherein the task of including an appropriate portion of the data of aggregates added in an email message comprises an attempt to include XML inscriptions in the email message.

6. The method according to claim 1, wherein the step of including an appropriate portion of the e-mail data added in a telemetry message comprises an act of including at least one name / value pair in the telemetry message. .

7. The method according to claim 1, wherein the action of including an appropriate portion of the damage data added in a message of intelligence comprises an act of including damage to the message of the message in the message of faith.

8. The method according to claim 1, wherein the action of sending a message of mail, through the email message, to an email service in response to the detected telemetry event includes an act of sending at least a name / value pair

9. The method according to claim 1, wherein the act of sending a stream of felemery, through the message of ememery, to a service of intelligence in response to the event of e-mail sent from there comprises an act of sending data of the same. incomplete telemery

10. The method according to claim 1, wherein the act of receiving a knowledge from the service of intelligence comprises an acío to receive a message of knowledge that includes a reply message with objeíivo.

11. The method according to claim 1, further comprising: an acio to load a message request with objeíivo in the telemetry message.

12. In a computer system that includes an electronic service, a method of sending damage to the Internet, the method includes: an act of the telemetry service that receives a message from a Member State, through a corresponding email message; a component of ílemeíría; an act of extricating damage to nature and a specific element of the message of self-worship; an act of idenifying one or more connectors of identifiable intelligence that have recorded telemetry data of the specific type; an act of sending the damage of exile to one or more of the identifiable connectors of identifiable ideology; and an acío to send a knowledge to the component of ílemetria, knowledge indicating that the telemetry service received the message of ílemeíría and if the service of ílemeíría was able to process portions of the message of ílemeíría.

13. The method according to claim 12, which further comprises: an acme of the service of ememery that receives registers of one or more connectors of connectable elements, the registers indicating that one or more connectors of connectable ememetry are interested in the type specific telemetry data.

14. The method according to claim 12, wherein the action of receiving a telemetry stream comprises an act of receiving one or more name / value pairs.

15. The method according to claim 12, wherein the act of receiving a telemetry stream comprises an act of receiving incomplete telemetry data.

16. The method according to claim 12, wherein the act of receiving a telemetry stream comprises an act of receiving a telemetry message that includes a targeted message request.

17. The method according to claim 12, wherein the act of receiving a telemetry stream comprises an act of sampling a subset of available telemetry components sending damage to the telemetry stream.

18. The method according to claim 12, wherein the action of extracting damage from the item and a specific item of the message of itemization comprises an act of extracting one or more name / value pairs from the message of telemetry.

19. The method according to claim 12, wherein the risk of extracting data from a specific element of the telemetry message comprises an action to extract XML attributes.

20. The method according to claim 12, which further comprises: an act of loading a message response with objective knowledge.

21. A computer program product to be used in a computer system that includes a computer service, the production of a computer program to implement a method of sending telemetry data, the computer program product comprises one or more means computer-readable computer-executable instructions that, when executed by a processor, cause the computer system to do the following: receive a telemetry stream, through a corresponding email message, from a computer set. telemetry; extract telemetry data of a specific type from the telemetry message; Identify one or more connectors of identifiable intelligence that have recorded damage to the specific character of the system; send the damage data extracted to one or more connectable telemetry controllers identified; and sending a knowledge to the telemetry component, the knowledge indicating that the service received the message of service and the service of intelligence was able to process portions of the telemetry message.