CA2411034A1

CA2411034A1 - Online machine data collection and archiving process

Info

Publication number: CA2411034A1
Application number: CA002411034A
Authority: CA
Inventors: Timothy P. Barber
Original assignee: Telecheck Services, Inc.; Timothy P. Barber; Keynetics Inc.; Kount Inc.
Current assignee: Kount Inc
Priority date: 2000-06-07
Filing date: 2001-06-05
Publication date: 2001-12-20
Anticipated expiration: 2021-06-05
Also published as: US10037529B2; US7937467B2; US20020035622A1; US20150193769A1; US20110218877A1; AU2001275217A1; CA2960857A1; US8539070B2; US8799458B2; US20110218860A1; WO2001097134A1; EP1305753A1; US7330871B2; US20180300719A1; US20110218856A1; US8150968B2; US20080133420A1; US10679216B2; CA2960857C; CA2411034C

Abstract

An online machine data collection and archiving process (15) generates a machine data profile (18) of a customer computer (5) accessing a transaction form of a merchant web site (3) and links the machine data profile (18) and a transaction record (6) with customer identifying information using a unique transaction identification string. The process preferably captures parameters typically communicated as part of web accesses, such as an IP address, an HTTP
header, and cookie information. The process additionally causes the customer computer (5) to process self-identification routines by processing coding within the merchant transaction form, the self-identification routines yielding further profile parameters. The process further includes a routine for bypassing an intervening proxy to the merchant web site (3) to reveal the true IP address of the customer computer (5).

Description

2

3 Cross-Reference to Provisional. Application

4 This application claims benefits from provisional application, Serial No.
60/209,936 filed June 7, 2000 and entitled METHOD FOR COLLECTINGMACHI13E
6 DATA FROM CUSTOMERS ON A COMPUTER NETWORK.

8 Back~roand of the Invention 9 The present invention relates to identity detection techniques and, more particularly, to a process for collecting and utilizing machine-identifying data of computers 11 and other online appliances used in online interactions and transactions and associating the 12 collected machine data with such online interactions.
13 The Internet, or global computer network, represents a new medium for marketing 2 4 similar to the way mail ordering and telephone ordering did in the past. A
downside of Internet marketing is that it also presents new opportunities for unscrupulous parsons to 2 6 take advantage of the mechanisms of Internet transactions by fraudulent and deceptive 17 practices. Merchants and f nancial institutions bear the initial costs of fraud. However, 18 consumers ultimately pay the costs in the form of prices and credit rates which must take 19 into account losses from fraud. Internet purchases typically involve the use of web page 2 o forms which are filled in by the customer with identity, address, purchase, shipping, and 1 payment information and submitted' to the online merchant for processing.
Internet 2 purchases are most often paid for by way of credit cards. While a merchant's software 3 may be able to verify the existence and status of a credit card account number and an 4 authorization for a specific amount, the merchant is often not able to match a credit card number with a specific purchaser or shipping address. Thus, absent any overt indication 6 otherwise, a merchant generally assumes that anyone using a credit card is auth4rized to 7 do so and that a customer is who he identifies himself to be.
8 An important step in combating fraud is accurate identification of the computers 9 through which customers make transactions and associating such identities with transactions which arouse suspicions or which ultimately turn out to be fraudulent. Basic 11 machine identity is essential to the manner in which the Internet operates.
We speak in 12 terms of "going" to a web site. In reality, "going" to a web site involves sending a request 13 for a web page file in a directory or folder on a computer located at a specific Internet 14 protocol, or IP; address. In order for the web page file to be returned to the requesting computer for processing into a displayed "web page", the request must include return 16 "directions" in the form of the basic identity of the requesting computer, including its IP
17 address. Some web sites are implemented with software which enables responses to web 18 page requests to be tailored to specifics of the requesting machine's configuration, specific 19 web browser, and the like. For this reason, current versions of browsers usually 2 0 communicate configuration information in addition to a return 1P address and return path.

1 The IP address of a page requesting computer can give an indication of the specific 2 country where the computer is located. ~ Further, identification of a page-requesting 3 computer can also recognize a returning user using the same computer as during a 4 previous access. For example, placing an HTTP (hypertext transfer protocol}
"cookie" on a page-requesting computer can make it possible to identify the computer on a later 6 access.
7 Because direct interaction with a customer's computer is essential in detecting 8 fraud, it has been assumed that any viable fraud detection software must be integrated with 9 a merchant's software. As a result, most existing fraud detection solutions require merchants to either abandon or extensively modify their existing web-based transaction 11 processing software. An additional problem with focusing fraud detection at single 12 merchants is that perpetrators of fraud often hit many merchants in an attempt to avoid or 13 delay detection. Thus, an ideal system for fraud detection in online marketing would' only 14 minimally affect the merchant's existing software and would route fraud detection efforts through a central, third-party entity serving a large multitude of merchants.

17 Summary of the Invention 18 The present invention provides a process for collecting data associated with a 19 customer's computer during access of a merchant, financial, other host web site, and 2 0 associating a transaction identification number with the data and with a transaction form of 21 the merchant. Generally, the present invention captures machine identifying data from a 1 computer or other digital appliance accessing a host web site, sends the captured data to a 2 machine data archive along with a unique transaction identification string for storage in the 3 archive and writes the same transaction identification string into a transaction form 4 through which transactions with the host web site are conducted. The machine data is, thus, associated with the customer identification data within the transaction form by way 6 of the transaction identification string and can be used on-the-fly or at a later time for a 7 variety of purposes including, but not limited to, fraud detection. Although the term 8 "archive" is used, the machine data collected need not be stored permanently.
9 The machine data collection process of the present invention is intended to be employed in a variety of applications including, but not limited to: online purchases and 11 orders; online banking, bill: payment, and funds transfers; online registrations, such as for 12 memberships, product warranties, applications for credit, renewal of subscriptions and-13 licenses; online technical support; and the like. The term "transaction" is used in the 14 present invention to describe an interaction effected between a digital appliance and a host system. However, the term "transaction" is not intended to be restricted to only 16 commercial interactions involving purchases. The term "transaction" is intended to apply 17 to an interaction of a remote digital appliance with a host system using a relatively 18 anonymous type of access process over a digital medium iri which some form of self 19 identification of the accessing appliance is inherent in the access process and in which the 2 0 true identity of the accessing party, the true source address of the appliance on the 1 medium, and/or the true machine characteristics of the accessing appliance is/are essential 2 or desirable to the interaction.
3 The host entity which operates the host system accessed is intended to encompass 4 a commercial, financial, educational, governmental, associational, or other type of entity.
The term "merchant" will be used herein to refer to such a host entity without intent to 6 limit the present invention to commercial transactions. The medium of access is intended 7 to be interpreted as including a global computer network such as the Internet or world 8 wide web, as well as other types of networks which may be less than global but which are 9 publicly and/or anonymously accessible. The term "Internet" will be used herein to refer to the medium through which accesses to the host entity are made. The terms "customer 11 computer" or "machine" are used herein to refer to a device for effecting remote access to 12 a host system over a digital' medium and are meant to encompass not only conventional 13 types of personal computers, but also additional types of"digital appliances" with online 14 access capabilities, such as: cell phones, personal digital assistant devices, electronic game systems, television sets with online access capabilities, web appliances for vehicles, and 16 any other type of device with online access capabilities whether connected to a wired 17 communications network directly or by a radiant technology.
18 The machine data collection process of the present invention contemplates a two 19 party process embodiment in which a "merchant" processes and/or stores machine data 2 0 profiles of customer computers in-house, as well as a three party process embodiment in

5 1 which machine data profiles of customer computers are processed and/or stored for the 2 merchant by a third-party machine data collection and archive service.
3 In a two party embodiment of the data collection process of the present invention;
4 the customer machine data is captured by a merchant or host system which also generates a unique transaction identification (ID) string and assigns or associates the transaction ID

6 with a machine data profile of the customer machine data profile. In the two party

7 process, the merchant system captures customer computer data which is inherently passef

8 from the customer computer to the merchant's web site, such as an IP address of the

9 customer computer and an HTTP header. Additionally, according to the present invention, the merchant web page code may have routines or calls for external routines 11 which, when processed by the customer computer, cause the customer computer to 12 further identify itself by collecting and returning certain machine and software 13 configuration. characteristics, which can be used to ifentify the particular customer 14 computer. The two party process may include the generation and setting of an HTTP
I 5 cookie in the customer browser for recognition upon a later access with the merchant web 16 site.
17 Although the two-party embodiment of the machine data collection process of the 18 present invention has utility for some applications, the three party embodiment is preferred 19 for applications in which analysis of a maximum number of customer computer profiles is 2 0 desirable, such as certain types of marketing processes and fraud detection and control 21 processes. In a three embodiment of the present invention, the customer machine data of 1 computers accessing the second party or merchant web site is communicated to and stored 2 within a third party system, referred to herein as a machine data archive service. In the 3 three party process, the transaction m could be generated by the merchant system, but is 4 preferably generated by the .archive service. The use of the term "archive"
is not meant to . indicate that the customer machine data profiles are stored permanently within the third 6 party system. Permanent storage of such profiles may not be practical, as far as yielding 7 beneficial results to the purposes for which the profiles are collected.
Thus, the term 8 "archive" is meant to indicate a central storage facility, such as a database, with a selected 9 retention period, with purging of most profiles after a certain length of time.
In the three party process a routine or line of code is added into the hypertext 11 markup language (HTML) code which defines the merchant's web page, particularly an 12 order or transaction form page. The added routine issues a request for a machine data 13 collection (MDC) script to the third-party web site when the form page code is processed 14 by the customer's browser. When the script request is received by the machine data archiving service (MDAS), the archive service generates a unique transaction 16 identification (TA/ID) and checks for its own cookie. If no MDAS cookie is present, the 17 archive service sends a cookie to the requesting computer along with a machine data 18 collection (MDC) script having the transaction m embedded therein. The MDC
script is 19 executed by the customer's browser, causing collection of certain data from the 2 0 customer's computer which is sent back to the archive service along with the transaction 21 m and stored in a machine data profile in the machine data archive. The transaction ll7 is 1 written into the transaction form, and when the transaction form is submitted to the 2 merchant web site, the transaction ID string becomes a part of the transaction data record, 3 along with customer identification, location, and financial information.
4 The machine data initially collected and stored~in each profile preferably includes the transaction ID, the apparent IP address of the customer's computer, a conventional 6 HTTP header which identifies the customer's browser versions and certain configuration 7 aspects of the browser, and the archive service's cookie. The combination of such 8 information, minus the transaction ID, will be relatively rare but may not be unique.
9 Additionally, customers intent on conducting fraudulent transactions often hide their IP
address behind HTTP proxies. In order to further narrow the machine profile, in a 11 preferred embodiment of the present invention, the lViDC script performs additional 12 machine profiling operations: generation. of a machine "fingerprint" and a proxy 13 "piercing" operation.
14 In the fingerprint generation operation, the MDC script assembles an attribute string formed by various attributes or configuration settings of the browser which can be 16 queried by the script. The MDC script then performs a conversion process on the 17 attribute string to generate a fingerprint string having content which is a function of the 18 original content of the attribute string. The conversion process is preferably a "hashing"
19 function which is, in erect, an irreversible encryption algorithm. The generation of a 2 0 conventional checksum is one example of a type of hashing function. For-example, if the 21 attribute string is formed by alphanumeric characters, the conversion process is performed 1 on the string of codes representing the characters. The particular conversion process or 2 hashing function used may be one of many types of conventional conversion algorithms or 3 hashing functions, which are typically used for data integrity tests. The resulting string 4 from the MDC conversion process is a so-called fingerprint, which is returned to the archive service along with the transaction ID for storage in the machine profile. A time 6 value, queried from the customer computer time-of day clock, is returned with the 7 fingerprint string and stored in conjunction therewith.
8 An HTTP proxy is one of several types of proxies through which a browser may 9 be setup to operate. Setting up an HTTP proxy causes HTTP requests to be relayed by a primary gateway, through which the computer actually interfaces to the Internet, to a 11 remote secondary gateway, or proxy, with an IP address different from the primary 12 gateway IP address. Such redirection hides the true IP address of a computer. The proxy 13 piercing operation of the MDC script queries the customer computer for any LAN (local 14 area network) address which may be assigned to the computer and reads the system time of day clock. Then attempts are made to send the LAN address, if any, the time value, 16 and the transaction ID to the archive service using a protocol which will not be redirected 17 through the HTTP proxy, for example a lower level protocol such as TCPlIP
or UDP
18 protocols. If the attempt is successful, the message containing the time value, the 19 transaction ID, and LAN address arnve at the archive service web site with the true return 2 0 IP address of the customer computer, whether an HTTP proxy intervenes or not. The 21 LAN address and IP address so derived are stored in the machine profile. It should be 1 noted that the use of an FiTTP proxy is not, of itself, an indication of fraud. However, the 2 acquisition of an additional IP address is one more parameter with which to identify a 3 particular computer.
4 When, and if, the customer submits the transaction form to the merchant, the transaction m string is communicated to the merchant; along with other customer 6 information such as name, address, credit card number and the like plus transaction 7 information. The complete transaction record is stored on the merchant's system and is 8 associated with a specific machine identity profile within the archive service by way of the 9 transaction m string. Thereafter, the stored machine identity profiles and transaction records of large numbers of transactions can be analyzed by various fraud detection 11 techniques to detect patterns of fraud and fraud' attempts and, preferably, identify and 12 locate the sources of such activity.
13 The machine data profiles stored in the archive service need not be combined with 14 the customer identification information for non-suspicious transactions, to thereby preserve the privacy of non-suspicious customers within the machine data archive.
16 However, the processes of the present invention do not require that the customer 17 identification information be kept separated from any associated machine data profiles, and 18 there may be reasons to combine the associated records.

10 1 Brief Description of the Drawings 2 Fig. 1 is a simplified block diagram illustrating a plurality of customer and 3 merchant computers interfaced' to the Internet along with a machine data archiving service 4 computer for practicing the machine data collection process of the present invention.
Fig. 2 is a simplified block diagram illustrating connection of a customer computer 6 to the Internet, with optional components shown in phantom lines.
7 Fig. 3 is a flow diagram illustrating principal steps of the machine data collection 8 and archiving process according to the present invention.
9 Fig. 4 is a flow diagram illustrating more detailed steps of the machine data collection and archiving process according to the present invention.

11 Fig. 5 is a flow diagram illustrating a still further detailed steps in the machine data

12 collection and archiving process of the present invention.

13 Various objects and advantages of this invention will become apparent from the

14 following description taken in relation to the accompanying drawings wherein are set forth, by way of illustration and example, certain embodiments of this invention.
16 The drawings constitute a part of this specification, include exemplary 17 embodiments of the present invention, and illustrate various objects and features thereof.

1 Detailed Description of the Invention 2 As required, detailed embodiments of the present invention are disclosed herein;
3 however, it is to be understood that the disclosed embodiments are merely exemplary of 4 the invention, which may be embodied in various forms. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a 6 basis for the claims and as a representative basis for teaching one skilled in the art to 7 variously employ the present invention in virtually any appropriately detailed structure.
8 Referring to the drawings in more detail:
9 The reference numeral 1 (Fig. 3) generally designates a process for online collection of machine identifying or profiling data of computers 11 involved in commercial transactions and for archiving such data to facilitate analysis for 12 fraud detection purposes. The process collects machine identifying or profiling data of 13 computers involved in commercial transactions and archives such data in a third-party 14 machine data archive service in association with a transaction identification string or Il7 which is also written into a transaction form of a merchant with whom the customer is 16 conducting a transaction.
17 Fig. 1 illustrates a plurality of host entities or merchants with corresponding 18 merchant computers 2, on which are operated merchant web sites 3 which are accessible 19 over a global computer network, such as the Internet 4, by a plurality of customer 2 0 computers 5. The merchant computers 2 execute various programs which enable the sale 21 of products or services by way of the Internet 4. The merchant web sites 3 typically make 1 use of form type web pages with which the customers 5 interact by filling in various data 2 fields, for example, name, address, shipping address, telephone number, credit card type 3 and number and expiration date, and description and quantities of products to be ordered.
4 The merchant transaction forms are usually written in hypertext markup language (HTML) and may include requests for code written in other languages, such as Java and 6 the like. When a customer 5 accesses a merchant's transaction form, a transaction form 7 file is communicated to the customer's computer with various data fields displayed as fill-8 in boxes or the like. The customer fills in the appropriate fields and selects a submit 9 "button" which activates a routine to transfer the collected information back to the merchant web site 3 for processing. The returned "form" is a data record 6 which is 11 stored in a merchant transaction database 7 for retrieval and processing in due course to 12 cause the ordered items to be gathered, packaged and prepared' for shipment, along with;
13 financial processing to debit the customer's credit account. The financial processing may 14 include a validity check of the credit account and an authorization check for the amount of purchase with the credit card issuer. Additionally, inventory management processes are 16 executed based on the items withdrawn from stock for shipment.
17 In a three party embodiment of the present invention, the process 1 makes use of 18 an entity referred to herein as a machine data archiving service, MDAS or archive service;
19 which operates an archive service computer system 15, including an archive service web 2 0 site 16. The archive service system 15 maintains a machine data archive service database 21 or archive 17 in which the machine data collection profiles.18 from customer computers 5 1 of the merchants 2 are stored. The archive service web site 16 is interfaced to the Internet 2 4. The archive service 15 is preferably independent of the merchants and may be operated 3 by a merchants' association, a financial institution or association thereof, or may be an 4 independent contractor. Alternatively, it is conceivable that a merchant with a high volume of online sales could operate its own in-house machine data profile collection and;
6 archiving service 15, for fraud detection or possibly for marketing purposes.
7 Referring to Fig. 2, a customer computer system 5 includes a customer computer 8 20 interfaced to the Internet 4 by way of a primary gateway 22, as of an Internet service 9 provider (ISP). The computer 20 might be one of many on a local area network or LAN
24 which includes a router or switch which routes data from the Internet 4 to the 11 computers on the network. The computer 20 may communicate through the Internet 4 by 12 way of a I3TTP (hypertext transfer protocol) proxy 26, which disguises the Internet 13 protocol (IP) address of the actual gateway 22. The computer 20 accesses web sites on 14 the Internet 4 using a customer web browser 28 which processes HTML
language and various other standard web oriented languages to display or otherwise render the content 16 of web pages and interact therewith. The browser 28 is normally enabled to accept I 7 "cookies" 30 which are stored in a cookie file. Cookies 30 are data strings which are 18 issued by Web sites and give an indication of a previous visit to a particular web site and 1 ~ may indicate a particular configuration or set of preferences of the customer's setup of the 2 0 computer 20. Typically, the customer computer 20 has a time of day clock/calendar 32.

1 The customer computer 20 may have a fixed IP address, depending on the manner 2 in which it is interfacedAto the Internet. ll~iore commonly, the customer computer 20 will 3 have a temporary or dynamically assigned IP address which is determined by the primary 4 router 22. The primary router 22 has an 1P address, as do a router of a LAN
24 or an HTTP proxy 26 if either is present in the customer's computer system 5.
6 Fig. 3 illustrates the principal actions or steps of a general or basic process 34 of 7 the process 1 for collecting machine identifying data from customer computers 5. At step 8 35, at least one machine identifying profile parameter is captured upon access of a 9 customer computer 5 or other online access device with a host or merchant web site 3. A
unique transaction identifier or TA/lD is generated at 36 and associated at 37 with the 11 captured profile parameter. The transaction >D is also associated at step 38 with a 12 transaction record generated as a result of the interaction or transaction conducted 13 between the customer computer 5 and a merchant web site 3. Although not specifically 14 shown in Fig. 3, the process 34 may capture machine profile data that is passed from the customer computer 5 to the merchant computer 3 as an inherent step of the customer 16 computer 5 accessing the merchant computer 3. Alternatively, the process 34 may pass 17 routines to the customer computer 5 to cause it to "self identify" itself by querying certain 18 configuration parameters and passing such information to a: machine profile stored either 19 within the merchant's system 2 or in a third party archive 17. The process 34, thus, 2 0 encompasses a two-party embodiment or a three party embodiment of the machine data 21 collection and archiving process 1 of the present invention.

1 Refernng particularly to Fig. 4, a more particular three party embodiment of the 2 machine data collection and archiving process 1 begins at step 40 with the coding of a 3 machine data collection (MDC) script request into the web page code for a transaction 4 form of a merchant web site 3. When a customer S accesses the merchant transaction form at step 42, the customer browser 28 processes the transaction page code, including 6 the MDC script request, which causes the MDC script request to be communicated to the 7 archive service web site 16 at step 44. The script request arrives at the archive service 1 S
8 with a set of customer machine parameters which principally provide a return path for the 9 MDC script from the archive service 15 to the customer S. The customer machine parameter set preferably includes "user agent" information, which is the version of the 11 customer browser 28.
12 At step 46, the archive service 15 generates a unique transaction m string and 13 associates it with the customer machine parameter set in the MDAS archive 17. At step 14 48, the archive service returns the MDC script, with the transaction m embedded within it, to the customer browser 28. At step 50, the customer browser 28 processes the MDC
16 script which, at a minimum, writes the transaction D? string into the merchant's transaction 17 form. Assuming that the customer 5 completes the transaction and submits the transaction 18 form to the merchant 2 at step 52, the transaction B7 string is stored with the transaction 19 data record 6 in the merchant transaction database 7. The transaction ID, thus, indirectly 2 0 associates the machine data parameter set 18 stored in the MDAS archive 17 at step 54 21 with the customer identity information stored with the transaction data record 6 in the 1 merchant's transaction database 7. Thereafter, qualified parties may access the MDAS
2 archive 17 for information related to a transaction B7.
3 The MDAS archive 17 need not contain any information which specifically 4 identifies a particular customer, only the machine parameter profiles 18 with associated transaction m strings. The MDAS archive records 18 can be analyzed in conjunction with 6 the merchant transaction records for patterns of fraud or for other purposes. The great 7 majority of MDAS archive records can be purged from the archive 17 after a selected 8 period of time. Any records which are associated with any transaction irregularities or 9 suspicions of actual fraud may be retained longer.
Fig. S illustrates the principal steps of a preferred embodiment 60 of the machine 11 data collection and archiving process 1 of the present invention. The process 60 begins 12 with the addition at 62 of a machine data collection (MDC) script to the transaction (TA) 13 form page code of a merchant web site 3. The transaction form page code is processed at 14 64 by a customer browser 28 when the merchant web page is accessed to thereby request the MDC script at 66 from the Machine data archive service (MDAS) web site 16.
When 16 the browser 28 accesses the MDAS web site 16, requesting the MDC script, the MDAS
17 web site checks far the presence of an MDAS cookie at step 68. If no MDAS
cookie is 18 detected, an MDAS cookie is generated at 70 and a uniquevtransaction identification 19 (TA/m) string is generated at 72. The MDC script, transaction m, and cookie, if not 2 0 previously set, are returned at 74 to the customer browser 28, the transaction m being 21 embedded within the MDC script.

1 When the MDC script is received by the browser 28, it is executed at 76. The 2 cookie is stored in the cookie file 30, or.possib~y in the memory of the customer computer 3 20. Execution of a preferred MDC script causes several actions to be performed. The 4 MDC script writes the transaction m into the transaction form at step 78.
The script can do this by either setting an existing variable of an appropriate name to the transaction m 6 string or by writing an appropriate variable into the transaction form page and setting its 7 value to the transaction 1D string. Additionally, the preferred MDC script generates a 8 "fingerprint" of the customer computer 20 at step 80 and attempts to perform a proxy 9 piercing operation at step 82.
In generating the machine fingerprint at 80, the 1V~7C script queries the browser 28 11 for a number of attributes and settings and concatenates the results into an attribute string 12 at 84. The 11~C script then performs a hashing algorithm on the. attribute string at 80 to 13 generate a fingerprint string which has a high degree of uniqueness.
Hashing functions are 14 irreversible encryption processes in which the result is dependent on the original content of the data on which the hashing algorithm is operated. Hashing functions are commonly 16 used for data integrity checking. As previously stated, a common checksum is the result 17 of a type of hashing function. The particular hashing function employed preferably 18 maximizes the uniqueness of the resulting fingerprint.
19 At step 86, the customer computer clock 32 is queried for a current time value. At 2 0 step 88, the fingerprint, the transaction ll~, and the time value are communicated to the 1 MDAS web site 16 along with an HTTP header with cookie and "apparent" IP
address, all 2 of which are stored as a machine data profile 18 within the MDAS archive 17.
3 At step 90, the MDC script adds a proxy piercer request to the transaction form 4 which, when executed by the browser 28 at step 92, sends a request for a proxy piercer applet or code to the MDAS web site 16. When the proxy piercer applet/code is executed 6 by the browser 28 at 94, a time value from the clock 32 is again queried at 96 and any 7 existing local area network (LAN) address is queried at 98. At step 100, the proxy piercer 8 applet/code sends the time value, the LAN address (if any), and the transaction ID to the 9 MDAS web site 16 by a protocol which bypasses any existing HTTP proxy 26.
The protocol used is one which is at a lower level than HTTP, such as UDP (user datagram 11 protocol) or, preferably, TCPlIP (transmission control protocol/internet protocol).
12 Bypassing the HTTP proxy 26 causes the data sent in step 100 to arnve at the 13 MDAS web site 16 with the IP address of the primary gateway 22, which may be different 14 from any apparent IP address previously recorded if an HTTP proxy 26 intervenes. If the proxy piercer procedure 82 is successful, the primary gateway 1P address is stored at step 16 102 within the machine data profile 18 identified by the transaction ID. It should be noted 17 that some types of proxies, such as some types of firewalls, may block all non-HTTP
18 protocol packets, so that the proxy piercer procedure 82 might not be successful in all 19 cases.

1 If the customer completes the transaction with the merchant web site 3, the 2 transaction form is submitted at step 104, which causes the transaction record 6, including 3 the transaction >D, to be stored at step 106 in the merchant database 7 for processing.
4 Following are examples of code for an MDC script, as from steps 40 or 62.
Assuming the machine data archiving service or MDAS web site 16 has the fictional URL
6 (uniform resource locator) example-url.net and a specific merchant has a merchant 7 identifier h~llvIM, a line of HTML code is added at step 40 to the transaction form of 8 merchant N.111~iM between the <form> and </form> HTMI, tags which has the form:

<script src=https://www.example-url.netls/?MlVfiVlS</script>

12 When the customer browses 28 processes the transaction form at step 42, it 13 requests a script file from the source URL: https://www.example-url.net/s/?MIVtM.
14 At step 44, the customer web browses 28 requests the MDC script by way of the HTTP protocol. The HTTP request includes the merchant JID MMM, the user agent 16 (browses version), the IP address of the customer's HTTP proxy, and any HTTP cookies 17 previously sent to the customer by www.example-url.net. Upon receiving this 18 information, the archive service 16 records this information in a machine data record 19 which also includes the transaction 1D.
2 0 Upon receiving the file request, the archive service 16 generates a unique 21 transaction m (represented below as ZZZ) at step 46 to be associated with the transaction 1 and the machine parameter set. An exemplary transaction m is a string of 24 letters and 2 digits. The first eight digits form a time.stamp.which is a hexadecimal representation of 3 the seconds elapsed since midnight January 1, 1970 T1TC (coordinated universal time).
4 In the preferred embodiment of the process 1, the MDC script is written in an ECMAScript compliant language, such as JavaScript, JScript, or VBScript. A
JavaScript 6 version of the MDC script is as follows (linebreaks and indentations added for clarity):

8 document.write("<input name--transactionid type=hidden value=ZZZ>;

drew Date;

12 t=3600*d.getHours~+60*d.get112mutes0+d.getSeconds~;

14 document.write("<img height=1 width=1 src=https://www.example-url.net/t/?i ZZZ&t="+t+">");

17 document.write("<applet height=1 width=1 18 codebase=https://www. example-url.net/
19 code=a/?ZZZ>
2 0 <param name--i value=ZZZ></applet>");

1 The exemplary MDC script includes the unique transaction 1D value in several 2 places. When the script executes on the customer computer 20, it writes HT1VII, code into 3 the merchant's order form. Specifically:
4 1). The script adds a hidden variable called "transactionid" to the merchant's transaction form and assigns it the value of the transaction ID (ZZZ). When the 6 transaction form is submitted, the merchant receives the transaction D7. and can associate 7 it with the transaction data record.
8 2) The script computes the seconds elapsed since midnight on the clock 32 9 and writes a request for a 1 pixel by 1 pixel image. Included in the request is the transaction ID and the time value. When the request executes, this data is sent back to the 11 archive service 16 and recorded with .the transaction ID in the MDAS
archive 17.
12 3) The script adds a request for a program located at the archive, service web.
13 site 16 which, in this example, is a Java applet. The applet downloads to the customer 14 computer 20 from the archive service 16 and executes, appearing as a 1 pixel by 1 pixel image on the transaction form. The transaction ID is passed to the program as a 16 parameter specified in the script. The program performs three tasks:
17 a) it calculates TTT, the seconds elapsed since midnight on the system clock 18 32;
19 b) it calculates AAA, the address of the customer 20 on its own local area 2 0 network 24; and 1 c) it sends this data back to the archive service 16 via TCP/IP, by requesting 2 the following URL:
3 http://www.example-url.net/d/?i ZZZ&t=TTT&a=AAA
4 The archive service 16 receives the message which includes the parameters TTT, AAA, and ZZZ. The message also includes the IP address of the sender. This address is 6 the customer's actual IP address, which in some cases is different from the HTTP proxy IP
7 address. The archive service 16 records this information in the MDAS archive 17 and 8 associates it with the transaction m ZZZ.
9 The machine data collection and archiving process 1 of the present invention has been described with a particular application in fraud detection. However, it is foreseen 11 that the techniques of the present invention have a wider application, as for marketing or 12 computer support purposes; or other functions. While the process 1 has been described 13 with reference to the Internet 4 or world wide web, it is also conceivable that the process 1 14 could be employed on computer networks of less than global expanse, such as a large intranet, a national or regional network, or the like.
16 Therefore, it is to be understood that while certain forms of the present invention 17 have been illustrated and described herein, the present invention is not intended to be 18 limited to the specific forms, arrangement of parts, sequence of steps, or particular 19 applications described and shown.

Claims

1. A process for collecting machine identifying information associated with a digital online access device used for substantially anonymously accessing a host computer system over a digital network, said host computer system generating an interaction record of an access therewith by said access device, and said process comprising the steps of:
(a) capturing a machine identifying profile parameter upon said access device accessing said host computer system;
(b) generating a unique interaction identification string upon said access device accessing said host computer system;
(c) associating said interaction identification string with said profile parameter;
and (d) associating said interaction identification string with said interaction record generated upon said access device accessing said host computer system.

2. A process as set forth in Claim 1 wherein said capturing step includes the step of (a) capturing a digital address of said access device on said digital network.

3. A process as set forth in Claim 1 wherein said capturing step includes the step of (a) capturing a configuration setting of said access device.

4. A process as set forth in Claim 1 and including the steps of:
(a) communicating a self-identification routine to said access device upon said access device accessing said host computer system;
(b) said access device executing said self-identification routine;
(c) said self identification routine querying a configuration setting of said access device to derive said profile parameter; and (d) said self identification routine communicating said profile parameter to a remote location for association with said interaction identification string.

5. A process as set forth in Claim 1 and including the steps of:
(a) said host system operating a host web site including an interaction page generated by interaction page code processed by said access device upon accessing said host web site; and (b) coding, within said interaction page code, a self-identification routine which causes said access device to communicate said profile parameter when said access device processes said interaction page code.

6. A process as set forth in Claim 3 and including the step of:
(a) coding said self-identification routine in such a manner that said profile parameter and said interaction identification string are communicated to a third party web site at which said profile parameter and said interaction identification string are stored.

7. A process for identifying a customer computer involved in an online transaction between a customer using a customer browser operating on said customer computer and a merchant operating a merchant web site, said method comprising the steps of:
(a) capturing a customer computer profile parameter upon said customer computer accessing said merchant web site;
(b) generating a transaction identification string and associating said string with said parameter;
(c) storing said parameter and said string in a machine data archive;
(d) upon said customer completing a transaction through said merchant web site, storing said transaction identification string with a transaction record formed during said transaction to thereby associate said parameter with said transaction record through said string.

8. A process as set forth in Claim 7 wherein said capturing step includes the step of (a) capturing an IP address of said customer computer.

9. A process as set forth in Claim 7 wherein said capturing step includes the step of (a) capturing a configuration setting of said customer computer.

10. A process as set forth in Claim 7 and including the step of (a) communicating said profile parameter and said transaction identification string to a third party web site for storage.

11. A process as set forth in Claim 7 and including the step of (a) causing said customer computer to communicate said profile parameter and said transaction identification string to a third party web site for storage.

12. A process as set forth in Claim 7 and including the steps of (a) communicating a self identification routine to said customer computer upon said customer computer accessing said merchant web site;
(b) said customer computer executing said self identification routine;
(c) said self-identification routine querying a configuration setting of said customer computer to derive said profile parameter; and (d) said self-identification routine communicating said profile parameter to a remote location for association with said interaction identification string.

13. A process as set forth in Claim 12 and including the step of:
(a) coding said self-identification routine in such a manner that said profile parameter and said interaction identification string are communicated to a third party web site at which said profile parameter and said interaction identification string are stored.

14. A process as set forth in Claim 12 wherein said querying step includes the steps of:
(a) querying said customer browser for a plurality of configuration settings;
(b) forming an attribute string from said plurality of configuration settings;
and (c) processing said attribute string to form said profile parameter of said customer computer.

15. A process as set forth in Claim 12 wherein said customer computer potentially accesses said merchant web site by way of a proxy, and said communicating step includes the steps of:
(a) communicating said profile parameter and said transaction identification string to said remote web site using a protocol which bypasses said proxy.

16. A process for identifying a customer computer involved in an online transaction through a merchant web site between a customer using a customer browser operating on said customer computer and a merchant who operates said web site, said method comprising the steps of:
(a) coding a script request within a transaction form of said merchant web site;
(b) processing said script request by said customer browser upon accessing said merchant web site to thereby communicate to an archiver web site of a machine data archiving service an electronic request for a machine data collection script;
(c) said archiver web site returning said script to said customer browser along with a unique transaction identification string;
(d) said customer browser processing said script to thereby cause said script to query said customer computer for a profile parameter of said customer computer;
(e) said script causing said customer browser to communicate said profile parameter and said transaction identification string to said archiver web site;
(f) said archiver web site storing said profile parameter and said transaction identification string in a machine data profile;
(g) said script causing said customer browser to write said transaction identification string into said transaction form; and (h) upon said customer adding customer identification information to said transaction form and electronically submitting said transaction form to said merchant web site to thereby comprise a transaction record, said transaction identification string associating said transaction record with said machine data profile.

17. A process as set forth in Claim 16 and including the steps of (a) said script causing said computer browser to communicate said profile parameter and said transaction identification string along with a conventional hypertext transfer protocol (HTTP) header; and (b) said archiver service additionally storing said HTTP header in association with said machine data profile.

18. A process as set forth in Claim 16 and including the step of:
(a) said script querying said customer browser for a configuration setting thereof.

19. A process as set forth in Claim 1f and including the steps of (a) said script querying said customer browser for a plurality of configuration settings;
(b) said script forming an attribute string from said plurality of configuration settings; and (c) said script processing said attribute string to form said profile parameter of said customer computer.

20. A process as set forth in Claim 19 wherein said script processing step includes the step of:
(a) said script performing a hashing function on said attribute string to form said profile parameter.

21. A process as set forth in Claim 16 wherein said customer computer potentially accesses said merchant web site by way of a proxy, and including the step of (a) said script communicating said profile parameter and said transaction identification string to said archiver service web site using a,protocol which bypasses said proxy.

22. A process as set forth in Claim 16 and including the step of (a) said script communicating said profile parameter to said archiver service web site using a protocol other than HTTP.

23. A process as set forth in Claim 16 wherein said customer computer includes a digital clock, and including the steps of:

(a) said script causing said customer browser to query said clock for a time value; aid (b) said script causing said customer browser to send said time value to said archiver service web site along with said profile parameter.

24. A process for identifying a customer computer involved in an online transaction through a merchant web site between a customer using a customer browser operating on said customer computer and a merchant who operates said web site;
said method comprising the steps of:
(a) coding a script request within a transaction form of said merchant web site;
(b) processing said script request by said customer browser upon accessing said merchant web site to thereby communicate to an archiver web site of a machine data archiving service an electronic request for a machine data collection script;
(c) said archiver web site returning said script to said customer browser along with a unique transaction identification string;
(d) said customer browser processing said script to thereby cause said script to:
(1) query said customer browser for a plurality of configuration settings;
(2) form an attribute string from said plurality of configuration settings;

(3) perform a hashing function on said attribute string to form said profile parameter; and (4) query an internal digital clock of said customer computer for a current time value;
(e) said script causing said customer browser to communicate said profile parameter, said time value, and said transaction identification string to said archiver web site along with a conventional HTTP header;
(f) said archiver web site storing said profile parameter, said time value, and said transaction identification string in a machine data profile;
(g) said script causing said customer browser to write said transaction identification string into said transaction form; and (h) upon said customer adding customer identification information to said transaction form and electronically submitting said transaction form to said merchant web site to thereby comprise a transaction record, said transaction identification string associating said transaction record with said machine data profile.

25. A process as set forth in Claim 24 wherein said customer computer potentially accesses said merchant web site by way of a proxy, and including the steps of (a) said script querying said customer computer for a second profile parameter;
and (b) said script communicating said second profile parameter and said transaction identification string to said archiver service web site using a protocol which bypasses said proxy.

26. A process as set forth in Claim 25 and including the step of (a) said script communicating said second profile parameter to said archiver service web site using a protocol other than HTTP.