AU2009225283A1

AU2009225283A1 - Method Of Collecting Data From Computers Over The Internet

Info

Publication number: AU2009225283A1
Application number: AU2009225283A
Authority: AU
Inventors: David Tucker
Original assignee: Individual
Current assignee: Individual
Priority date: 2008-10-16
Filing date: 2009-10-12
Publication date: 2010-05-06

Description

- 1 METHOD OF COLLECTING DATA FROM COMPUTERS OVER THE INTERNET FIELD OF INVENTION The present invention relates to methods of collecting data particularly via the 5 internet. The present invention has particular but exclusive use in collecting data regarding the installation and or activation of software on a user's computer. Reference in the specification is made to the collection of data about the installation and activation of software but this is made by way of example only. 10 BACKGROUND OF THE INVENTION The collection of data for confirmation of installation or activation of software or for statistical analysis of software usage is increasingly difficult with the introduction of privacy laws, increased monitoring of data entering and leaving a user's computer (end point) and programmed restriction of certain data types to and 15 from the end point. Data leaving the user's computer to a central location is usually subject to normal scrutiny and censorship associated with firewalls, routers and software applications. Firewalls filter packets of information as they pass through their connection points to block undesirable content, hosts (end points) or group of hosts, 20 or amounts of information and are typically set up to only allow known sources and or services. Routers are often configured to drop or disregard certain types of information packets that are sent through them. Filtering and censoring applications, on the other hand, are designed to filter each packet of information before it leaves the user's computer.

The common method for sending data back to a central location is to either open a TCP/IP socket and send the data or use standard libraries to send information embedded in HTTP requests. Censoring applications and curious end users can examine these communications and filter the data. 5 It is therefore difficult for a software developer to obtain accurate data of a meaningful size and consumer representation range regarding the use of their software. Furthermore different users would have different filters and restrictions so that some packets of data can pass from some end points but not from other end points. 10 OBJECT OF THE INVENTION It is an object of the present invention to provide an alternative method of collecting data from end point computers over the internet that overcomes at least in part one or more of the above mentioned disadvantages. 15 SUMMARY OF THE INVENTION The present invention arises from the observation that standard internet service protocol (trusted protocol) requests such as DNS (Domain Name Services) and NTP (Network Time Protocol) requests are subject to less restriction than other 20 types of requests. With this observation in mind, the present invention was developed by modifying the trusted protocols to encode data but without affecting the request type. In one aspect the present invention broadly resides in a method of collecting data from an end point processor over the internet including -3 having programming operable on end point processor, said programming can form a modified standard internet service protocol request at a particular stage or event, said modified standard internet service protocol request encodes data for collection; 5 sending the modified standard internet service protocol request from the end point processor via the internet to a central location; and retrieving the modified standard internet service protocol request or data encoded in modified standard internet service protocol request from the central location. 10 The collected data may include SKU (Stock Keeping Unit) code, whether a product is installed or uninstalled, whether a product is activated and whether the product was purchased. The modified standard internet service protocol request is preferably based on a standard internet service protocol request. The standard internet service protocol 15 request preferably includes DNS (Domain Name Services) request, NTP (Network Time Protocol) request, ICMP (Internet Control Message Protocol) request, daytime internet protocol request, SMTP (Simple Mail Transfer Protocol) request, time internet protocol request and any other suitable trusted protocol request. More preferably the standard internet service protocol request is a DNS 20 request. In another embodiment the programming can preferably code for the sequential forming and sending of two or more modified standard internet service protocol type requests until a request is successfully sent. Where the end user has censorship and restrictions preferably one of the modified standard internet service 25 protocol type requests can be successfully sent.

-4 Preferably the programming is part of or associated with a software product or firmware product. The modified standard internet service protocol type request is preferably sent when the software or firmware within which the programming is encoded, is installed, 5 uninstalled, activated or when another detectable event has occurred. The data coded within the modified standard internet service protocol type request is preferably encrypted. More preferably the data coded within the modified standard internet service protocol type request is phonetically encrypted to produce a phonetically pronounceable word. Phonetic encryption serves to divert suspicion 10 from what would otherwise be 'strange looking' requests. The modified standard internet service protocol type request may include a randomly generated number to provide a unique request and avoid a server from using previously cached results from earlier requests. The modified standard internet service protocol type request may include a 15 time stamp which may be encrypted to provide a random element and an event recorder. In another aspect the invention broadly resides in programming encoded in software or firmware that codes for forming and sending a modified standard internet service protocol request at a particular stage or event, wherein said modified 20 standard internet service protocol request encodes data for collection or recorded. In another aspect the present invention broadly resides in a modified standard internet service protocol type request as described above. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 25 Example 1 -5 Company A wants to study one of its products to see how many end users are purchasing their software product Y. The product has finished its development phase and is about to be released to the public. It has a numerical 3 digit SKU (Stock Keeping Unit) code of 123. 5 A procedure in the installation process has been identified as the point at which Company A would like to count the end user as being a customer, Product Y has been modified to do a DNS lookup at that identified stage. The modified DNS lookup request consists of the product SKU and the company's domain name being '123.companyascom'. The product SKU of 123 can be hard coded into the modified 10 code itself or looked up from some identifying layout information that would be installed with the product. Because the DNS lookup is only performed during the installation procedure of the product, the product can be considered installed by an end user and ready for use when the DNS is performed. This information is limited as it does not show if the 15 product was tree or purchased or if the user uninstalled the product for some reason and returned it to the place of purchase for a refund. Further DNS lookup requests with modified information can be done to collect this type of information. When the DNS lookup is performed, the operating system contacts it's preferred DNS Server (DNS1) to lookup the IP address that corresponds with the 20 name being requested. If the default DNS server does not have the name in it's cache (because this is the first reference of this name or due to a timeout on the record that was retrieved previously), it will ask one of the Internet's ROOT DNS Servers (DNS ROOT) where to find the DNS Server that holds the relevant information for the domain being requested. The ROOT DNS Server would return -6 the IP address of the DNS Server (DNS2) hosted by Company A. DNS1 then connects to DNS2 to ask it to lookup the name in question. When DNS2 receives the request for '123.companya.com', it knows that product Y has been installed by a user and is now making a DNS call to identify itself 5 as being active. DNS2 can respond to DNS1 with its IP address (or indeed any IP address that it wishes if it is not used by the application for any purpose). Nevertheless an IP address should be returned to comply with the published DNS RFC and avoid unnecessary scrutiny because of irregularities. DNS2 can then record the fact that a request from product 123 has been 10 made by removing the companya.com part of the request. The information can then be collated at a later date into a report showing when each product Y was installed. Example 2 Company B wants to study the take up by end users of product X inside a 15 large corporation. In this example, Company B is selling its software product X with a SKU of 456 mainly to large corporations. Due to the fact that DNS Servers cache requests by remembering results of previous requests, other information needs to be added to the DNS request to alleviate this caching. ONS Servers are typically configured within the standard DNS infrastructure to remember request results for a 20 predetermined time that is embedded within the DNS result sets themselves. As in example 1, Company B has identified a stage in the installation procedure at which it would like to count its users. This time however the DNS request is constructed slightly differently in that an extra random field is added to the fully qualified domain name. For example; where the product SKU is 456 and the 25 company's domain name is companyb.com, this information would be put together -7 with a randomly generated number or string to look something like '45O6xdsejd.companyb.com'. The random string component of the address needs be to be of sufficient size and complexity so that there would be little chance of being generated twice in a 5 period of time that a DNS server may remember the results of the requests. When Company B's DNS server answers the request, it simply discards the random component of the request and record the product SKU the same as in Example 1. 10 Example 3 Company C wishes to identify when a user installs and uninstalls a product Z. In this example Company C wishes to know how many copies of a product Z are installed at any one time. The product Z with a SKU of 789 is installed and uninstalled by users on a regular basis. To identify a user a session key is given to 15 each user so that when the installation is performed, the same key can be passed to an uninstall routine. With the product 2, a stage in the installation and un-installation procedures is identified at which Company C would like to count the end user as being a customer. At this stage the product Z initiates a DNS lookup with a modified DNS lookup 20 request. As with example I and 2, a fully qualified name is created from the product SKU and the company name to create '789.install.companyc.com'. When the product Z is installed, it executes a DNS lookup on '789.install.companyc.com', However this time instead of Company C's DNS servers responding with an unimportant IP address, it responds with an identifying marker.

-44 The DNS server knows to respond with the marker instead of the simple request type by decoding special instructions within the modified DNS request itself. For example in the modified DNS request, the word "install" is encoded within the request and Company C's DNS servers interpret the word "install" as the product 5 Z has been installed. Company C's DNS server responds with a unique identifying marker. This marker could be an IP address or an alias for another lookup (such as, DNS CNAME). A unique marker is allocated every time the initial DNS request is made each time an installation is performed by an end user. If the marker were to be an IP address it could look something like 1.1.1.1 for 10 one user and 1.1.1.2 for another user. If the marker was a CNAME, it could be a string encoded unique ID within a fully qualified domain name such as 'xxxw2essaq2e3de.uninstall.companyc.com'. When the marker is returned to the installed product Z, it stores the marker locally for use when the application is uninstalled. 15 When the application is uninstalled, it looks up the stored marker and uses it to perform another DNS request. If the marker was in the form of an IP address, it would be encoded into a format that resembles a fully qualified domain name such as '1-1-1-1.uninstall.companyc.com'. If the marker was a CNAME then it could be used as is or translated into something else if required. The product Z then executes 20 a DNS lookup with this domain name. Company C's DNS server then decodes the DNS request, matching the initial marker given to the product with the installation procedure and the current request so that the un-installation can be recorded correctly.

ADVANTAGES The advantage of the preferred embodiment of the present invention is that it allows information to be sent over the internet about an installed software product without restrictions or censorship. 5 The preferred embodiment is programming that codes for the forming and sending of a modified standard internet service protocol type request to provide information that a software or firmware product has been installed, uninstalled, activated or other event has occurred. The programming is encoded within the software or firmware product. 10 VARIATIONS It will of course be realised that while the foregoing has been given by way of illustrative example of this invention, all such and other modifications and variations thereto as would be apparent to persons skilled in the art are deemed to fall within 15 the broad scope and ambit of this invention as is herein set forth. Throughout the description and claims this specification the word "comprise" and variations of that word such as "comprises" and "comprising", are not intended to exclude other additives, components, integers or steps. 20

Claims

1. A method of collecting data from an end point processor over the internet including 5 having programming operable on end point processor, said programming can form a modified standard internet service protocol request at a particular stage or event, said modified standard internet service protocol request encodes data for collection; sending the modified standard internet service protocol request from the end 10 point processor via the internet to a central location; and retrieving the modified standard internet service protocol request or data encoded in modified standard internet service protocol request from the central location. 15

2. A method as claimed in claim 1, wherein the modified standard internet service protocol request is based on a standard internet service protocol request including DNS (Domain Name Services) request, NTP (Network Time Protocol) request, ICMP (Internet Control Message Protocol) request, daytime internet protocol request, SMTP (Simple Mail Transfer Protocol) request, time internet 20 protocol request and any other suitable trusted protocol request.

3. A method as claimed in claim 1 or 2, wherein the data encoded in the modified standard internet service protocol request includes SKU (Stock Keeping Unit) code, whether a product is installed or uninstalled, whether a product is 25 activated and whether the product was purchased. - 11

4. A method as claimed in any one of the above mentioned claims, wherein the modified standard internet service protocol request is a DNS request.

5 5. A method as claimed in claim 1, wherein the programming codes for the sequential forming and sending of two or more modified standard internet service protocol type requests until a request is successfully sent.

6. A method as claimed in claim 1, wherein the programming is part of or 10 associated with a software product or firmware product.

7. A method as claimed in claim 1, wherein the modified standard internet service protocol type request is sent when the software or firmware within which the programming is encoded, is installed, uninstalled, activated or when another 15 detectable event has occurred.

8. A method as claimed in claim 1, wherein the data coded within the modified standard internet service protocol type request is encrypted. 20

9. A method as claimed in claim 8, wherein the data coded within the modified standard internet service protocol type request is phonetically encrypted to produce a phonetically pronounceable word,

10. A method as claimed in any one of the proceeding claims, wherein the 25 modified standard internet service protocol type request includes a randomly - 12 generated number to provide a unique request and avoid a server from using previously cached results from earlier requests.

11. A method as claimed in any one of the preceding claims, wherein the modified 5 standard internet service protocol type request may include a time stamp which may be encrypted to provide a random element and an event recorder.

12. A method as substantially described herein with reference to the preferred embodiments. 10

13. Programming encoded in software or firmware that codes for forming and sending a modified standard internet service protocol request at a particular stage or event, wherein said modified standard internet service protocol request encodes data for collection or recorded. 15

14, A modified standard internet service protocol type request as claimed in any one of the preceding claims. 20