WO 2008/052310
`
`PCT/CA2007/001767
`
`4
`
`PCT Patent Application No. WO 2006/083063 to Park, for a system and method for mediating and
`
`conducting peer-to-peer electronic commerce, discloses a method of allowing people who don't
`
`have a commercial website to have their product details spidered and sold on a regular website.
`
`U.S. Patent Publication No. 2006/0068785 to Kamijo et al., for a secure communication over a
`
`5 medium, discloses a process to assist in securing insecure communications using a cell phone.
`
`U.S. Patent Publication No. 2005/0209876 to Linlor, for a secure money transfer between hand-held
`
`devices, discloses a method of storing a clients billing information in a database and then making a
`
`purchase from their computer using a Personal Identification Number (PIN) or biometrics to
`
`identify themselves.
`
`10
`
`BRIEF SUMMARY OF THE INVENTION
`
`What is needed is a system that is pre-emptive and uses technology already available on every
`
`computer that accesses the Internet; so that additional software may not be required on the client
`
`computer operated by the account user. The system according to the invention preferably uses a
`
`database
`
`independent of the client computer, and works
`
`in conjunction with traditional
`
`15
`
`authentication systems, or optionally without traditional authentication at all (such as with standard
`
`online credit card transactions).
`
`The system according to the invention includes a method to determine the MAC address of a
`
`computer and other identifying details from outside the local area network (e.g., via the Internet)
`
`using common online scripting languages.
`
`20 Authentication is not required for the system according to the invention to function; instead the
`
`system assists in securing existing authentication systems and online credit card transactions. The
`
`system is also comprehensive and complete, actually offering an automated security solution when
`
`suspicious transactions are made.
`
`In addition to specifying the computer used in any online
`
`transaction using the MAC address of the computer, the system according to the invention may also
`
`25
`
`show the IP address of the connecting computers between the client computer and the receiving
`
`server. This allows administrators to determine if the alleged account user is using spoofing
`
`Page 409 of 860
`
`GOOGLE EXHIBIT 1002
`
`

`

`WO 2008/052310
`
`PCT/CA2007/001767
`
`5
`
`technology to try and hide their identity. The system according to the invention may be used for
`
`law enforcement, by discreetly capturing significant data from online criminals and terrorists.
`
`For an additional level of security, more stringent computer identification may be implemented and
`
`biometrics may be integrated with the system according to the invention to gain access to highly
`
`5
`
`sensitive online accounts for government and law enforcement.
`
`The security system according to the invention 1s a companion for existing authentication and
`
`processing systems. The system may provide for:
`
`1. a reduction in hacking, fraudulent charges, and staff needed to administer a current security
`
`system;
`
`10
`
`2. an improvement in client/merchant satisfaction, and the ability to use the effectiveness of the
`
`system as selling point;
`
`3. revenue potential (for payment processors and publishers) for the enhanced security services;
`
`4. creation of highly secure authentication systems for federal or law enforcement applications
`
`accessible via the Internet;
`
`15
`
`5.
`
`elimination of the threat of fraudsters or hackers using IP spoofing to hide their identities and
`
`commit fraud; and
`
`6. Provision of a system useful for espionage and for law enforcement to collect data from online
`
`criminals or terrorists.
`
`A system for enhancing security between a client and a server is provided, including: a database,
`
`20
`
`accessible by the server, the database having a record associated with an account, the account
`
`associated with a MAC address; wherein when the client accesses the account, the server receives
`
`the MAC address associated with the client and compares the MAC address associated with the
`
`client to the MAC address associated with the account, and if the MAC address associated with the
`
`client is the same as the MAC address associated with the account, permits access to the account.
`
`Page 410 of 860
`
`

`

`WO 2008/052310
`
`6
`
`PCT/CA2007/001767
`
`If the MAC address associated with the client is not the same as the MAC address associated with
`
`the client, the server communicates with said client to determine if access to the account should be
`
`permitted.
`
`The account may associated with a geographic area, and the server receives an IP address associated
`
`5 with the client, and if the geographic area associated with the IP address is not the same as the
`
`geographic area associated with the account or the MAC address of the client is not the same as the
`
`MAC address associated with the account, the server denies access to the account.
`
`If the
`
`geographic area associated with the IP address is not the same as the geographic area associated
`
`with the account and the MAC address of the client is not the same as the MAC address associated
`
`10 with the account, the server may notify law enforcement of the IP address and MAC address of the
`
`client.
`
`The account may be associated with biometric information related to a user, and the server receives
`
`the biometric information from the client.
`
`DESCRIPTION OF THE FIGURES
`
`15
`
`Exemplary embodiments are illustrated in referenced figures of the drawings. It is intended that the
`
`embodiments and figures disclosed herein are to be considered illustrative rather than restrictive.
`
`Figure 1 is a block diagram of a system according to the invention;
`
`Figure 2 is a flow chart showing the process by which an account is opened according to the
`
`invention;
`
`20
`
`Figure 3 is a flow chart showing the process by which an account is accessed according to the
`
`invention;
`
`Figure 4 is a block diagram showing the interaction between an ActiveX Control Container and a
`
`Windowed ActiveX Control;
`
`Figure 5 is a block diagram showing communication between an ActiveX Control Container and an
`
`25
`
`ActiveX Control; and
`
`Page 411 of 860
`
`

`

`WO 2008/052310
`
`7
`
`PCT/CA2007/001767
`
`Figure 6 is a block diagram showing a Java security architecture.
`
`DETAILED DESCRIPTION OF THE INVENTION
`
`Throughout the following description specific details are set forth in order to provide a more
`
`thorough understanding to persons skilled in the art. However, well known elements may not have
`
`5
`
`been shown or described in detail to avoid unnecessarily obscuring the disclosure. Accordingly, the
`
`description and drawings are to be regarded as being illustrative and not restrictive.
`
`The system, according to the invention, restricts access to an account ( or a credit card) based on the
`
`MAC address of the network card 30 in client computer 20 used by the account user 10. Each
`
`network card 30 is identifiable by a unique MAC address.
`
`10 A typical system incorporating the invention is shown in Figure 1. Account user 10, accesses the
`
`Internet 50 via client computer 20 to communicate with a server 70 operated by account provider
`
`80.
`
`Server 70 may be a single computer, software running on a computer, or a plurality of
`
`computers. Server 70 communicates with database 90 which may be within server 70 or one or
`
`more computers in communication with server 70. Account provider 80 also has access to database
`
`15
`
`90. Client computer 20 includes a network card 30 for communications, network card 30 having a
`
`MAC address.
`
`To use the secure account, the MAC address of the client computer must be registered with the
`
`server permitting access to the account. If client computer 20 tries to access an account or use a
`
`credit card via an unregistered computer (and therefore unregistered MAC address), then the
`
`20
`
`registered account user 10 may be notified by e-mail and/or by phone, and the account, transaction
`
`or credit card can be suspended due to the suspicious action until the account user 10 verifies the
`
`transaction. If account user 10 was just using a different, unregistered computer, account user 10
`
`can respond to the notification and the account can be re-activated without intervention from a
`
`"live" person.
`
`25
`
`The MAC address of a particular computer is positioned one level below an IP address, and within a
`
`local network it can be determined by sending an "arp -a" request. MAC addresses of computers
`
`accessing the Internet are determined and used by ISPs routinely to restrict or allow access to the
`
`Page 412 of 860
`
`

`

`WO 2008/052310
`
`PCT/CA2007/001767
`
`8
`
`Internet by sending a Dynamic Host Configuration Protocol (DHCP) request or an Address
`
`Resolution Protocol (ARP) request to the client computer. These requests involve sending a
`
`message to the client computer 20 with the request, which in turn responds with the MAC address.
`
`Communications sent through the Internet only retain the MAC address of the last IP/Hop in the
`
`5
`
`transmitted packet, meaning that the MAC address of the original client computer 20 is not usually
`
`preserved as the packet goes from router to router throughout the Internet. However, there are
`
`several ways of determining the MAC address of client computer 20, including the following:
`
`1. Capturing the MAC address from the first router or hop receiving the packet from client
`
`computer 20. Such a method requires a series of queries of previous routers and requires
`
`10
`
`cooperation from the ISPs involved.
`
`2. "Spoofing" a DHCP packet or ARP request with the connecting computer (as sent from the local
`
`subnet) and storing the resulting MAC address in a text file to be sent back to the requesting server
`
`70.
`
`3. Using a script that reports the MAC address and may also report the IP address and/or host name
`
`15
`
`of client computer 20 for a message received from a connecting computer. For the purposes of law
`
`enforcement, additional details could be determined for investigation of criminals or terrorists. A
`
`secure script, digitally signed by a well-known and secure source, will allow users to run the script
`
`without security warnings. Such a script can be created using commonly used Internet scripting
`
`languages, or the script can be included as an application add-on or plug-in for computer programs
`
`20
`
`or websites that use authentication; or the script may be a small stand alone application distributed
`
`by credit card issuers or payment processors.
`
`In a preferred embodiment of the invention, more than one of these means for obtaining a MAC
`
`address may be used.
`
`Microsoft™ or Java™ software may be used to implement the system in order to provide scripts
`
`25 with compatibility with most systems. The system is designed for maximum compatibility and
`
`discreet operation.
`
`In a preferred embodiment, code implementing the method according to the
`
`Page 413 of 860
`
`

`

`WO 2008/052310
`
`PCT/CA2007/001767
`
`9
`
`invention is downloaded from a web server and then executed on client computer 20 and account
`
`provider server
`
`Embodiment using ActiveX™ Controls
`
`The system and method according to the invention may be implemented using ActiveX controls,
`
`5 which are software components based on the Component Object Model (COM™) environment
`
`provided by Microsoft™. Like Java applets, ActiveX controls 100 can be used to add rich content
`
`to web pages. Unlike applets, ActiveX controls 100 are limited to use in Microsoft's Internet
`
`Explorer™ web browser.
`
`In the context of this document, the term "ActiveX" is used to refer to the technology that
`
`10
`
`downloads and runs controls in one of the formats supported by the "Authenticode" code signing
`
`system, and corresponds to controls that can be declared from a web page using an OBJECT tag.
`
`Such controls include: COM controls (filetypes .DLL and .OCX); Win32 executable files (filetype
`
`.EXE); INF set-up files, used to specify locations and versions for a collection of other files
`
`(filetype .INF); and "cabinet" files that are referred to by an OBJECT tag (filetype .CAB). These
`
`15
`
`controls are all treated in a very similar way by web-enabled ActiveX container 120 applications,
`
`including in the use of the same caching and versioning mechanisms.
`
`ActiveX controls 100 are highly portable COM objects, and are used extensively throughout
`
`Microsoft Windows platforms and, especially, in web-based applications. COM objects, including
`
`ActiveX controls 100, can invoke each other locally and remotely through interfaces defined by the
`
`20 COM architecture. The COM architecture allows for interoperability among binary software
`
`components produced in disparate ways.
`
`If an ActiveX control 100 is not installed locally, it is possible to specify a URL where the control
`
`can be obtained by account user 10. Once obtained, the control 100 installs itself on client
`
`computer 20 automatically if permitted by the browser. Once it is installed, it can be invoked
`
`25 without the need to be downloaded again.
`
`ActiveX controls 100 can be signed or unsigned. A signed control provides a high degree of
`
`verification that the control was produced by the signer and has not been modified. As ActiveX
`
`Page 414 of 860
`
`

`

`WO 2008/052310
`
`PCT/CA2007/001767
`
`10
`
`controls 100 do not run in a limited environment or "sandbox", it is important to have a high degree
`
`of trust in the author of the control.
`
`The system and method according to the invention may be implemented using an ActiveX control
`
`100, herein referred to as an "secureIDx control".
`
`The secureIDx control uses several
`
`5
`
`programmatic elements to interact efficiently with a control container and with account user 10.
`
`These programming elements may be: class ColeControl 130; a set of event-firing functions; and a
`
`dispatch map.
`
`The secureIDx control object inherits a set of features from its MFC base class, ColeControl 130.
`
`These features include in-place activation and Automation logic. COleControl can provide the
`
`10
`
`control object with the same functionality as an MFC window object and the ability to fire events.
`
`COleControl can also provide windowless controls, which rely on their container 120 for some of
`
`the functionality a window otherwise provides, but offers faster display than windows. The fired
`
`events are used to notify the control container when something important happens in the control.
`
`The automatic logic in the securelDx control interacts with client computer 20 and creates a unique
`
`15
`
`signature for client computer 20. This unique identity of client computer 20 works as an
`
`authentication token in addition to the existing authentication systems, or as an identity token itself.
`
`SecureIDx is derived from client computer 20's MAC Address and may also be derived from the
`
`client computer's IP Address or the account user's biometrics.
`
`When a control 100 is used within a control container 120, it uses two mechanisms to communicate:
`
`20
`
`it exposes properties and methods, and it fires events. Figures 4 and 5 demonstrate how these two
`
`mechanisms are implemented.
`
`ActiveX controls 100 are an integral part of systems and applications, and they are required for
`
`essential functions in many environments. Though priorities many change from organization to
`
`organization and user to user, it is important to understand the tradeoffs between functionality
`
`25
`
`and security and to make informed decisions about the appropriate level of risk.
`
`Page 415 of 860
`
`

`

`WO 2008/052310
`
`PCT/CA2007/001767
`
`11
`
`Authenticode and Software Signing
`
`Software downloaded from the Internet to client computers 20 may contain unauthorized programs
`
`or viruses intended to cause damage or provide clandestine network access for malicious users. As
`
`networks become more interconnected, the threat of malicious software and viruses has extended.
`
`5
`
`To counter this growing threat, Microsoft developed Authenticode™ technology to enable
`
`developers to digitally sign software using standard X.509 public key certificates. Account users
`
`can verify the publisher of digitally signed software as well as verify that the software has not been
`
`tampered with, because the publisher has signed the code. For software distributed on the Internet,
`
`most users are more likely to trust software signed by certificates issued by a reputable commercial
`
`10
`
`certification authority. Therefore, if software is distributed via the Internet, it is useful to obtain the
`
`services of a commercial certification authority to issue digital signing certificates to sign the
`
`application.
`
`Java Embodiment
`
`The system and method according to the invention can also be implemented using Java. Java refers
`
`15
`
`to a programming language; a virtual machine designed to run that language (also known as the
`
`"JVM"); and a set of APis and libraries. The libraries are written in a combination of Java and other
`
`programming languages, for example C and C++.
`
`The Java language is object-oriented, with all code defined as part of a class. When the software is
`
`implemented using a NM, these classes are dynamically loaded as modules of code that can be
`
`20
`
`separately compiled. Classes are stored and represented as a sequence of bytes in a standard format,
`
`called the classfile format. (They need not be stored in files as such - it is possible to create and load
`
`classfiles on the fly, for example by downloading them from a network.)
`
`Java's security model is based on several layers of verification, including: checking the structure of
`
`each classfile to make sure that it conforms to the classfile format; checking the sequence of
`
`25
`
`instructions within each method to make sure that each instruction is valid, that there are no invalid
`
`jumps between instructions, and the arguments to each instruction are of the correct type. The JVM
`
`instruction set is designed to allow this analysis to be tractable; as classes are dynamically linked,
`
`consistency checks make sure that each class is consistent with its superclasses, e.g. that final
`
`Page 416 of 860
`
`

`

`WO 2008/052310
`
`PCT/CA2007/001767
`
`12
`
`methods are not overridden, and that access permissions are preserved; security restrictions are
`
`imposed on which packages can be accessed which can be used to prevent access to implementation
`
`classes that would not normally be needed by applets, for example; and runtime checks are
`
`performed by some instructions. For example, when an object is stored in an array, the interpreter
`
`5
`
`(or compiled code) checks that the object to be stored is of the correct type, and the array index is
`
`not out of bounds.
`
`This security scheme does not depend on the trustworthiness of the compiler that produced the
`
`classfiles ( or on whether the code was compiled from source in the Java language or from another
`
`language). The compiler for the standard API libraries must be trustworthy, but this can be ensured
`
`10
`
`because the standard libraries are provided by the JVM implementation. However, the scheme is
`
`complicated, and quite difficult to implement correctly. The presence of several layers increases the
`
`potential for error; a flaw in any layer may cause the whole system to collapse. This is offset against
`
`the increased efficiency over a fully interpreted language implementation where all checking is
`
`done at run-time (such as the current implementations of JavaScript and VBScript, or of Safe-Tel
`
`15
`
`and Safe-Perl).
`
`An applet is a software component that runs within a larger application. Java applets run in the
`
`context of a Java-enabled web browser. The web browser is responsible for maintaining the
`
`environment or "sandbox" that manages the applet's resource access.
`
`In practice, this usually
`
`serves to prevent the applet from accessing the local filesystem on client computer. The browser
`
`20
`
`downloads the applet code from a web server and either embeds the applet into an HTML page or
`
`opens a new browser window to show the applet user interface. The default security manager
`
`denies applets all access to the filesystem and all network access except to the web host that
`
`supplied the applet.
`
`The method and system may be incorporated into an applet, referred to herein as secureBox. The
`
`25
`
`secureBox applet is a signed applet that once trusted by a client computer runs harmlessly on the
`
`client computer with a strict security policy. The applet securely enumerates the user's computer
`
`identity by recording the MAC address and optionally the client computer 20's IP address and/or
`
`the account user's biometric information and posts such identity to server 70 which authenticates or
`
`generates alerts based on submitted identification.
`
`Page 417 of 860
`
`

`

`WO 2008/052310
`
`PCT/CA2007/001767
`
`13
`
`Applets do have several disadvantages. For example, applets require a Java plug-in, which is not
`
`always available. Some organizations do not permit users to install software, so these users might
`
`not view applets by default. There are also performance issues. The applet cannot run until the Java
`
`Virtual Machine is initialized, and this delay can be significant. Applets usually execute at a speed
`
`5
`
`that is comparable to, but slower than, compiled applications. Finally, Java applets are considered
`
`more difficult and expensive to develop than html based pages.
`
`The JAR file format is a convention for using PKW ARE™'s ZIP format to store Java classes and
`
`resources that may be signed. All JAR files are ZIP files, containing a standard directory called
`
`"/META-INF/".
`
`The META-INF directory
`
`includes
`
`a
`
`"manifest
`
`file", with name
`
`10
`
`"MANIFEST.MF", that stores additional property information about each file (this avoids having to
`
`change the format of the files themselves). It also contains "signature files", with filetype ".SF", that
`
`specify a subset of files to be signed by a given principal, and detached signatures for the .SF files.
`
`A typical Java security architecture is shown in Figure 6.
`
`Deploying Downloadable Code
`
`15
`
`Both Java and ActiveX authenticate code by signing it using a digital signature scheme. Digital
`
`signatures use public-key cryptography; each signer has a private key, and there is a corresponding
`
`public key that can be used to verify signatures by the signing party. Assuming that the digital
`
`signature algorithm is secure and is used correctly, it prevents anyone but the owner of a private key
`
`from signing a piece of data or code.
`
`20 An alternative approach to signing for authenticating controls, would be to secure the connection
`
`between the web site and the browser, using a transport protocol such as SSL 3.0 (or secure IP) that
`
`ensures the integrity of the transmitted information. The site certificate would be shown when a
`
`control runs or requests additional privileges. This would have several advantages over code
`
`signing, including: in cases where the web pages also need to be authenticated, it is much simpler
`
`25
`
`than requiring two separate mechanisms, and the account user 80 sees a single, consistent
`
`certificate; it is common for controls that need extra privileges, beyond the default environment or
`
`"sandbox" permissions for Java or scripts, to also require a secure (i.e. authenticated, and optionally
`
`private) connection back to the site that served them; it simplifies creating secure systems of co-
`
`Page 418 of 860
`
`

`

`WO 2008/052310
`
`PCT/CA2007/001767
`
`14
`
`operating controls and scripts that can span pages; individual controls can be revoked at any time,
`
`by removing them from all web sites; and an malicious user cannot reuse a signed control
`
`maliciously, because the controls themselves are never signed.
`
`It is not difficult to spoof a MAC address, however, it is extremely difficult for a malicious user,
`
`5
`
`such as a hacker or fraudster, to know what the MAC address is in the first place. In order to
`
`determine the MAC address, the malicious user would have to know specifically which client
`
`computer 20 was used to access the account, which is only really possible if they have direct access
`
`to the client computer 20 being used. Further security can be provided by checking the region of
`
`the IP address and verifying the IP addresses of the connecting computers to determine if attempts
`
`10
`
`have been made to hide a computer's identity.
`
`Given the above, fraud/hacking becomes possible only by malicious users who have physical access
`
`to the client computer 20 used to access the account or credit card. If this were to happen, a report
`
`can be provided showing exactly which MAC address and IP address was used to access the
`
`account, making it easy for a particular case to be disputed by a merchant.
`
`15
`
`The system according to the invention provides both convenience and security, and fraud
`
`prevention measures/actions to prevent access/purchases from unauthorized computers. The system
`
`is practical to implement and can compliment existing online authentication checks and/or
`
`purchases.
`
`The system may be viewed as an online computer registry and fraud/hack prevention system. The
`
`20
`
`system would be queried for any publisher or merchant that wants a significant security
`
`improvement with their system.
`
`The logic follows:
`
`New Account I Account Creation
`
`As seen in Figure 2, an embodiment of the process by which a new account is created includes the
`
`25
`
`steps:
`
`Page 419 of 860
`
`

`

`WO 2008/052310
`
`PCT/CA2007/001767
`
`15
`
`1. In step 210, an account user 10 using a client computer 20 logs into an online account provided
`
`by an account provider 80 for the first time, or purchases a good or service online with their credit
`
`card provided by a account provider 80, such as a credit card provider for the first time.
`
`2. In step 220, database 90 at server 70 hosting the account or used by the credit card provider to
`
`5 maintain the credit card account is queried, and the system determines that this is the first time the
`
`particular account or credit card has been used online.
`
`3. In step 230, the account is registered and verified. Depending on the security level selected by
`
`the administrator of the account provider 80, client computer 20 will either:
`
`(a) Automatically have its MAC address and IP address registered to the account or credit
`
`10
`
`card and stored in database 90;
`
`(b) Receive an e-mail automatically emailed to the e-mail address provided to the account
`
`provider, to confirm that the account user 10 has made the request. If the account user 10
`
`confirms the request, the MAC address and IP address of client computer 20 are registered
`
`with the account or credit card. If the account user 10 does not confirm the request, the
`
`15
`
`account or credit card may automatically be suspended, and an administrator notified; or
`
`(c) Receive a phone call using the phone number provided to the account provider 80, to
`
`confirm that they have made the request. If the account user 10 confirms the request, the
`
`MAC address and IP address of the client computer 20 are registered with the account or
`
`credit card. If the account user 10 does not confirm the request, the account or credit card
`
`20
`
`may be suspended, and an administrator notified. Optionally, an additional automated check
`
`could be made by an administrator using the account user's registered phone number to test
`
`the type of phone being used (PSTN line, cell phone, or VOiP). If the phone type is not
`
`appropriate (i.e. VOiP instead of a cell phone), the administrator could be notified for
`
`review and the account suspended.
`
`25
`
`Current Account/ Fraud Prevention
`
`Page 420 of 860
`
`

`

`WO 2008/052310
`
`PCT/CA2007/001767
`
`16
`
`The system according to the invention can also be used to protect accounts by preventing
`
`unauthorized access to such accounts. In such a use, the following steps, as seen in Figure 3, may
`
`occur:
`
`1. In step 31 O, account user 10 logs into their existing online account, or makes a purchase with
`
`5
`
`their credit card.
`
`2.
`
`In step 320, database 90 is queried, and determines that the account accessed is an existing
`
`account.
`
`3. In step 330, depending on the security level selected by the administrator, server 70 queries to
`
`the client computer 20 for verification purposes, specifically to determine if:
`
`10
`
`(a) The MAC address of client computer 20 matches the account;
`
`(b) The MAC address of client computer 20 matches the account and the IP address of the
`
`client computer 20 is from the appropriate geographical region; and/or
`
`( c) The IP address is accurate and is not being spoofed.
`
`4. In step 340, if the database query is successful, the authentication process or purchase continues
`
`15
`
`as intended.
`
`5. In step 350, if the database query is NOT successful, depending on the security level selected by
`
`the administrator, the following may happen:
`
`(a) Client computer 20 is automatically e-mailed (to the e-mail address provided to the
`
`administrator), to confirm that they have made the request. If client computer 20 confirms
`
`20
`
`the request, the new MAC address and IP address are registered to the account or credit
`
`card. This automatically registers the additional computer for use with the account. If the
`
`client computer 20 does not confirm the request, the account or credit card may
`
`automatically be suspended, and an administrator notified; or
`
`(b) The account user 10 is automatically phoned (at the phone number provided to the
`
`25
`
`administrator), to confirm that they have made the request. If the account user 10 confirms
`
`Page 421 of 860
`
`

`

`WO 2008/052310
`
`PCT/CA2007/001767
`
`17
`
`the request, the new MAC address and IP address are registered to the account or credit
`
`card. This automatically registers the additional client computer 20 for use with the account.
`
`If the account user 10 does not confirm the request, the account or credit card may
`
`automatically be suspended, and an administrator notified.
`
`5
`
`For investigative purposes, the system is able to provide the true IP address and MAC address of
`
`attempted frauds or hacks, thus allowing investigators to track down fraudsters or hackers, even if
`
`they are using proxy servers. Additional information could also be used by law enforcement to help
`
`gather information regarding online criminals and terrorists.
`
`The system is automated and has significant revenue potential by having multiple database servers
`
`10
`
`(co-located or licensed) to meet demand, and charge per usage fees for database queries and
`
`automated e-mail/call services. The system according to the invention thereby may save the online
`
`industry significant amounts of time and money.
`
`Using the system, the only fraud/hacks possible are by people who have physical access to the client
`
`computer 20. Although it is possible to spoof IP and MAC addresses, it is virtually impossible to
`
`15
`
`know (or find out) which MAC address is registered with the account, unless the malicious user
`
`knows which client computer 20 was used to register the account in the first place. The true IP
`
`address functionality also eliminates the risk of IP address spoofing by showing the true IP address
`
`used by each client computer in every online transaction. The system thereby can determine which
`
`client computer was used for the transaction, which would greatly limit a merchant's liability by
`
`20
`
`proving that the transaction was completed at an authorized location.
`
`Profiling
`
`The system according to the invention can be used for anti-fraud/ profiling purposes to allow users
`
`to look for and be notified of suspicious credit card activity. This additional protection helps make
`
`credit card transactions even more secure for online purchases.
`
`25 At present credit card companies look for suspicious activity on their own. However, each credit
`
`card company sets its own criteria, which may not be suitable for every card user. The system
`
`according to the invention allows clients to determine themselves the types of purchases they want
`
`Page 422 of 860
`
`

`

`WO 2008/052310
`
`PCT/CA2007/001767
`
`18
`
`to allow with a particular credit card. For example, a card user may want to be notified if a
`
`purchase over $100 is made on their card, or if there is a purchase overseas, etc. The card users
`
`themselves know exactly how they plan on using their card, while the credit card providers do not.
`
`If a suspicious transaction occurs, the card user can preselect to have