U.S. patent application number 12/030057 was filed with the patent office on 2008-06-05 for online machine data collection and archiving process.
This patent application is currently assigned to First Data Corporation. Invention is credited to Timothy P. Barber.
Application Number | 20080133420 12/030057 |
Document ID | / |
Family ID | 22780938 |
Filed Date | 2008-06-05 |
United States Patent
Application |
20080133420 |
Kind Code |
A1 |
Barber; Timothy P. |
June 5, 2008 |
ONLINE MACHINE DATA COLLECTION AND ARCHIVING PROCESS
Abstract
An online machine data collection and archiving process
generates a machine data profile of a customer computer accessing a
transaction form of a merchant web site and links the machine data
profile and a transaction record with customer identifying
information using a unique transaction identification string. The
process preferably captures parameters typically communicated as a
part of web accesses, such as an IP address, an HTTP header, and
cookie information. The process additionally causes the customer
computer 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 to reveal the true IP address of the
customer computer.
Inventors: |
Barber; Timothy P.; (Boise,
ID) |
Correspondence
Address: |
SUTHERLAND ASBILL & BRENNAN LLP
999 PEACHTREE STREET, N.E.
ATLANTA
GA
30309
US
|
Assignee: |
First Data Corporation
Greenwood Village
CO
|
Family ID: |
22780938 |
Appl. No.: |
12/030057 |
Filed: |
February 12, 2008 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
09873339 |
Jun 5, 2001 |
7330871 |
|
|
12030057 |
|
|
|
|
60209936 |
Jun 7, 2000 |
|
|
|
Current U.S.
Class: |
705/75 |
Current CPC
Class: |
H04L 67/303 20130101;
G06Q 20/382 20130101; G06Q 20/401 20130101; G06Q 30/0601 20130101;
G06Q 20/12 20130101; G06Q 10/00 20130101; G06Q 20/40 20130101; G06Q
30/0609 20130101; G06Q 20/0855 20130101; G06Q 20/3674 20130101;
G06Q 30/0255 20130101; G06Q 30/02 20130101; G06Q 20/385 20130101;
G06Q 30/0269 20130101; G06Q 20/10 20130101; G06Q 40/12 20131203;
G06Q 30/0251 20130101 |
Class at
Publication: |
705/75 |
International
Class: |
H04L 9/00 20060101
H04L009/00 |
Claims
1. A process for collecting machine identifying information
associated with a digital online access device used for 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: capturing a
machine fingerprint that identifies said access device accessing
said host computer system wherein said machine fingerprint
comprises a hashed attribute string that is a concatenation of
attributes associated with said access device; generating an
interaction identification string upon said access device accessing
said host computer system; associating said interaction
identification string with said machine fingerprint; and
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 further comprising capturing a
digital address of said access device on said digital network.
3. A process as set forth in claim 1 wherein said hashed attribute
string comprises a configuration setting of said access device.
4. A process as set forth in claim 1 further comprising:
communicating a self-identification routine to said access device
upon said access device accessing said host computer system; said
access device executing said self-identification routine; said
self-identification routine querying a configuration setting of
said access device to derive said machine fingerprint; and said
self-identification routine communicating said machine fingerprint
to a remote location for association with said interaction
identification string.
5. A process as set forth in claim 1 further comprising: 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 coding, within said
interaction code, a self-identification routine which causes said
access device to communicate said machine fingerprint when said
access device processes said interaction page code.
6. A process as set forth in claim 3 further comprising coding said
self-identification routine in such a manner that said machine
fingerprint and said interaction identification string are
communicated to a third party web site at which said machine
fingerprint 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: capturing a
machine fingerprint of a customer computer upon said customer
computer accessing said merchant web site wherein said machine
fingerprint comprises a hashed attribute string associated with one
or more attributes of said customer computer; generating a
transaction identification string and associating said string with
said machine fingerprint; storing said machine fingerprint and said
transaction identification string in a machine data archive; 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 machine fingerprint with said transaction record
through said transaction identification string.
8. A process as set forth in claim 7 further comprising capturing
an IP address of said customer computer.
9. A process as set forth in claim 7 wherein said machine
fingerprint comprises a configuration setting of said customer
computer.
10. A process as set forth in claim 7 comprising communicating said
machine fingerprint and said transaction identification string to a
third party web site for storage.
11. A process as set forth in claim 7 further comprising causing
said customer computer to communicate said machine fingerprint and
said transaction identification string to a third party web site
for storage.
12. A process as set forth in claim 7 further comprising:
communicating a self-identification routine to said customer
computer upon said customer computer accessing said merchant web
site; said customer computer executing said self-identification
routine; said self-identification routine querying a configuration
setting of said customer computer to derive said machine
fingerprint; and said self-identification routine communicating
said machine fingerprint to a remote location for association with
said interaction identification string.
13. A process as set forth in claim 12 further comprising coding
said self-identification routine in such a manner that said machine
fingerprint 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
further comprises: querying said customer browser for a plurality
of configuration settings; forming an attribute string from said
plurality of configuration settings; and hashing said attribute
string to form said machine fingerprint of said customer
computer.
15. A process as set forth in claim 12 wherein said customer
computer accesses said merchant web site by way of a proxy, and
said communicating step further comprises communicating said
machine fingerprint and said transaction identification string to
said remote location using a protocol which bypasses said proxy.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims the benefit of priority under 35
U.S.C. .sctn. 119(e) to U.S. Provisional Patent Application No.
60/209,936 filed Jun. 7, 2000 and is a continuation of U.S. patent
application Ser. No. 09/873,339, filed on Jun. 5, 2001, the
entireties of which are hereby incorporated herein by
reference.
BACKGROUND OF THE INVENTION
Field of the Invention
[0002] The present invention relates to identity detection
techniques and, more particularly, to a process for collecting and
utilizing machine-identifying data of computers and other online
appliances used in online interactions and transactions and
associating the collected machine data with such online
interactions.
[0003] The internet, or global computer network, represents a new
medium for marketing 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 persons to take
advantage of the mechanisms of Internet transactions by fraudulent
and deceptive practices. Merchants and financial institutions bear
the initial costs of fraud. However, consumers ultimately pay the
costs in the form of prices and credit rates which must take into
account losses from fraud. Internet purchases typically involve the
use of web page forms which are filled in by the customer with
identity, address, purchase, shipping, and payment information and
submitted to the online merchant for processing. Internet purchases
are most often paid for by way of credit cards. While a merchant's
software may be able to verify the existence and status of a credit
card account number and an 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 otherwise, a merchant generally assumes that anyone
using a credit card is authorized to do so and that a customer is
who he identifies himself to be.
[0004] An important step in combating fraud is accurate
identification of the computers through which customers make
transactions and associating such identities with transactions
which arouse suspicions or which ultimately turn out to be
fraudulent. Basic machine identity is essential to the manner in
which the internet operates. We speak in terms of "going" to a web
site. In reality, "going" to a web site involves sending a request
for a web page file in a directory or folder on a computer located
at a specific internet 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 "directions" in the form of the basic identity of the
requesting computer, including its IP address. Some web sites are
implemented with software which enables responses to web page
requests to be tailored to specifics of the requesting machine's
configuration, specific web browser, and the like. For this reason,
current versions of browsers usually communicate configuration
information in addition to a return IP address and return path.
[0005] The IP address of a page requesting computer can give an
indication of the specific country where the computer is located.
Further, identification of a page-requesting computer can also
recognize a returning user using the same computer as during a
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 access.
[0006] Because direct interaction with a customers computer is
essential in detecting fraud, it has been assumed that any viable
fraud detection software must be integrated with 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 processing software. An additional
problem with focusing fraud detection at single merchants is that
perpetrators of fraud often hit many merchants in an attempt to
avoid or delay detection. Thus, an ideal system for fraud detection
in online marketing would only 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.
SUMMARY OF THE INVENTION
[0007] The present invention provides a process for collecting data
associated with a customer's computer during access of a merchant,
financial, other host web site, and associating a transaction
identification number with the data and with a transaction form of
the merchant. Generally, the present invention captures machine
identifying data from a computer or other digital appliance
accessing a host web site, sends the captured data to a machine
data archive along with a unique transaction identification string
for storage in the archive and writes the same transaction
identification string into a transaction form 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 of the transaction identification
string and can be used on-the-fly or at a later time for a variety
of purposes including, but not limited to, fraud detection.
Although the term "archive" is used, the machine data collected
need not be stored permanently.
[0008] 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 orders; online banking,
bill payment, and funds transfers; online registrations, such as
for memberships, product warranties, applications for credit,
renewal of subscriptions and licenses; online technical support;
and the like. The term "transaction" is used in the 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 commercial interactions involving
purchases. The term "transaction" is intended to apply to an
interaction of a remote digital appliance with a host system using
a relatively anonymous type of access process over a digital medium
in which some form of self-identification of the accessing
appliance is inherent in the access process and in which the true
identity of the accessing party, the true source address of the
appliance on the medium, and/or the true machine characteristics of
the accessing appliance is/are essential or desirable to the
interaction.
[0009] The host entity which operates the host system accessed is
intended to encompass 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 limit the present invention to commercial
transactions. The medium of access is intended to be interpreted as
including a global computer network such as the internet or world
wide web, as well as other types of networks which may be less than
global but which are 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
computer" or "machine" are used herein to refer to a device for
effecting remote access to a host system over a digital medium and
are meant to encompass not only conventional types of personal
computers, but also additional types of "digital appliances" with
online access capabilities, such as: cell phones, personal digital
assistant devices, electronic game systems, television sets with
online access capabilities, web appliances for vehicles, and any
other type of device with online access capabilities whether
connected to a wired communications network directly or by a
radiant technology.
[0010] The machine data collection process of the present invention
contemplates a two party process embodiment in which a "merchant"
processes and/or stores machine data profiles of customer computers
in-house, as well as a three party process embodiment in which
machine data profiles of customer computers are processed and/or
stored for the merchant by a third-party machine data collection
and archive service.
[0011] In a two party embodiment of the data collection process of
the present invention, 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 with a machine data profile of the customer machine
data profile. In the two party process, the merchant system
captures customer computer data which is inherently passed from the
customer computer to the merchant's web site, such as an IP address
of the 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 which, when processed
by the customer computer, cause the customer computer to further
identify itself by collecting and returning certain machine and
software configuration characteristics, which can be used to
identify the particular customer computer. The two party process
may include the generation and setting of an HTTP cookie in the
customer browser for recognition upon a later access with the
merchant web site.
[0012] Although the two-party embodiment of the machine data
collection process of the present invention has utility for some
applications, the three party embodiment is preferred for
applications in which analysis of a maximum number of customer
computer profiles is desirable, such as certain types of marketing
processes and fraud detection and control processes. In a three
embodiment of the present invention, the customer machine data of
computers accessing the second party or merchant web site is
communicated to and stored within a third party system, referred to
herein as a machine data archive service. In the three party
process, the transaction ID could be generated by the merchant
system, but is 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 party
system. Permanent storage of such profiles may not be practical, as
far as yielding beneficial results to the purposes for which the
profiles are collected. Thus, the term "archive" is meant to
indicate a central storage facility, such as a database, with a
selected retention period, with purging of most profiles after a
certain length of time.
[0013] In the three party process a routine or line of code is
added into the hypertext markup language (HTML) code which defines
the merchant's web page, particularly an order or transaction form
page. The added routine issues a request for a machine data
collection (MDC) script to the third-party web site when the form
page code is processed 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 identification
(TA/ID) and checks for its own cookie. If no MDAS cookie is
present, the archive service sends a cookie to the requesting
computer along with a machine data collection (MDC) script having
the transaction ID embedded therein. The MDC script is executed by
the customer's browser, causing collection of certain data from the
customer's computer which is sent back to the archive service along
with the transaction ID and stored in a machine data profile in the
machine data archive. The transaction ID is written into the
transaction form, and when the transaction form is submitted to the
merchant web site, the transaction ID string becomes a part of the
transaction data record, along with customer identification,
location, and financial information.
[0014] The machine data initially collected and stored in each
profile preferably includes the transaction ID, the apparent IP
address of the customers computer, a conventional HTTP header which
identifies the customers browser versions and certain configuration
aspects of the browser, and the archive service's cookie. The
combination of such information, minus the transaction ID, will be
relatively rare but may not be unique. 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 preferred embodiment of the present invention, the
MDC script performs additional machine profiling operations:
generation of a machine "fingerprint" and a proxy "piercing"
operation.
[0015] 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 queried by the
script. The MDC script then performs a conversion process on the
attribute string to generate a fingerprint string having content
which is a function of the original content of the attribute
string. The conversion process is preferably a "hashing" function
which is, in effect, an irreversible encryption algorithm. The
generation of a conventional checksum is one example of a type of
hashing function. For example, if the attribute string is formed by
alphanumeric characters, the conversion process is performed on the
string of codes representing the characters. The particular
conversion process or hashing function used may be one of many
types of conventional conversion algorithms or hashing functions,
which are typically used for data integrity tests. The resulting
string 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 value, queried from
the customer computer time-of-day clock, is returned with the
fingerprint string and stored in conjunction therewith.
[0016] An HTTP proxy is one of several types of proxies through
which a browser may 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 remote
secondary gateway, or proxy, with an IP address different from the
primary gateway IP address. Such redirection hides the true IP
address of a computer. The proxy piercing operation of the MDC
script queries the customer computer for any LAN (local 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, and the transaction ID to the
archive service using a protocol which will not be redirected
through the HTTP proxy, for example a lower level protocol such as
TCP/IP or UDP protocols. If the attempt is successful, the message
containing the time value, the transaction ID, and LAN address
arrive at the archive service web site with the true return IP
address of the customer computer, whether an HTTP proxy intervenes
or not. The LAN address and IP address so derived are stored in the
machine profile. It should be noted that the use of an HTTP proxy
is not, of itself, an indication of fraud. However, the acquisition
of an additional IP address is one more parameter with which to
identify a particular computer.
[0017] When, and if, the customer submits the transaction form to
the merchant, the transaction ID string is communicated to the
merchant, along with other customer information such as name,
address, credit card number and the like plus transaction
information. The complete transaction record is stored on the
merchant's system and is associated with a specific machine
identity profile within the archive service by way of the
transaction ID string. Thereafter, the stored machine identity
profiles and transaction records of large numbers of transactions
can be analyzed by various fraud detection techniques to detect
patterns of fraud and fraud attempts and, preferably, identify and
locate the sources of such activity.
[0018] The machine data profiles stored in the archive service need
not be combined with the customer identification information for
non-suspicious transactions, to thereby preserve the privacy of
non-suspicious customers within the machine data archive. However,
the processes of the present invention do not require that the
customer identification information be kept separated from any
associated machine data profiles, and there may be reasons to
combine the associated records.
BRIEF DESCRIPTION OF THE DRAWINGS
[0019] FIG. 1 is a simplified block diagram illustrating a
plurality of customer and merchant computers interfaced to the
internet along with a machine data archiving service computer for
practicing the machine data collection process of the present
invention.
[0020] FIG. 2 is a simplified block diagram illustrating connection
of a customer computer to the internet, with optional components
shown in phantom lines.
[0021] FIG. 3 is a flow diagram illustrating principal steps of the
machine data collection and archiving process according to the
present invention.
[0022] FIG. 4 is a flow diagram illustrating more detailed steps of
the machine data collection and archiving process according to the
present invention.
[0023] FIG. 5 is a flow diagram illustrating a still further
detailed steps in the machine data collection and archiving process
of the present invention.
[0024] Various objects and advantages of this invention will become
apparent from the following description taken in relation to the
accompanying drawings wherein are set forth, by way of illustration
and example, certain embodiments of this invention.
[0025] The drawings constitute a part of this specification,
include exemplary embodiments of the present invention, and
illustrate various objects and features thereof.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
[0026] As required, detailed embodiments of the present invention
are disclosed herein; however, it is to be understood that the
disclosed embodiments are merely exemplary of 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 basis for the claims and as a
representative basis for teaching one skilled in the art to
variously employ the present invention in virtually any
appropriately detailed structure.
[0027] Referring to the drawings in more detail:
[0028] The reference numeral 1 (FIG. 3) generally designates a
process for online collection of machine identifying or profiling
data of computers involved in commercial transactions and for
archiving such data to facilitate analysis for fraud detection
purposes. The process collects machine identifying or profiling
data of computers involved in commercial transactions and archives
such data in a third-party machine data archive service in
association with a transaction identification string or ID which is
also written into a transaction form of a merchant with whom the
customer is conducting a transaction.
[0029] FIG. 1 illustrates a plurality of host entities or merchants
with corresponding merchant computers 2, on which are operated
merchant web sites 3 which are accessible over a global computer
network, such as the internet 4, by a plurality of customer
computers 5. The merchant computers 2 execute various programs
which enable the sale of products or services by way of the
internet 4. The merchant web sites 3 typically make use of form
type web pages with which the customers 5 interact by filling in
various data fields, for example, name, address, shipping address,
telephone number, credit card type and number and expiration date,
and description and quantities of products to be ordered.
[0030] 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 the like. When a
customer 5 accesses a merchant's transaction form, a transaction
form file is communicated to the customer's computer with various
data fields displayed as fill-in boxes or the like. The customer
fills in the appropriate fields and selects a submit "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 stored in a merchant transaction database 7
for retrieval and processing in due course to cause the ordered
items to be gathered, packaged and prepared for shipment, along
with financial processing to debit the customer's credit account.
The financial processing may 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 executed based on the items withdrawn from stock for
shipment.
[0031] In a three party embodiment of the present invention, the
process 1 makes use of an entity referred to herein as a machine
data archiving service, MDAS or archive service, which operates an
archive service computer system 15, including an archive service
web site 16. The archive service system 15 maintains a machine data
archive service database or archive 17 in which the machine data
collection profiles 18 from customer computers 5 of the merchants 2
are stored. The archive service web site 16 is interfaced to the
internet 4. The archive service 15 is preferably independent of the
merchants and may be operated by a merchants' association, a
financial institution or association thereof, or may be an
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 archiving service 15,
for fraud detection or possibly for marketing purposes.
[0032] Referring to FIG. 2, a customer computer system 5 includes a
customer computer 20 interfaced to the internet 4 by way of a
primary gateway 22, as of an internet service 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 computers on the network. The computer 20 may
communicate through the internet 4 by way of a HTTP (hypertext
transfer protocol) proxy 26, which disguises the internet protocol
(IP) address of the actual gateway 22. The computer 20 accesses web
sites on 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 of web pages
and interact therewith. The browser 28 is normally enabled to
accept "cookies" 30 which are stored in a cookie file. Cookies 30
are data strings which are issued by web sites and give an
indication of a previous visit to a particular web site and may
indicate a particular configuration or set of preferences of the
customers setup of the computer 20. Typically, the customer
computer 20 has a time of day clock/calendar 32.
[0033] The customer computer 20 may have a fixed IP address,
depending on the manner in which it is interfaced to the internet.
More commonly, the customer computer 20 will have a temporary or
dynamically assigned IP address which is determined by the primary
router 22. The primary router 22 has an IP address, as do a router
of a LAN 24 or an HTTP proxy 26 if either is present in the
customers computer system 5.
[0034] FIG. 3 illustrates the principal actions or steps of a
general or basic process 34 of the process 1 for collecting machine
identifying data from customer computers 5. At step 35, at least
one machine identifying profile parameter is captured upon access
of a customer computer 5 or other online access device with a host
or merchant web site 3. A unique transaction identifier or TA/ID is
generated at 36 and associated at 37 with the captured profile
parameter. The transaction ID is also associated at step 38 with a
transaction record generated as a result of the interaction or
transaction conducted between the customer computer 5 and a
merchant web site 3. Although not specifically 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 computer 5 accessing the merchant computer 3.
Alternatively, the process 34 may pass routines to the customer
computer 5 to cause it to "self-identify" itself by querying
certain configuration parameters and passing such information to a
machine profile stored either within the merchant's system 2 or in
a third party archive 17. The process 34, thus, encompasses a
two-party embodiment or a three party embodiment of the machine
data collection and archiving process 1 of the present
invention.
[0035] Referring particularly to FIG. 4, a more particular three
party embodiment of the machine data collection and archiving
process 1 begins at step 40 with the coding of a machine data
collection (MDC) script request into the web page code for a
transaction form of a merchant web site 3. When a customer 5
accesses the merchant transaction form at step 42, the customer
browser 28 processes the transaction page code, including the MDC
script request, which causes the MDC script request to be
communicated to the archive service web site 16 at step 44. The
script request arrives at the archive service 15 with a set of
customer machine parameters which principally provide a return path
for the MDC script from the archive service 15 to the customer 5.
The customer machine parameter set preferably includes "user agent"
information, which is the version of the customer browser 28.
[0036] At step 46, the archive service 15 generates a unique
transaction ID string and associates it with the customer machine
parameter set in the MDAS archive 17. At step 48, the archive
service returns the MDC script, with the transaction ID embedded
within it, to the customer browser 28. At step 50, the customer
browser 28 processes the MDC script which, at a minimum, writes the
transaction ID string into the merchant's transaction form.
Assuming that the customer 5 completes the transaction and submits
the transaction form to the merchant 2 at step 52, the transaction
ID string is stored with the transaction data record 6 in the
merchant transaction database 7. The transaction ID, thus,
indirectly associates the machine data parameter set 18 stored in
the MDAS archive 17 at step 54 with the customer identity
information stored with the transaction data record 6 in the
merchant's transaction database 7. Thereafter, qualified parties
may access the MDAS archive 17 for information related to a
transaction ID.
[0037] The MDAS archive 17 need not contain any information which
specifically identifies a particular customer, only the machine
parameter profiles 18 with associated transaction ID strings. The
MDAS archive records 18 can be analyzed in conjunction with the
merchant transaction records for patterns of fraud or for other
purposes. The great majority of MDAS archive records can be purged
from the archive 17 after a selected period of time. Any records
which are associated with any transaction irregularities or
suspicions of actual fraud may be retained longer.
[0038] FIG. 5 illustrates the principal steps of a preferred
embodiment 60 of the machine data collection and archiving process
1 of the present invention. The process 60 begins with the addition
at 62 of a machine data collection (MC) script to the transaction
(TA) form page code of a merchant web site 3. The transaction form
page code is processed at 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
the browser 28 accesses the MDAS web site 16, requesting the MDC
script, the MDAS web site checks for the presence of an MDAS cookie
at step 68. If no MDAS cookie is detected, an MDAS cookie is
generated at 70 and a unique transaction identification (TA/ID)
string is generated at 72. The MDC script, transaction ID, and
cookie, if not previously set, are returned at 74 to the customer
browser 28, the transaction ID being embedded within the MDC
script.
[0039] When the MDC script is received by the browser 28, it is
executed at 76. The cookie is stored in the cookie file 30, or
possibly in the memory of the customer computer 20. Execution of a
preferred MDC script causes several actions to be performed. The
MDC script writes the transaction ID 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 ID string or by
writing an appropriate variable into the transaction form page and
setting its value to the transaction ID string. Additionally, the
preferred MDC script generates a "fingerprint" of the customer
computer 20 at step 80 and attempts to perform a proxy piercing
operation at step 82.
[0040] In generating the machine fingerprint at 80, the MDC script
queries the browser 28 for a number of attributes and settings and
concatenates the results into an attribute string at 84. The MDC
script then performs a hashing algorithm on the attribute string at
80 to generate a fingerprint string which has a high degree of
uniqueness. Hashing functions are 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 used for data integrity checking. As previously
stated, a common checksum is the result of a type of hashing
function. The particular hashing function employed preferably
maximizes the uniqueness of the resulting fingerprint.
[0041] At step 86, the customer computer clock 32 is queried for a
current time value. At step 88, the fingerprint, the transaction
ID, and the time value are communicated to the MDAS web site 16
along with an HTTP header with cookie and "apparent" IP address,
all of which are stored as a machine data profile 18 within the
MDAS archive 17.
[0042] At step 90, the MDC script adds a proxy piercer request to
the transaction form 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 by the
browser 28 at 94, a time value from the clock 32 is again queried
at 96 and any existing local area network (LAN) address is queried
at 98. At step 100, the proxy piercer applet/code sends the time
value, the LAN address (if any), and the transaction ID to the 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 protocol) or, preferably, TCP/IP
(transmission control protocol/internet protocol).
[0043] Bypassing the HTTP proxy 26 causes the data sent in step 100
to arrive at the MDAS web site 16 with the IP address of the
primary gateway 22, which may be different from any apparent IP
address previously recorded if an HTTP proxy 26 intervenes. If the
proxy piercer procedure 82 is successful, the primary gateway IP
address is stored at step 102 within the machine data profile 18
identified by the transaction ID. It should be noted that some
types of proxies, such as some types of firewalls, may block all
non-HTTP protocol packets, so that the proxy piercer procedure 82
might not be successful in all cases.
[0044] If the customer completes the transaction with the merchant
web site 3, the transaction form is submitted at step 104, which
causes the transaction record 6, including the transaction IID, to
be stored at step 106 in the merchant database 7 for
processing.
[0045] 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 (uniform resource locator)
example-url.net and a specific merchant has a merchant identifier
MMM, a line of HTML code is added at step 40 to the transaction
form of merchant MMM between the <form> and </form>
HTML tags which has the form:
[0046] <script
src=https://www.example-url.net/s/?MMM></script>-;
[0047] When the customer browser 28 processes the transaction form
at step 42, it requests a script file from the source URL:
https://www.example-url.net/s/?MMM.
[0048] At step 44, the customer web browser 28 requests the MDC
script by way of the HTTP protocol. The HTTP request includes the
merchant ID the user agent (browser version), the IP address of the
customer's HTTP proxy, and any HTTP cookies previously sent to the
customer by www.example-url.net. Upon receiving this information,
the archive service 16 records this information in a machine data
record which also includes the transaction ID.
[0049] Upon receiving the file request, the archive service 16
generates a unique transaction ID (represented below as ZZZ) at
step 46 to be associated with the transaction and the machine
parameter set. An exemplary transaction ID is a string of 24
letters and digits. The first eight digits form a time stamp which
is a hexadecimal representation of the seconds elapsed since
midnight Jan. 1, 1970 UTC (coordinated universal time).
[0050] 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 version of the MDC script is as
follows (linebreaks and indentations added for clarity):
TABLE-US-00001 document.write("<input name=transactionid
type=hidden value=ZZZ>; d=new Date( ); t=3600*d.getHours(
)+60*d.getMi- nutes( )+d.getSeconds( ); document.write("<img
height=1 width=1
src=https://www.example-url.net/t/?i=ZZZ&t="+t+">");
document.write("<applet height=1 width=1
codebase=https://www.example-url.net/ code=a/?ZZZ> <param
name=i value=ZZZ></applet>");
[0051] The exemplary MDC script includes the unique transaction ID
value in several places. When the script executes on the customer
computer 20, it writes HTML code into the merchant's order form.
Specifically:
[0052] 1) The script adds a hidden variable called "transaction" ID
to the merchant's transaction form and assigns it the value of the
transaction ID (ZZZ). When the transaction form is submitted, the
merchant receives the transaction ID and can associate it with the
transaction data record.
[0053] 2) The script computes the seconds elapsed since midnight on
the clock 32 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 archive
service 16 and recorded with the transaction ID in the MDAS archive
17.
[0054] 3) The script adds a request for a program located at the
archive service web site 16 which, in this example, is a Java
applet. The applet downloads to the customer 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 parameter specified in the script. The program
performs three tasks:
[0055] a) it calculates TTT, the seconds elapsed since midnight on
the system clock 32;
[0056] b) it calculates AAA, the address of the customer 20 on its
own local area network 24; and
[0057] c) it sends this data back to the archive service 16 via
TCP/IP, by requesting the following URL:
[0058] http://www.example-url.net/d/?i=ZZZ&t=TTT&a=AAA
[0059] 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 the customer's actual IP
address, which in some cases is different from the HTTP proxy IP
address. The archive service 16 records this information in the
MDAS archive 17 and associates it with the transaction ID ZZZ.
[0060] 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 that the techniques of
the present invention have a wider application, as for marketing or
computer support purposes, or other functions. While the process 1
has been described with reference to the internet 4 or world wide
web, it is also conceivable that the process 1 could be employed on
computer networks of less than global expanse, such as a large
intranet, a national or regional network, or the like.
[0061] Therefore, it is to be understood that while certain forms
of the present invention have been illustrated and described
herein, the present invention is not intended to be limited to the
specific forms, arrangement of parts, sequence of steps, or
particular applications described and shown.
* * * * *
References