An information management system

ES 2 299 666 T3

DESCRIPTION

An information management system.

Background of the invention

This invention relates to the provision of extended Internet application management functionality, particularly in the areas of information security, transaction review and reporting, centralized policies, and application connectivity.

Electronic commerce (“e-commerce”), particularly between businesses (“B2B”), but also between businesses and consumers (“B2C”), is a rapidly growing market where buyers and sellers communicate using the Internet, a network of worldwide scope of linked computer systems, rather than by traditional means such as mail, telephone or personal meetings. Vendors advertise their products and services using digital brochures and catalogs, which can be viewed or downloaded over an Internet connection, through pages on the World Wide Web (WWW), or through electronic marketplace sites that typically deal with with articles or services from a particular market sector. Buyers can find suppliers, select items, get quotes, place or track orders, and even make payments entirely electronically and at any time. E-commerce holds the promise of increased flexibility, choice, and efficiency, with dramatically reduced procurement costs.

There are two universally accepted means of interfacing users with the Internet. The first of these is the "Web Browser" which allows users to view World Wide Web pages by accessing individual Web sites, the addresses of which are typically published widely, either using traditional means, or by referencing elsewhere. Web. The most widely adopted web browser is "Internet Explorer" from Microsoft Corporation.

The second means of interface is by using an Electronic Mail program, with which the user composes a message, known as an electronic mail, which is then electronically addressed to the intended recipient address on the Internet. Well-known e-mail programs include "Lotus Notes" from IBM Corporation and "Outlook" from Microsoft Corporation.

In a typical e-commerce scenario, a buyer can identify a particular product, along with pricing and supply information, on the seller's website. He can then place an order, either by filling out an electronic order on the website, or by sending an email directly to the seller. The order would typically include a commitment to pay, perhaps in the form of Credit Card details, or by some electronic means of payment. The seller would typically send an email back to confirm acceptance of the order.

Web Browsers operate in accordance with recognized regulations, in particular the Hypertext Transfer Protocol ("HTTP"), fully described in the Internet regulations document RFC2616. Email programs operate in accordance with recognized standards, in particular the Simple Mail Transfer Protocol (“SMTP”), fully described in the Internet standards document RFC0821 and the Multipurpose Internet Mail Extensions (“MIME”). fully described in the Internet normative documents RFC2045-2049.

Since e-commerce provides enormous benefits, its adoption increases to many new uses, which can be addressed to ensure its continued adoption, particularly if it is to ultimately replace traditional methods. One of the central issues is security.

The Internet is an open communications network, which is by definition insecure as it can be used by anyone. Means have been provided to secure sensitive information to be exchanged over the Internet (eg an electronic commerce transaction) by the adoption of secure transmission and messaging protocols. Secure point-to-point transmission protocols, used for example between a Web Server and a Web Browser, include the "Secure Socket Layer" ("SSL"), defined by the Netscape Communications Corporation, and its successor "Web Security. Transport Layer ”(“ TLS ”) defined in the Internet standards document RFC2246. The secure e-mail regulations include the "Secure Multipurpose Internet Mail Extensions" ("S / MIME") described entirely in the Internet regulations document RFC2633 and the "Pretty Good Privacy" a domain secure messaging system. public developed by Philip Zimmerman.

To control access to information on servers connected to the Internet, a user name and password system has been widely adopted. For example, access to discounted price lists on a particular Web server may be restricted to merchant users who have previously provided a username and password allowing access. Similarly, online information services typically make extensive use of usernames and passwords to restrict access to those who have paid for the service. By providing each user with a unique username and password that can be changed, the

ES 2 299 666 T3 service can ensure that only paying subscribers can access the system, and allow users to prevent access by others to their personal data stored by the service.

In e-commerce applications, the issue of identification and trust is a considerable problem. When a supplier receives an order via the Internet, it is perfectly possible, even probable, that there is no prior knowledge of the customer. The supplier can establish that the customer is a) who he says he is, in other words that he is not masking another person, and that b) that he is trustworthy and will ultimately pay for the goods or services to be supplied. These issues have been dealt with mainly in B2C commerce due to the use of credit cards. The customer provides their credit card number and address with the order, which the supplier then verifies with the credit card company, and obtains an authorization for the charge. The entire process is typically carried out online with no human intervention. This method is largely effective when a supplier ships items to the cardholder's address, as a potential thief would not only need to steal the cardholder's details, but would also need to intercept the delivery of the items. It is much less effective in the case of services where a physical delivery is not involved.

Clearly, the use of credit cards in electronic commerce, although widespread, is restricted to small-scale transactions that potentially involve amounts, say, up to $ 10,000. For transactions above such amounts (which in joint monetary terms exceed those below), a mutual trust third party should be used to establish both identity and trust.

Fundamental to establish identity is the use of Digital Certificates. A Digital Certificate may be issued to the customer by a trusted third party, which is then used to electronically "sign" the communications. Upon receipt of a signed message, the receiver (in this case the provider) can positively establish a) the identity of the sender, b) that the message has not been altered, and c) that the sender cannot therefore deny that the sender the message. The recognized standards for Digital Certificates are described in the ITU document X.509, and their use in Internet communications in the Internet standards documents RFC2312, RFC2459, RFC2510, RFC2511, RFC2527, RFC2560, RFC2585 and RFC2632.

The services of a Third Party, which can be billed, such as those provided by Valicert Inc., may be used to verify that a Digital Certificate has not been revoked, for example after the certificate has been compromised in some way.

Once the authenticity of the messages is established, the provider can use another third party to establish trust, or the same third party can be used to establish both authenticity and trust. For example, “Identrus”, a consortium of the largest banks in the world, provides a system such that when a supplier receives a message signed with a Digital Certificate issued by Identrus, it can independently verify that the customer is the holder of a valid account of good standing. prestige with a recognized bank. Ultimately, the system has been extended in such a way that the bank will additionally guarantee the transaction, and therefore guarantee payment to the supplier. It will be appreciated that the terms "customer" or "supplier" may apply to any parties involved in Internet communication.

Appropriate combinations of the systems described can be seen to provide a secure foundation for the use of the Internet and the services and functions available through the Internet. However, we have appreciated that there are several problems with conducting e-commerce using only these systems. These issues are discussed below.

In the secure messaging and transmission protocols listed above, data is usually encrypted prior to transmission and decrypted by the intended recipient prior to viewing. In this way, if the data is intercepted during transmission, it will be safe from being seen by unauthorized third parties unless they know or can find out the secret encryption key of the encryption algorithm.

Encrypting and decrypting data at each end of a secure link or message requires significant processing power. Additionally, both transmitting and receiving parties must be in possession of the same encryption algorithm encryption key, with the same encryption strength, for the system to function successfully. This often presents a problem, for example when regulations for importing and exporting data into or out of a computer system prohibit the use of higher strength algorithms, forcing the link or message to be encrypted with a lower encryption strength. , or totally preventing secure communications. Consequently, secure messaging and links are typically used only when necessary.

In the case of communications over the World Wide Web, the requirements for secure transmissions are determined and initiated by the web server. If, for example, the server is about to transmit an order form for completion by the user it can initiate a secure link so that the order information will be encrypted when it is transmitted back to the server. Similarly, once the request is complete the server can terminate the secure link and return to normal unencrypted communication.

Typically, the only indication the user has that a link has been secured is an icon (usually representing a lock), which appears in the browser window. Once the icon has appeared, the user

ES 2 299 666 T3 can then typically interrogate the browser to determine the strength of the encryption algorithm being used, and can decide whether or not to enter, and subsequently transmit sensitive information, such as your credit card details and address. .

In practice, however, users frequently do not verify that the link is secure, much less that the encryption strength is adequate to protect the information that is being transmitted. To solve this problem, email applications such as Microsoft Corporation's "Outlook" provide the ability to encrypt all emails by default.

The widespread adoption of usernames and passwords has created a management problem for many Internet users due to the sheer number they need to remember, particularly when good security practice requires changing passwords frequently. Similarly, users often need to use a variety of different usernames as some people may have taken their "favorite" on a particular site. In search engines such as "Internet Explorer" from Microsoft Corporation, facilities have been provided to remember, and automatically complete the username and password fields on subsequent occasions, and adding "helper" utilities such as " Gator ”from Gator.com. These facilities typically maintain a file of usernames, passwords, and the Web page to which each applies. These files are encrypted to ensure that only the appropriate user can access them. If such username and password files are lost or become unusable, such as when the authorized user has forgotten the encryption key and can no longer be contacted to provide it, or when the file is accidentally or maliciously lost, destroyed, or corrupted then access to Internet accounts can be lost, and each site must be individually targeted to replace or recover the necessary username and / or password. This can be a very expensive problem for corporations in terms of missed accesses and administration time. Additionally, such remembered usernames and passwords are only available for use on the machine on which they were originally used. If the user moves to another machine, or uses multiple machines then the usernames and passwords are not available to him from the other machines.

All businesses, and many individual users, have a legal obligation to maintain accurate records of the transactions they undertake, but for e-commerce transactions this can be difficult. Businesses should keep recordings for review purposes, for example to prove the terms under which items were ordered in the event of a dispute. Such records are considerably more difficult to maintain in an e-commerce environment, requiring the user to retain, for example, copies of orders sent by email, or to print the receipt from the Web page upon purchase from the Web site. . For the user, this is labor intensive and there is no guarantee that any such recordings created will be complete or reliable.

An automated solution for keeping records of e-commerce transactions is provided by the Max Manager application from the Max Manager Corporation. Max Manager captures the receipt pages on well-known Web sites, extracts the transaction information from those receipt pages, and then stores both the receipt page and the extracted transaction information locally on the machine on which it is located. running the application. However, to operate, the Max Manager must be supplied with the exact address and composition of the receipt page. Max Manager determines that an e-commerce transaction has taken place either by detecting the address of the receipt page, or by comparing the current page being viewed by the search engine with the composition of the receipt page with the one supplied. Once a receipt page has been identified, the relevant transaction details are extracted from the receipt page using the known layout of the page as a template for comparison purposes. A significant drawback with the Max Manager is that it can only be used to extract data from the pages for which details have been supplied. Also, if the layout of the receipt page is changed then the Max Manager cannot meaningfully extract any data from the page until it is supplied with a new template for the changed layout. Since Web sites are frequently changed, the Max Manager must be constantly updated to take account of such changes. This is not practical on a large scale and inevitably leads to transactions being lost or worse, incorrectly reported.

The problems also stem from the fact that the computer terminals are distributed, often resulting in terminals and users being located in different locations. In multi-user environments, user machines can be physically connected to each other, using for example a Local Area Network ("LAN"), which provides an exit port for connection to the Internet. They can also be connected to local servers such as Microsoft Corporation's “Exchange Server”, which acts as a central collection and distribution point for e-mail messages, and Microsoft Corporation's “Proxy Server”, which acts as both a a cache memory to improve the performance of frequently visited Websites, and as a filter to prevent access to certain Websites that may have been flagged as undesirable. However, as regards the exchange of information, except in the case of a message sent between two local users, each user operates entirely isolated from the others in the same location. This presents a significant management problem for a corporation and other organizations, which have no means of controlling employee activity and cannot benefit from the significant cost savings that could be made by sharing information. For example, two users in an organization can independently receive digitally signed email messages from the same sender. Both recipients must separately validate the Digital Certificate, incurring two validation charges, at least one of which was unnecessary.

ES 2 299 666 T3

A system and method for creating, editing and distributing standards for processing electronic messages is known from United States Patent No. US 5,917,489. Such rules are determined by workstation users for deleting help, filling in, and responding to their messages.

US 6,073,142 describes a system and method for automatic postponement and review of electronic mail messages.

The present invention provides additional functionality to the aforementioned systems to alleviate their inherent problems and provide a single integrated system for the exchange of information.

Summary of the invention

The invention is set forth in the independent claims to which reference will now be made. Advantageous features of the invention are set out in the appended claims.

The information management system provides many advantages in the electronic commerce environment to companies that trade online, which can benefit from being able to regulate the transactions carried out by their staff according to their instructions encoded in the directive data, automatically keep records of passwords and business conducted online, avoiding payment for unnecessary checks on the validity of digital certificates, and ensure that the transmission of data by your staff is always done safely.

Brief description of the drawings

The preferred embodiment of the invention will now be described in more detail, by way of example, and with reference to the drawings in which:

Figure 1 is a schematic illustration of the current arrangement of the systems and resources that make up the Internet according to the prior art;

Figure 2 is a schematic illustration of the preferred embodiment of the invention implemented in a corporate environment;

Figure 3 is a schematic illustration of the operation of a web browser in accordance with the preferred embodiment of the invention;

Figure 4 is an illustration of a typical login window generated by a web browser;

Figure 5 is a schematic illustration of the operation of an email client in accordance with the preferred embodiment of the invention;

Figure 6 is a flow chart illustrating the operation of an expansion module, in accordance with the preferred embodiment of the invention, to capture username and password values ​​transmitted by a user to the remote Web site ;

Figure 7 is an illustration of an example of policy data specifying control conditions for recording data;

Figure 8 is a flow chart illustrating the operation of an expansion module, according to the preferred embodiment of the invention, for the recognition of credit card numbers contained in data transmitted to or from a Web server or a email client;

Figure 9 is a flow chart illustrating the operation of an expansion module, in accordance with the preferred embodiment of the invention, to establish the validity of a digital certificate received by a user;

Figure 10 is an illustration of an example of policy data for determining whether or not a digital certificate should be verified;

Figure 11 is a flow chart illustrating how the example policy data shown in Figure 10 is used to determine whether or not verification is required for a digital certificate;

Figure 12 is a flow chart illustrating the operation of an expansion module, in accordance with a preferred embodiment of the invention, to identify transmissions from a user or a user comprising part of an electronic commerce transaction;

Figure 13 is an example illustration of policy data intended to be used with the process illustrated in Figure 12 to identify a transaction;

ES 2 299 666 T3 Figure 14 is a flow chart illustrating the operation of an expansion module, according to a preferred embodiment of the invention, to record identified transmissions that comprise a part of a simple transaction thus forming a record of the transaction;

Figure 15 is a flow chart illustrating the operation of an expansion module, in accordance with a preferred embodiment of the invention, for approval or rejection of identified transactions based on a predetermined policy scenario; and Figure 16 is an example illustration of policy data for determining whether an identified transaction requires approval, and for identifying an appropriate approver;

Figure 17 is a flow chart illustrating the operation of an expansion module, in accordance with a preferred embodiment of the invention, to determine an appropriate level of encryption for a transmission and to allow that transmission to be transmitted only if that level;

Figure 18 is an example illustration of policy data specifying required encryption strength for various types of data;

Figure 19 is an example illustration of policy data to control re-routing of outgoing messages;

Figure 20 is a flow chart illustrating the operation of an expansion module, in accordance with a preferred embodiment of the invention, for redirecting output messages to a third party for review prior to transmission, using the policy data shown in Figure 19;

Figure 21 is a flow chart illustrating the operation of an expansion module, according to a preferred embodiment of the invention, to control the upload of information to an external company site, using policy data shown in Figure 19;

Figure 22 is an example illustration of policy data to control forwarding of messages to recipients inside or outside the company;

Figure 23 is a flow chart illustrating the operation of an expansion module, in accordance with a preferred embodiment of the invention, using the policy data shown in Figure 22;

Figure 24 is an example illustration of policy data for controlling whether an outgoing message is digitally signed or not; and Figure 25 a flow chart illustrating the operation of an expansion module, in accordance with a preferred embodiment of the invention, using the policy data shown in Figure 24.

Description of the preferred embodiment

The preferred system provides Internet users with an automatic way of managing the flow of information over a computer system. It provides facilities to manage the level of security at which transmissions occur, facilities to record online transactions and to suspend transactions that are about to be made to third parties for approval, and means to stop transactions taking place if approval is rejected; it also provides facilities to extract and record relevant data from any transmissions that are received or about to be transmitted, and to intelligently manage the transmission of emails.

The preferred system provides solutions for many problems encountered by e-commerce companies trading over the Internet; consequently the following sample discussion will be directed for the most part to the implementation and use of the system by a reasonably sized company that conducts at least some of its business over the Internet. However, it will be appreciated that anyone, including companies of any size or description and private individuals, using the Internet can benefit from the functionality provided by the preferred system.

The functionality of the preferred system is implemented by code modules that "plug in" within the web browser or email client. These "expansion" modules can be used to control and alter the behavior of the web browser or email client as it works.

Many existing web browsers and email clients can be easily integrated with such expansion modules. In the case of Microsoft's Internet Explorer, the module is known as a "Search Helper", and is more fully described in the document "Browser Helper Objects: The Browser the Way You Want It" by Dino Esposito, published by the Corporation. Microsoft in January 1999. In the case of Microsoft Outlook and Exchange Email Clients, the expansion is known as the “Extension” module and is more fully described in Sharon Lloyd's “Microsoft Outlook and Exchange Client Extensions” document, published by

ES 2 299 666 T3 by Microsoft Corporation in March 1998. The use of the "Browser Helper Object" and "Extension" modules made in the preferred system will be described in more detail later.

The use of the browser or email client expansion modules to implement the preferred system functionality has the additional advantage that, since the encryption of the message content is usually done by the browser or email client itself, the examination of the content of the transmission, to extract the password information or to determine the desired level of encryption for example, it can take place before the content has been encrypted ready for transmission, or indeed after it has been received and decrypted.

Figure 1 shows the relationship between service providers, typically companies that sell items and services over the Internet 10, and users who wish to purchase such items or services. Users equipped with web browsers 22, 24 and 26 can connect via the Internet and retrieve information from the web page from web servers 14 and 18. Alternatively, users with email applications 20, 30, and 32 can send email messages with abc.com and xyz.com through email servers 12 and 16.

In a corporate establishment, such as the one illustrated in the upper right corner of Figure 1, the corporate user's web browsers 24 and 26 connect to the Internet through proxy server 28. proxy server 28 is used as a cache of Web pages and control of access to Web sites. Similarly, the corporation has email clients 30 and 32, connected to the Internet through email server 34 that acts as a central collection point for incoming emails into the corporation and that control the distribution of emails to individual users. It will be appreciated that although Figure 1 describes abc.com and xyz.com as sellers, the corporation can be both a buyer and a seller, and as buyers abc.com and xyz.com would be described as corporate users for the purpose of this description. .

In the case of emails sent and received by personal email application 20, it will be noted that the email will typically be collected and distributed by a remote email server provided by the provider of the Internet connection service to which the personal user subscribes.

Although many of the features and functions of this system provide considerable benefit to individual users, the system provides the greatest advantage when operating in a multi-user environment where transaction information is shared with many users. Figure 2 shows a schematic diagram of the preferred system configuration in a multi-user environment. The preferred system comprises a Central Management server 40 connected to the database 42 and operator consoles 44. The Central Management Server 40 is also connected to the Management Office Application Expansions comprising the Application Interfaces 50 , 52 and an open Application Program Interface 54, and the Exit Port components 60, 62 and 64. The Output Port 62 component is shown connected to the User Application Expansions, located on one or more user machines, comprising the Internet Explorer Expansion 70, the Netscape Browser Expansion 72, the Microsoft Outlook Expansion 74 and the Lotus Notes 76 Expansion. These expansions are used to provide preferred system functionality in the host program in which they are embedded. Four possible host programs are shown, Internet Explorer, Netscape Browser, Microsoft Outlook, and Lotus Notes, but any other program with the ability to connect to the Internet can be used, assuming its behavior can be modified to implement the functionality. of the preferred system.

The connection to the Internet 10 is made through the expansions of the User applications and their respective host programs.

Output port components 70, 72, and 74 are optional but preferred as they allow scaling of the entire system, with each output port storing or forwarding information, thereby allowing any number of users to connect.

The information from the Multiple Application Expansions 70, 72, 74 and 76 for the different applications on multiple user machines, is shared with the central management server 40 and stored in the associated database 42.

Back Office Application Modules 50, 52 and 54 allow the system to interface with third party management applications such as order processing and accounting systems. This allows transaction information to be entered automatically and processed by such systems.

The Operator Consoles 44 are provided for administrative purposes, and in particular for the approval of transactions. Although it is logically represented connected directly to the central management server in Figure 2, such consoles could work on any machine connected in a network. When an email or web browser expansion determines that a particular transaction requires approval, a request is sent to the Central Management Server and queued pending approval by an authorized operator.

ES 2 299 666 T3

The operation of the system is controlled by policy data, which stores the corporation's regulations regarding security, authorization, and the actions that users are allowed to perform, as well as operational information. Preferably, the policy data is stored in a policy file on the Management Server for access by any of the Operator Consoles 44, the Management Office Application Expansions, or the User Application Expansions. The system administrator or network supervisor can define one or more policies or scenarios from the policy file and can assign individual users or groups of users to different policies, thereby controlling the user capacity or even the capacity of a station. to interact with the Internet without the need to set parameters and directly control each user machine. A user in an accounting department or a company for example can be assigned to "accounting policies"; any subsequent changes to those policies will automatically result in a change in the capabilities of all users assigned to those policies.

It is preferable that the ability to edit or set policy data is restricted to the network supervisor or other authorized person or persons. This can be achieved by designating one or more supervisory workstations on the network, enabled with access to edit policy data such as Operator Consoles 44.

Preferably, the policies are like a tree structure, allowing scenarios to be forced down to individual policy nodes, and global changes made quickly, for example if the CEO wants to make all purchases require her approval if the flow of Company cash could become a problem. Such a policy-based system greatly reduces the latency inherent in both traditional shopping systems and today's e-commerce shopping environments.

Each user on the network will have their own representation of the policy data. Preferably, only the branches and leaves of each user policy that differ from the master network policies are stored as this saves memory space. Although the policy data is preferably stored in file form on the Central Management Server, it is not intended that the storage of the policy data is restricted to file form only. Any other representation or encoding of policy scenarios can be used within the preferred system.

The implementation of the system in a web browser or in an email client will now be described in more detail.

Using the preferred system in a web browser

Figure 3 shows the simplified operation of a web browser. The web browser is launched in step S100 in response to a start request from the user or automatically from the startup file of the user computer. The startup file on the user's computer contains commands to automatically start the specified programs when the computer starts up. After the web browser has started, it typically prompts for a "home page", the default web page to view, according to a predetermined scenario. This is shown in step S102.

The request is sent to the appropriate Web server 90, the exact Internet address of which is usually determined by Domain Name Services; Web server 90 then responds with the appropriate data defining the Web page. This process is represented respectively as steps S104 and S106 resulting in step S108.

The data that defines the Web page consists of an HTML descriptor, and other possible data types such as XML or ActiveX, and Javascript that encode executable programs. The Finder interprets this data, displaying it on the screen and / or executing it as appropriate in step S110.

Next, the browser typically waits for user input in step S112. Such input may include filling in fields presented on screen, clicking on a hyperlink, or entering the URL address of the new web page. Ultimately, such actions lead to an additional request being sent to the Web server 90 in step S114 and step S116. The request may simply be another web page address, or it may contain additional data such as that entered by the user in the fields presented on the screen.

Figure 4 shows a sample web page screen, in which a GUI is presented to the user to receive the username and email address. It will be seen from the reference to Figure 4 that the user has entered his name as "Fred Smith" within the field provided in the name request, and his email address as "fsmith@xyz.com" within the address field. of e-mail.

When the user clicks on the "Submit" button provided on the request window, the details entered by the user are included in the command sent to the Web server 90. Such a command may be;

http://www.sample.com/ sample2.htm? UserID = Fred + Smith & email = fsmith@xyz.com&submit = submit

ES 2 299 666 T3

From the above it can be seen that the username is incorporated into the command as the value of a variable called "UserID" and its email address is incorporated as the value of a variable called "email".

The command is assembled in step S114, and transmitted to the Web server 90 in step S116 where the username and email address can be used, for example to send product information to the user via email, or to access other web pages.

The expansion module provided by the preferred embodiment of the invention in the form of a Search Help Object (BHO) provides additional functionality to augment that of the standard Web browser. The BHO is implemented to respond to a significant number of events that occur when the Web browser is operated and directed by the user to interact with various Web sites and pages.

The BHO is implemented to monitor the browsing requests and the data transmitted to the Web server from the search engine and the identification data that are unique to the user. This can be done simply by searching the output data stream for the presence of predetermined words or phrases. In the above case shown in Figure 4, the two variable definitions "UserID" and "email" can be searched, and the data that follows them is extracted and stored. Alternatively, the BHO can look for the “?” Symbol, which indicates the end of the URL to which it is connecting and indicates that what follows is data. The BHO can also monitor the incoming stream data received from the website to which it is connecting.

Also, the BHO can be implemented to monitor the operation of the web browser itself. As the web browser works, it generates “events” to notify the co-dependent software modules or objects that something significant has just happened or that an action has just been completed. The name of the event is usually descriptive in itself of what just happened; additional data is usually available that describes the event in more detail. The BHO is in place to catch these events and take action depending on them.

One such event for which the BHO is implemented to respond to the so-called "BeforeNavegation2" launched by the Web browser when the user requests the browser to browse a new page. The event is broadcast and can be recognized by the BHO before the requested page is downloaded, allowing the BHO to take any relevant action before the user views the page. One such action could be to save the page and any of the data transmitted in response to that page to a database. Another such action could be to identify the URL of the page requested from the event and prevent the page from downloading.

Another event that the BHO catches is the “DocumentComplete” event, which is fired by the web browser when a new page has been fully downloaded from the web site into memory. The page is encoded in the form of a Document Object, conforming to the Microsoft Document Object Model (DOM). The DOM provides comprehensive access to the data that comprises the page, allowing BHO to extract the data elements that are of interest to it. For example, the BHO may request data from the DOM to determine if the page is part of an e-commerce transaction. This can be done by searching for objects in the DOM for terms such as "Receipt" or "Account Number".

The BHO can also use the DOM to determine the names of the fields or types of fields of the data that is being requested on a Web page. The data entered by the user within such fields can then be extracted from the DOM and stored or taken action. The names of the fields are typically descriptive of what is stored; passwords, for example, are often kept in a field called "password" and thus can be searched on a web page. Credit card numbers can be searched in a similar way. Usually the password fields are of a type such that any input data is displayed as asterisks on the screen. This can also be determined from DOM analysis and used to identify relevant data.

User data would not normally be present on a Web page downloaded from the Web site, but is entered by the user within an HTML format. Usually, potentially sensitive user data is transmitted to the Web page site through the Web server when the user selects the "Submit" button. At this stage, the BHO can catch the "Send" event emitted by the web browser, and access the DOM to extract the user data, and if necessary, prevent the data from being transmitted.

Encryption and decryption over a secure link takes place after point C and before point A in Figure 3 respectively. In this way, the BHO can analyze the data before it is encrypted or after it is decrypted. This is an advantage as there is no need for the BHO itself to perform any encoding or decoding of the data. This does not affect the ability to determine whether the link is secure or not, as a secure link can be identified by the protocol identifier "https" at the beginning of the current URL address. It is preferred that the examination of the content of the transmission takes place before encryption occurs or after decryption.

Discussion of how an email client works

The operation of a typical email client, and the implementation of the preferred embodiment in an email client are now described with reference to Figure 5 of the drawings.

ES 2 299 666 T3

Figure 5 shows the simplified operation of an email client. The Receive and Send operations typically operate independently, and these operations are shown separately on opposite sides of Figure 5, beginning with steps S120 and steps S130 respectively.

An operation of "receiving a message" from an email client is started in step S120. This can be done automatically at predetermined intervals to keep the user informed of any new messages they receive, or it can be done in response to the user's manual selection of the "receive messages" icon. Starting this operation causes the email client to query the email server 95 and download any new messages to the user's machine. In step S122, an email message is received by the email client. Typically, when a new message is received, it is added to an "input box", with the headers of the received messages (name of senders, date and title for example) arranged in a list. The user then clicks on the appropriate entry in the list to read the entire message causing it to be displayed on their computer screen. The email message is displayed on the screen in step S124.

In the case of an outgoing email, the user selects the option of "compose email" in step S130. In response, the email client provides an interface comprising a text editor in which the user can enter the text of the body of the message and other information such as the destination address, subject, and so on. The user composes the message in step S132 and then chooses to send it, selecting an icon or a menu option provided by the email client to issue a "send command". The email is sent to the email server for transmission to the receiver in step S134. If any encryption is applied by the email client, it is applied in step S134 before transmission.

In the preferred embodiment, additional functionality is provided for the email client through an expansion module. Preferably, the email client is one of those provided by Microsoft, such as the Microsoft Exchange client, or the Microsoft Outlook client, and the expansion module is coded as an extension of the Exchange client. These are described in Sharon Lloyd's "Microsoft Outlook and Exchange Client Extensions" document mentioned above.

An Exchange Client Extension is a component object that complies with Microsoft's Windows Component Object Model (COM) and that uses the Exchange interface IExchExt. This Interface provides several additional interfaces to modify the operation of the Exchange email client, such as the IExchExt Command Interface, which allows you to modify or replace the behavior of an existing client and add new commands to the client menu; and the IExchExtEvents interface that allows customizing the behavior to be implemented to handle client "events" such as the arrival of new messages, reading, writing, sending messages, and reading and writing attached files. The IExchExtMessageEvents, IExcht SessionEvents, and the IExchExtAttachmentEvents interfaces are also provided and provide added functionality for the more specific tasks that each of the interface names suggests.

In the preferred embodiment, the Exchange Client Extension that forms the expansion module is implemented to respond to client "events" that are launched by the client program when it performs operations and completes actions. The "events" in question are provided by the COM interfaces mentioned above. Monitoring of the email client by the expansion module can therefore be viewed as analogous to the way the BHO expansion module monitors the operation of the web browser.

The email client expansion module is implemented to respond to the "OnDelivery" event that is thrown for example when a new message is received from the underlying mail delivery system and before it is visible to the user. The “OnDelivery” event contains information to access the different parts of the e-mail message that has been downloaded and is kept in memory. The message header, message body, and any attachments are encoded in memory as message object properties that can be accessed separately through Mail Application Program Interface (MAPI) calls.

Through the information supplied as part of the “OnDelivery” event, the expansion module can access the header of the message and extract, for example, the identity of the sender. In addition, the expansion module can use the information obtained from MAPI calls to scan the body of the received message for keywords or relevant data. You can search for evidence of an e-commerce transaction, identifying significant words such as "receipt" or "account number." The message can then be stored for review purposes. In the case of an unapproved sender, or harmful message content, the message can be deleted without viewing.

Analysis of a received email then occurs at point A in Figure 5 before it is viewed by the user. Preferably the email is scanned even before the email is placed in the Inbox. When a message is not automatically decrypted before being placed in the Inbox, for example when the user is required to enter a decryption key, the message is examined immediately after decryption, but before it is seen. Digital Certificates can be attached to email attachments and can be easily examined before viewing, allowing any appropriate actions to be taken, such as validation.

ES 2 299 666 T3

Another significant client event that implements the expansion module is responding to the "OnWriteComplete" event that is thrown when the user has selected the "send command" and has requested the email client to transmit a new email to the mail delivery system. . This event is fired, at point B in Figure 5, before transmission takes place and before any encryption. The new message to be transmitted is stored in memory in the same way as an object that can be accessed by MAPI calls. The expansion module can use MAPI calls to scan the content of the outgoing email for sensitive data, such as a credit card number, and subsequently cause the message to be recorded or even blocked.

Expansion Module Operation

The preferred implementation of the Web browser and email client expansion modules has been described above with reference to Figures 3 and 5. The functionality provided by the expansion modules will now be described in detail and with reference to the Figures 6 to 18.

Identification and Recording of User Names, Passwords and other information

The preferred system provides a means of automatically identifying, collecting and storing data contained in transmissions to and from a user workstation, in particular user names and passwords entered by a user to access website pages, File Transfer Protocol (“FTP”) sites and other similar sites on the Internet.

Systems that currently provide facilities to record passwords only do so when a user clicks on the "remember password" option provided by the GUI. The password is stored in a protected local file on the user's machine that is only opened when the user authenticates on that machine, for example, by entering their username and password at boot time. The option to remember the password causes the system to remember the user's password when they visit the next time, filling in the password field with the password so that the user does not have to enter it each time it is requested. The drawback of the password file that has them stored locally is that if the user moves to another machine, they do not have access to the stored password file and will have to re-enter the password themselves.

The preferred system identifies passwords automatically, without the need for user instruction, and stores the identified passwords and user names in a data store. Preferably this is the central database 42. This allows to recall the passwords of any user regardless of the terminal the user logs on to, providing that the terminal has access to the central database.

Any identified passwords and usernames are stored in the database along with the names of the fields in which they are stored on the original Web site and the address of the Internet site to which they were transmitted and in which they are used. . Site information can simply be retrieved as included in the HTTP request by sending the username and password information to that site, and on behalf of the web page held in memory.

Preferably, for the sake of security, the information stored in the database is encrypted so that only a number of selected people, such as network supervisors, system administrators or company directors, have access to it. They can access the database either through a workstation on the network, by entering a username or password to identify themselves, or through a supervisor workstation, such as the Operator Consoles. 44.

This storage of usernames and passwords along with address details presents a significant advantage for companies using online facilities. With existing technologies, if a user forgets his authentication password, preventing access to the protected file, or leaves the company without having revealed it, the Internet service cannot be accessed. A similar situation occurs if the protected file is damaged, deleted or, on the contrary, lost. Each Internet service must then be accessed to replace or recover the lost password, which can be expensive in terms of lost access and administrative time. With the preferred system, password information can be retrieved from the central database, so that access to Web sites is not lost.

Figure 6 is a flow diagram that schematically illustrates the operation of the expansion module implemented to extract the username and password information from the data to be transmitted to the Web server.

In Step S150, the expansion module starts and parses the data about to be transmitted to the Web server from the browser. This occurs at point "C" in the process illustrated in Figure 3. Control then proceeds to step S152 where the expansion module determines whether or not the data to be transmitted contains the username information. or password.

Passwords and user names can be identified as described above with reference to Figures 3, 4 and 5, by identifying the field names in the command sent or by using the DOM, for example, to search for field names, field types, o the display method used to identify the data

ES 2 299 666 T3 on web pages. These can also be retrieved from the HTML of the Web pages, from the associated windows or from the GUI (Graphical User Interface) presented by remote servers or providers on the World Wide Web or even by browsing the content of e-mail messages.

Identifying passwords and usernames in passed commands or in the DOM of a Web page from their field names depends on the names of the fields that describe their purpose with obvious tags such as "password" or "field name. Username". In cases where the field names are not significant in themselves, the nature of the data being transmitted can be inferred from the data type, which are "String", "Integer" and so on. or the screen display method used to enter the data. The fields that are intended to receive a password can be identified from the representation by looking for a field type "password" in the DOM. Text boxes on a Web page into which password data is entered, for example, typically have an input character such as an asterisk; this property can be determined from the dOm and used to infer that the data input to the text cell is a password even if there are no other prompts. Although the password is displayed as a string of asterisks, the in-memory representation still contains the character information that has been entered by the user. The password can be retrieved simply by extracting the entry from the field.

Alternatively, passwords and user names can be identified by referring to those stored by other programs such as Microsoft's "Internet Explorer" when the remember password option is selected by the user. Such passwords are stored in a protected local file on the user's computer. This file is "opened" when the user authenticates on the computer, and therefore can be accessed to obtain the password and username information by the browser expansion module of the preferred system.

If the expansion module does not detect a username or password in the data being transmitted, control passes to step S158 at which point the module exits and control passes again to point "C" in Figure 3. The browser can then transmit the data to the web server. If, on the other hand, a username or password is detected by the expansion module in step S152 then control passes to step S154, where the values ​​of the identified username or password and the URL or other identifier are extracted from the web page to which the data is transmitted. Control then proceeds to step S156 where these values ​​and the URL or other identifier are stored in a predetermined database of the system 42. Once storage has taken place, control passes to step S158, where the module exits and control is passed back to point "C" in Figure 3. The browser can then transmit the data to the web server.

The preferred embodiment need not be limited only to the storage of passwords and user names which have been used as an example for the immediate advantage that their storage provides. It may be useful to extract and store other types of data, particularly those related to electronic commerce transactions, such as credit card information and digital certificates to provide a database or record. The system can also be applied to extract information from transmissions to email systems.

The information can be extracted in the way described above, through the DOM or through MAPI calls to the COM representation of the email content, or it can be extracted from the language in which a Web page is encoded. Web pages are typically encoded in Hypertext Annotation Language (HTML), a human-readable text based on a language that can be searched for known keywords or pointers using conventional text matching techniques. In the preferred embodiment, recording the data may involve recording only the password and username information, recording the URL of the web page being viewed or of an email account, recording any data transmitted to the login fields. the web page, and recording the HTML of the web page, so that the web page can be retrieved and viewed later.

Expansion modules provided by the preferred system work in conjunction with policy data, which can be written to a file, database, or for example software code. The policy data allows a user of the preferred system to instruct the operation of each of the expansion modules thereby controlling their functionality.

The sample representation of the policy data, illustrated in Figure 7, shows how a user can control the operation of the expansion module to record user name and password information along with other types of data.

The tree-like structure of the policy data is clearly seen in Fig. 7 which shows only one major branch of the policy data titled "Recording". The "Recording" branch is separated into two sub-branches called Search and E-Mail, which contain instructions for the operation of the Web browser and e-mail client expansion modules respectively.

The Finder branch contains three sub-branches called "DataAGrabar", "When to Start Recording" and "When to Stop Recording". The DataAGrabar branch specifies the type of data that is extracted from transmissions to or from user workstations and a Web server. In this illustration, four types of data have been referred, these being the URL of the Web page that is being viewed, the HTML of the Web page that is being viewed, the data that is entered by a user within the fields provided on the Web page and sent to the Web site, and any

ES 2 299 666 T3 other passwords and user names that are entered by the user. These refer to four different sub-branches of DatosAGrabar, entitled "URL", "HTML", "Fields Sent" and "Passwords". A Yes / No option on each of these branches specifies whether the indicated data will be recorded or not.

The WhenRecordingBegin branch sets several conditions that specify the point at which the data specified in theDataAGrabar branch will be recorded. Five conditions are illustrated in this example, each of which sets a separate branch and are respectively titled "WhenSearchOpens", "IfCreditCardNumber Transmitted", "IfPassword-Transmitted", "IfKandWordsReceived" and "IfSendedKeywords". Whether or not these conditions are used to determine when to start recording is indicated by the Yes / No marks on each branch.

Similarly, the WhenStopRecording branch lists three conditions that can be used to determine the point at which recording of the data specified in theDataAGrabar branch will stop. These conditions are "WhenUserClose Search", "WhenUserChangeSite" and "WhenUserChangePage". The Yes / No status of each of these conditions and for each type of data to be recorded can be easily set by a user of the preferred system to control the operation of the expansion module.

The Email branch of the policy data is divided into the DataAGrabar branch and the WhenSabb branch. Each of these branches is subdivided into branches dealing with Sent Mail and Received Mail. The type of data that can be recorded is set in the DataAGrabar branch and for the sent mail it can be the text message, any attachment to the message, and in the case of messages signed with a digital signature, a copy of the digital certificate accompanying the signature . The conditions for recording sent mail and received mail are set in the When to Record branch and can be based on the identification of a credit card number, a keyword or a digital certificate in the mail that is sent or received.

The tree-like structure described is the preferred form for policy data as it allows the data to be easily organized and named. It also allows assigning different users to different branches of the tree to receive different directives. Although the tree-like structure is preferred, other arrangements may be possible. The branches shown in this diagram are only intended to be illustrative.

Identification of Credit Card Numbers

The preferred system also looks for Credit Card numbers or other account information in the data to be transmitted to the web page server or email client by looking for a string of numeric digits, typically between 14 and 16 in length. It then determines whether the string of digits passes one of the checks used universally by credit card companies to validate card numbers. If a credit card number is found in the transmission, then the preferred system can take various actions depending on the scenarios in the policy file, such as referring the transmission to a third party for approval, renegotiating a higher level of encryption to keep the transmission secure if the credit card number belongs to the company, or to completely prevent the transmission from taking place.

The most common test for identifying a credit card number is defined in the ANSI X4.13 standard, and is commonly known as LUHN Mod 10.

The Luhn formula is applied to a credit card number to generate a check of the digits, and thus can be used to validate credit cards, in which case the check of the digits is part of the formula. To validate a credit card number using the Luhn formula, the value of every second digit after the first, starting from the right side of the number and moving to the left, is multiplied by two; all digits, both those that have been multiplied by two and those that have not been multiplied, are added together; Any of the digit values ​​that become greater than or equal to ten as a result of doubling are added as if they were two single digit values, for example: “10” counts as “1 + 0 = 1”, “18” counts like "1 + 8 = 9". If the total of the sum is divisible by 10, then the credit card is a valid credit card number.

Figure 8 is a flow chart illustrating the operation of the expansion module that detects credit card numbers, using the Luhn formula described above, in data that is about to be transmitted. If a credit card number is identified, the expansion module implements additional checks based on the directives, based on which result, the expansion module can determine to transmit the data containing the credit card number or prevent the transmission.

The module begins operation in step S160, which follows point "C" in the process illustrated in Figure 3 in the case of the browser implementation, or point B in the process illustrated in Figure 5 in the case of an implementation of an email client. Control passes from step S160 to step S162 in which the module scans the data about to be transmitted to the web server or the email service and extracts therefrom a first string of digits which is probably a card number. credit.

This is achieved by scanning the data contained in the transmission for string of digits over a particular number of digit lengths. Credit card numbers are normally made up of more than 12 digits, and not usually more than 16 digits in length. In this way any strings of digits in this range can be identified as possible credit card numbers.

ES 2 299 666 T3

Following the extraction step S162, control passes to the decision step S164 where an end-of-file checking routine is performed. If the data does not contain candidate credit card numbers and the end of the file check is reached before any first candidate number can be found, then in step S164 control passes to step S178 where it is allowed to proceed. the transmission of the data without any additional verification being carried out. The module then exits in step S180. The control resumes the operation of the web browser shown in Figure 3 from point “C” or in the operation of the email client shown in Figure 5 from point B.

If a first potential credit card number is found in the data in step S162, then it is extracted and stored in memory. The end of the file has not yet been reached so control passes from step S162 to step S164 and then to S166 where a checksum is calculated for the stored candidate number using Luhn's formula. Control passes to decision step S168, where the checksum is asked.

If the checksum indicates that the candidate number is not a valid credit card number then control goes back to step S162 where the next potential credit card number is extracted from the data. If a second credit card number is not found, then the end of the file is reached and control passes to step S178 where transmission is allowed to continue, and then to step S180 where the module exits.

On the contrary, if the checksum indicates that the candidate number is a valid credit card number then control passes to decision step S170 where the policy data scenarios are interrogated for the appropriate action to be taken. The action can be determined from factors such as the number itself, the identity of the user transmitting the number, and the address to which it is sent. Policy data can for example specify that credit cards are not transmitted, or that a higher encryption strength is required for transmission before it can proceed.

This stage of policy checking allows credit card transactions to be monitored at a higher level than the user making the transaction. In this way financial decisions can be easily and quickly implemented and can be automatically enforced without the need for monitoring. An agency may, for example, wish to restrict the ability to carry out credit card transactions on the organization's account for particular authorized people or it may wish to completely restrict transactions on a particular account.

In step S170, the credit card number and other details of the transaction are compared to the setting of the policy file and it is determined whether or not transmission takes place. If for some reason, with reference to the policy checks, it is determined that the credit card number should not be transmitted, control passes to step S172 where the transmission of the data is stopped, and then to step S174 where the module comes out. At this point the system could notify the user that the request has been denied by means of a message box at an associated lead. Control then returns to point A in Figure 3, in the case of a web browser, or to step S132, "compose mail" in Figure 5, in the case of an email client.

If in step S172, it is determined that the credit card number can be transmitted, control passes to step S176 where data transmission occurs, and then to step S180 where the module exits. In this case control resumes from point C in the operation of the Web browser illustrated in Figure 3, or from point B in the operation of the email client illustrated in Figure 5.

The credit card numbers need not only be identified in step S162 by scanning the content of the transmission. In implementations of the Web browser, the credit card number can, for example, be identified directly by referring to the names of the fields of any of the variables to be transmitted or also from the representation of the Web page in memory. The previous discussion about identifying passwords explains this in more detail.

The preferred system can also be configured to search the outgoing transmissions for other pertinent financial details, such as account numbers. The company account numbers from which you pay can be deposited or stored in a separate file. Any probable character or digit strings can then be extracted from the output data as described and compared with the entries in the account file to determine whether it is a valid account number or not. The transaction can then be allowed to proceed or be rejected as described above. Although we have referred to credit card numbers, it will be appreciated that any type of card number can be used to make payment, such as debit card numbers.

Also, although the identification of credit card numbers has been explained with reference to the data being transmitted, it will be appreciated that similar techniques could be used to identify and extract credit card numbers from the transmissions being received.

Authentication and Validation Support

Online transactions typically require some form of authentication that the user is who they say they are, and that they are able to pay for the items ordered. These requirements are usually met by the buyer

ES 2 299 666 T3 supplying the merchant with their credit card number and the cardholder's address which can then be verified by the seller with the card issuer. However, more and more Digital Certificates are attached to electronic transmissions by the user which, together with a digital signature, allows the receiver to verify that the transmission originated from the person called as the sender. The digital certificates of certain issuing authorities, such as Identrus, can also act as a guarantee that the holder will fulfill his payment commitment for the specified amount of money. These certificates are useful with online trading.

Digital signatures are a widely used means of establishing the identity of the individual online when transmitting information or when conducting a transaction. They also provide an assurance to the recipient that any transmitted information or transaction details, that those details and that information have not been falsified by routing by an unauthorized third party.

Digital certificates are issued to individuals, organizations, or companies by independent Certification Authorities such as Verising Inc. An organization can act as its own Certification Authority by issuing its own digital certificate that may or may not be derived from an issued "root" certificate. by another Certification Authority. A digital certificate typically contains the name of the holder, a serial number, an expiration date, a copy of the certificate holder's public key, and the digital signature of the authority issuing the certificate. A private key is also issued to the certificate holder that he must not reveal to anyone else.

The certificates are unique for each holder and can be revoked by the issuer if the holder is no longer viable; alternatively, a holder can ask to have it revoked if the private key has been compromised.

The public and private keys can also be used in tandem to encrypt or decrypt a message. No one can use the certificate holder's public key to encrypt a message so that it can only be read by the certificate holder after decrypting the message with their private key.

Messages can also be digitally signed using software that converts the contents of the message into a mathematical summary, called a fingerprint. The fingerprint is then encrypted using the sender's private key. The encrypted fingerprint can then be used as a digital signature for the message being transmitted. The original message, the digital signature and the digital certificate of the transmitter are all sent to the receiver who, to confirm that the received message is complete and unaltered in its original form, can also produce a fingerprint for the received message. If the received fingerprint, which has been decrypted with the holder's public key, matches the fingerprint produced by the receiver, then the receiver can trust that the message that has been sent by the person to whom the certificate was issued, and that the message has not been altered along the way from its original form. Digital certificates are therefore of considerable importance and on the rise for companies conducting business over the Internet.

In cases where the online merchant makes use of Digital Certificates to ensure the identity of its customers, it is necessary to verify with the issuer that the certificate is valid even before any transaction is authorized. Such checks can be performed online using an independent verification service such as that provided by Valicert, Inc. There is usually a charge for such services.

It may be that individual employees of an organization each receive emails from a unique client, each signed with their digital certificate, on separate occasions. Currently, there is no way for information about a certificate received by an employee to be shared with another employee unless they share it manually, and as a result, individual employees can request that the same certificate be validated each time. receive. This is however uneconomical, since once a certificate is revoked by its issuer, it is never reinstalled again, so that any validation fee expense on an already revoked certificate is unnecessary. Additionally, the recipient may wish to make a business judgment as to whether a previously validated certificate should be re-checked or not. For example, if a digitally signed order for $ 1 million is received one day, and the certificate is successfully validated, and another $ 50 order is received the next day, signed with the same certificate, the organization you may consider a second validation check unnecessary, thereby saving the validation charge.

The preferred system provides a means to record information about the Digital Certificates that have been received, the status of the certificate at the last check as well as, where applicable, transaction information such as customer, quantity, date, articles and so on. This information is stored in a central database to which all users of the system have access. The preferred system also provides a means of using the stored information to decide whether or not a validation check is desirable, and to accept or reject transmissions depending on the status of the digital certificate. In this way, users of the system can receive and review transmissions without having to establish their authenticity themselves.

Figure 9 illustrates the operation of a preferred system expansion module implemented to extract digital certificates from transmissions received by company employees and record them in a database along with their validation status and details of any associated transactions such as date, quantity, items and so on. The module first checks to determine if the certificate is obviously invalid, and that the message was correctly signed by it. The certificate is obviously invalid, for example, if it has passed its expiration date, or if it contains an invalid “fingerprint”. Such a fingerprint can be

ES 2 299 666 T3 a checksum, for example, for the certificate itself. The message has not been signed correctly if the signature cannot be verified from the information contained within the certificate. The details of certificate validation and message signing are more fully described in the ITU and RFC documents referenced above. The module then performs a check to determine whether the certificate has already been stored in the database or not and only records those that are not. When a copy of the certificate is already stored, the module checks the database recording to determine if it was previously identified as revoked in which case the transmission is rejected immediately. Otherwise, the module then determines, in accordance with the directives that define the business rules, whether or not to validate the certificate. Taking into account the results of such validation, it then determines whether the certificate should be trusted, and therefore whether the transmission signed by the digital certificate should be rejected or accepted. The module starts in step S190, following the receipt of the data containing a digital certificate. Digital certificates are typically transmitted as attachments to messages and can be identified by examining the first few octets of bits in the attachment header. These bit octets identify the type of file attached and thus indicate whether an attachment is a digital certificate or not.

The initiation step S190 occurs after point A in Figure 3 if the module is implemented in a web browser, and after point A in Figure 5 if the module is implemented in an email client. Following initialization, the module proceeds to step S191 in which the expiration date of the certificate is checked, and the confirmed digital signature with which the message has been signed. If the certificate has expired, or the message is incorrectly signed, the module proceeds to step S198 and rejects the transmission. Otherwise the module proceeds to step S192 in which a previously received copy of the digital certificate is searched in the database. Control then proceeds to step 194. If a copy of the certificate has been found in the database then control passes to decision step S196 where the module determines if the certificate has previously been marked as revoked. This will have occurred if a previous validity check revealed that the certificate had been revoked. If the certificate is not already in the database control passes from step S194 to step S202 where the new certificate and the date it was received are stored in the database, along with additional details such as the address. from which it was sent and details of any transactions associated with the transmission such as the monetary value, account number etc. If the certificate has already been marked as revoked in step S196 then control goes directly to step 198 in which the transmission comprising the digital certificate is automatically rejected. This may involve, for example, transmitting an automatically generated message to the initiator of the transmission whose certificate has been found invalid to explain the rejection, and to prevent the recipient of the digital certificate from taking into account any additional steps in connection with the rejected transmission. The module then exits in step S200.

However, if the certificate has not previously been marked as revoked in step S196, then control proceeds to step S204 in which the history of the transmissions signed by the certificate, by other certificates of the same company, are considered, or used to direct transactions on the same account are considered with the policy data to determine if an online certificate validity check is required. Control also passes to step S204 after a new digital certificate has been added to the database in step S202.

Policy data contains instructions that when considered together with the history of previously received signed transmissions and previously performed revocation checks indicate whether or not the certificate used to sign a transmission should be verified at this time. An example of policy data is illustrated in Figure 10 to which we will refer.

Policy data is stored on the AcceptanceClassificationTrust branch of the DigitalCertificates branch of the policy data representation. The branch of AcceptanceClassificationTrust is subdivided into two separate branches that deal individually with “monetary” digital certificates, where a certificate has been used to sign a transmission that involves a transaction with the receiver for an amount of money, and the digital “identity ”That do not involve a monetary transaction with the receiver of the transmission. Certain certificates are issued only for use in conjunction with monetary transactions. For example, the "guarantee certificate" issued by some online banking organizations, such as Identrus, as a guarantee for the signed transmission receiver. Such a guarantee certificate testifies that the sender of the transmission is a customer of a member bank of Identrus, and that if he does not make the payment, the bank will accept responsibility.

Organizations that issue different types or classes of digital certificates mark each certificate according to its class. Identifying a certificate as of a particular class is then a matter of understanding how different organizations classify their certificates and looking for the appropriate indicator in the certificate received.

Users of digital certificates can provide many kinds of certificates adapted for different purposes. These can be dealt with separately with the policy data by the corresponding sub-branches of the policy data tree.

In the policy example, the first branch titled “Identity Certificates” deals with transmissions that do not involve a monetary transaction. The branch comprises four separate sub-branches. The first of these, titled “AlwaysAccept” contains a reference to a table, the “a” table that lists the names of individuals and organizations that are considered trustworthy. The names listed in this table will all be known and trusted implicitly.

ES 2 299 666 T3 by the company, for which it is not considered necessary to determine whether or not a digital certificate has been revoked by its issuer.

The second branch titled “AlwaysCheckFrom” contains a reference to a separate table, table b, in which the names of individuals and organizations for which digital certificates should always be verified are stored. Clearly, the contents of table a and table b will depend on the user's experience of the preferred system and will be left to the user to enter.

The third branch entitled "CheckYesFundaysReceivedCertificate-FromCompany" specifies a period of time that follows the receipt of a valid digital certificate from a company, within which the checks of any additional certificates received from that company are not considered necessary. In this case, the time period is set to 10 days.

The fourth branch entitled "CheckIfDaysFromThisLast Certificate-Received" specifies a similar time period in the case of an individual digital certificate. In the example shown, the policy data specifies that validity checks on any given digital certificate only need to be done every 30 days. Again, the number of days specified on any of these branches is left to the user of the preferred system to decide. The amount of time that has passed since a valid digital certificate has been received can be determined by referring to the digital certificates and associated data stored in the database. Checking digital certificates periodically, better than every time they are received, saves money spent to make checks. The Monetary Certificates branch also contains an AcceptAlwaysFrom branch and anAlwaysCheckOf branch which refer to tables x and y respectively. Table x lists all organizations and individuals for whom a digital certificate health check is not required; the table and lists all the ones that will always require a check.

The Monetary Certificates branch also contains a branch of CheckIfAmountExceeds that specifies a threshold for the amount of the transaction above which all digital certificates must be verified and finally a branch of YesRecentlyChecked that sets two conditions to perform checks on a digital certificate that has been verified. recently received and validated. The IfRecentlyChecked branch allows the user to specify which certificates received for transactions for a small amount, in this case $ 5,000, received within a specified time, in this case 30 days, of a previous revocation check, does not need validation.

Figure 11 illustrates the expansion module process that interacts with the policy data shown in Figure 9. This process is a sub-process of the one shown in Figure 8 and occurs in step S204 resulting in decision step S206 in the which the expansion module determines whether or not to perform an online check of the status of the Digital Certificate that has been received. The sub-process begins in step S220 from which control passes to decision step S222 in which it is determined whether the transmission is monetary from the kind of Digital Certificate used to sign the message. If the transmission is monetary then control flows to decision step S232, which is the first in a chain of decision stages corresponding to the branches in the MonetaryCertificates branch of the AcceptanceClassificationTrust branch of the policy data.

If in step S222, it is determined that the transmission is non-monetary, control passes to decision step S224, which is the first decision stage in a chain of decision stages corresponding to the Branches Identity Certificates Acceptance Classification Trust of the branches. policy data. In each of the decision stages in the chain, a simple check is made to see if the conditions specified on each of the sub-branches of the Identity Certificates branch of the policy data are satisfied. Depending on the results of that check, control flows either to step S242 in which trust in the Digital Certificate is established and no on-line checking of the status of the Digital Certificate is deemed necessary, or to step S244 in which no establishes trust and an online check is deemed necessary, or to the next decision stage in the chain.

Thus, in step S224, in which it is determined whether the sender of the Digital Certificate is listed in table a, which is the "AcceptAlwaysFrom" table, if the sender of the Digital Certificate is listed in Table A then the control flows from decision step S224 to step S242 where trust in the Certificate is established and the thread ends up returning to step S208 in Figure 8. If the sender is not listed in table a then control flows from step S224 to the next decision stage in chain step S226 in which it is determined whether the sender of the Digital Certificate is listed in table b, which is the "AlwaysCheckOf" table. Similarly, if the sender is listed in this table control flows to step S244 in which an on-line check of the status of the Digital Certificate is deemed necessary. Control returns from step S244 in the thread to step S210 in Figure 8.

If the sender of the Digital Certificate is not listed in table b then control flows from decision stage S226 to the next decision stage in the chain representing the next condition listed as a sub-branch listed in the policy data. Thus, in decision step S228 a check is made whether this Digital Certificate has been validated in the last 30 days. This will involve searching the Digital Certificate in the database of stored Digital Certificates and extracting from the stored information the date on which the Digital Certificate was last checked. If the status of the Certificate has been verified in the last 30

ES 2 299 666 T3 days, control flows to step S242 where trust is established. If the information in the stored Digital Certificate database indicates that the Digital Certificate has not been verified in the last 30 days then control flows from step S228 to step S230 where a check is made to see if it is successful. have received another Digital Certificate from the same company and if that Digital Certificate has been verified within the last 10 days. This determination again involves checking the database of stored Digital Certificates and the information related to those Digital Certificates. If the other Digital Certificate has been checked in the last 10 days then control flows to step S242 where trust in the received Digital Certificate is established. If not, then control flows to step S244.

In the case of a monetary transmission, the conditions set on the policy data are set through decision steps S232 to decision step S240. If in the decision stage S232 the sender of the Digital Certificate is listed in table x, which sets the names of the companies and organizations for which the verification of the status of the Digital Certificate is not considered necessary, then trust is established and control proceeds to step S242. Otherwise control passes to the next decision stage in the chain which is decision stage S234. In the decision step S234 if the sender of the Digital Certificate is listed in table b, that is the Table "Always CheckOf", then trust is not established and control passes to S244. Otherwise, control passes to decision step S236, where it is determined whether the amount for which the transaction is being performed exceeds $ 10,000. This determination is made with reference to the signed transaction data that will contain the monetary amount or in a manner predetermined by the issuer of the certificate, or contained within the associated email (s) that make up the transaction (s). If the transaction is found to be for an amount in excess of $ 10,000, or if the transaction amount cannot be determined with a reference to the transmitted data, then trust is not established and control proceeds to step S244. Otherwise the trust to the decision stage S238 in which it is determined if the Digital Certificate has been verified within the last 30 days. Again, this determination is made with reference to the database of stored Digital Certificates and the data related to Digital Certificates. If the certificate has not been verified within the last 30 days then trust is not established and control proceeds to step S244. If it has been checked, then control proceeds to decision step S240 where, if the previously determined amount of the transaction is estimated to be above $ 5,000 then trust is not established and control proceeds to step S244. If the amount of the transaction is below $ 5,000 then it is classified as an acceptable risk to trust the Digital Certificate, trust is established and control passes to step S242.

These last two conditions allow the system to determine whether to check the status of the certificate based on the recent history of operations. If, for example, a transaction is about to be made by one party for a modest sum, that is, below $ 5,000, and a search for the recorded transaction and certificate details reveals that fairly recently, the same party made a transaction and at that time your digital certificate was confirmed as valid, then it is debatable that checking the validity of the party's certificate again so soon after the first one is unnecessary, And it is preferable to trust the party than to pay the validation fees a second time.

It will be appreciated that the instructions in the policy file may be set to reflect the level of trust the company has in its customers and suppliers, based on the experience of individuals within the company, the amounts of transactions deemed permissible. without significant risk and so on. The policy file can also be set to implement more general policies to be used in conjunction with a recording of the transaction details for the digital certificate holder. For example, any transaction that is offered by the holder can be compared to the recording of those that they have made previously to see if the quantity and the requested items or services are maintained with their business history. If they are not, then it may be desirable to check the validity of the certificate to confirm that it is still valid and that it guarantees the identity of the sender. If it has been revoked, then a third party may have acquired the private key from the original holder and be attempting to conduct fraudulent transactions.

After the policy data is checked in step S204, trust in the digital certificate will be established or it will not be established. In decision step S206, if trust has been established then control passes to step S208 in which the transmission containing the transaction is accepted. Control then goes to step S200 where the module exits and control goes back to point A in Figure 3 in the case of a web browser, or to point A in Figure 5 in the case of a mail client. electronic.

If in step S206 the trust in the digital certificate is not established, then control goes to step S210, where an online validation check is performed on the digital certificate. This may involve a check to see if the Digital Certificate has been revoked or if, in the case of an electronic commerce transaction, the issuer of the Digital Certificate confirms a guarantee for the amount promised in the transaction. Control then proceeds to step S212 in which the validity status stored in the database for that certificate is updated. Control then proceeds to step S214 in which, if the certificate was found invalid, control proceeds to step S198 where the transmission is rejected, or to step S208 where the transmission is accepted. Rejection of the transmission may mean that it is cleared from the e-mail recipients box before it is opened, or that the transmission is marked with the word "rejected" or some other indicator. Following either step S198 or S208, control passes to step S200 where the module exits. Each time a transaction is allowed to occur, the database is updated to include information about the transaction, such as the date and amount, so that the information can be used in determining the need for future verification checks. validation.

ES 2 299 666 T3

Information recording

The preferred system also provides an automatic mode in which transaction information is recorded for transactions performed online. In this context, the word "transaction" and "electronic commerce transaction" are intended to mean an agreement promising money or money value made between two parties over the Internet, or even over the same company network. Normally, the user himself is responsible for maintaining the transaction information by making hard copies of the relevant electronic records or by actively storing copies of any electronic recordings in files on his computer. Relying on manual methods to ensure these recordings remain clearly unreliable and labor intensive.

The preferred system on the contrary scans the information content of all communications processed by the system for indications that a transaction has started or is taking place. Such indications are numerous. The simplest is whether the link is secure or not as most web pages negotiate a secure link before making a transaction and close that link later. Determining whether a link is secure is achieved by examining the URL of the destination web page. A secure link is indicated by an "s" after the "http" prefix. Thus, a preferred system mode of operation is to record all data transmitted to the web page while the link is secure. The preferred system also keeps a recording of the Web pages that negotiate the secure links but that are not e-commerce sites, that is, those that are connected to another that make purchases, and do not record any data transmitted to these pages. Such a web page may be Microsoft's Hotmail web page that provides an e-mail service.

Another indication can simply be the URL of the site. In this case the preferred system can be configured to record all data transmitted to the website that has been identified as that of an online trading company. Other indications could be an identified credit card number, an electronic receipt, an email confirming the sale, the use of a digital certificate, in particular a digital guarantee certificate, or a purchase code.

Once it has been identified that it has occurred, the preferred system can record the details of the transaction both by fully storing each communication between a user and the identified merchant, as well as by scanning the transmissions and extracting the particular details, such as date, amount, type of items, quantity and so on.

Recording of transaction data can be stopped when the end of the transaction is identified or after a predefined number of transmissions have taken place between the buyer and the merchant. Similarly, once a transaction has been identified, the preferred system may write to the database a predefined number of cached transmissions that occurred immediately after the first acknowledged transmission of the transaction.

This will be useful, for example, when the first indication that a transmission is taking place is the detection of a credit card number or an electronic receipt, as these are likely received very late in a transaction. Previous transmissions may, for example, consist of web pages containing information regarding the items or services being purchased, or an email exchange where the specification or terms of supply are agreed. Note that it is perfectly possible for previous transmissions to be of the same type as those in which the transactions were detected, of a different type, or to be a mixture of types. For example, a user could visit a website www.abc.com, obtain details of items, and then order them in an email sent to orders@abc.com.

The preferred system records the details of the transaction in a common centralized database 42. Additionally, the database may be a local file or a service on the network. The information stored in the database can be encrypted using known encryption techniques so that only a person with the necessary authorization can access it.

Figure 12 is an illustration of the operation of an example implementation of a module to identify when an electronic online transaction is being conducted. Figure 14 illustrates the process by which the preferred system records an identified transaction in the database, and Figure 15 illustrates how the preferred system allows an identified transaction to be approved or rejected based on predetermined approval policies.

With reference to Figure 12, the operation of a module to identify when an online transaction is occurring will be described below.

The module begins operation in step S250 in response to a reception of data or in response to an initiation by the user of a transmission of data to the remote site. In the case of a web browser implementation this will be after point A or after point C respectively as shown in Figure 3; in the case of an email client implementation it will be after point A or B respectively as shown in Figure 5.

Control then proceeds to decision step S252 in which it is determined whether, in the case of a web browser, a secure link has been negotiated between the site transmitting the data and the site receiving the data. This can

ES 2 299 666 T3 can be achieved by asking for the address of the URL to which it has been connected, as mentioned above, or by interrogating the web browser to see if encryption is being used. In the case of an e-mail message this step is skipped and control passes directly to step S260. As online web browser transactions usually involve the transmission of personal information, such as name and address, credit card number or other information that identifies the account, secure links are usually negotiated as a matter of course. Thus the presence of a single secure link is a good indication that a transaction is taking place. However, secure connections can be negotiated for reasons other than the transmission of transaction details. Thus, if in step S252 it is determined that the connection is secure, control passes to step S254, in which the address of the remote site to which the connection has been made is checked against a list of known sites that they do not provide facilities for directing online transactions but they do establish secure connections. Search engines based on email sites, an example of which is Microsoft's Hotmail site. Control then proceeds to decision step S256 where a determination is made based on the above check. If the site address is identified as a non-e-commerce site, this is one that does not facilitate transactions, then it is determined that a transaction may or may not be occurring and control passes to decision step S260 to perform additional checks on the content of the transaction. If in step S256 the site address is not identified as a known non-e-commerce site, then it is assumed that an online transaction is taking place, and the module exits in step S258.

If it is found that a secure connection has not been established in step S252, or if the secure connection has been established but to a known non-e-commerce site, as determined in step S256, or the transmission is an email, then control passes to decision step S260. In decision step S260, the first of several checks is made on the content of the transmission to determine whether or not it is part of a transaction. In step S260, the transmission is scanned to see if it contains a credit card number. The method for doing so has been described with reference to Figure 8. If a credit card number is found in the transmission then it is assumed that a transaction must be occurring and control passes to step S258 in the transmission. which the module comes out. If no credit card number is found then control instead passes to decision step S262 where the transmission is scanned to see if it contains an account code. The account codes can (for example) be stored in a separate file that is accessed by the module when this stage is carried out or, alternatively, an account number can be identified from the descriptive data in the transmission such as a field name such as " Account Number ”or similar characters appearing in the text of a message.

If an account code is found in decision step S262, then the transmission is assumed to be part of a transaction and control passes to step S258 where the module exits. If no account code is found then control passes to step S264 where, in the case of a Web browser, the URL is compared with a list of known e-commerce URLs stored in a file or database. decision step S266, a determination is made on that comparison. If the URL is found to be a known e-commerce page, or within a known set of e-commerce pages, then it is determined that an e-commerce transaction is taking place and control passes to step S258 where the module exits. . Similarly, in the case of an email, the destination address can be compared against a list of known e-commerce email addresses, for example "orders@abc.com" and if a match is found then it is determined that an electronic commerce transaction is taking place and control passes to step S258 where the module exits.

The checks that have been described are only representative of the possible checks that can be performed to determine whether or not a transmission is likely part of an electronic commerce transaction and are not intended to be exhaustive. Also, the order in which the checks have been illustrated has no special meaning. The order simply depends on the structure of the policy data as will be seen from the reference to Figure 13.

At step S268, a general check is illustrated representing any additional checks for an indication of a transaction, in addition to those described above, that a company decides that it is desirable to employ, in addition to those described above, such such as searching for purchase codes or embedded codes located in the data. It is preferable that the web browser or email client being used in the preferred system allows the user to mark transmissions with an embedded code to indicate that the transmission is part of a transaction and should be recorded. Also, the embedded code could be placed in the data by the website or email client that transmits some of the transaction data to the user's workstation.

Control passes to this stage after step S266, if the site is not recognized as a known e-commerce site and if such a transaction indicator is found in step S268, then it is estimated that a transaction is taking place and the control goes to step S258 where the module exits. If in step S268, no such indicator is found then it is judged that a transaction is not taking place and the module exits in step S258. Following the output, the data can be transmitted, following points C and B respectively in Figures 3 and 5, or processed following from its reception at point A in Figures 3 and 5.

In the example described, the objective is to start recording the transmissions and possible details of the transactions if there is only a suspicion that a transaction is taking place. It is assumed that recording data that is not part of a transaction is preferable to not recording a transaction at all. Figure 13 is an illustration

ES 2 299 666 T3 of policy data used to identify that an electronic commerce transaction is taking place and to control how the transaction data is recorded. Policy data is represented by a Transactions branch of the policy data tree which is subdivided into two separate sub-branches called "Identification" and "Termination". The Identification branch is in turn divided into five sub-branches that correspond to the determinations made in the process illustrated in Figure 12. The first of these sub-branches is entitled "SiConecciónVaASegura" allows the user to specify if the recording should start. when the expansion module detects that the connection to the web server has been made secure. The conditions specified on this sub-branch correspond to decision step S252 shown in Figure 12. It will be appreciated with reference to Figures 12 and 13 that the control flow shown in Figure 12 corresponds to the distribution of the conditions specified in the branches of the policy data tree shown in Figure 13. The Excluded Sites branch of the branch IfSecureVaConnection contains a reference to the table q in which Web sites known to negotiate secure sites but known as non-e-commerce Web sites are listed. Table q refers to step S256 of the process shown in Figure 12.

The next sub-branch of the identification branch is titled "SiNumberCarjetaCréditoPresente" and allows the user to specify whether the detection of a credit card number should or should not be used to initiate a recording of the data that is being transmitted or received. This sub-branch corresponds to decision step S260. The PreviousPages sub-branch of the IfPresentCreditCardNumber branch lists the number of Web pages, prior to the Web page on which the credit card number was detected, that must also be recorded. Since credit card numbers are normally sent at the end of a transaction, the provision of this sub-branch enables previous web pages that likely contain the transaction details and request to be retrieved and stored. These web pages are continuously cached by the preferred system so that if a transaction is identified they can be retrieved from the cache and stored in the database. This will be explained in more detail with reference to Figure 14.

The next sub-branch of the Identification branch of the tree is titled “IfCodeAccountPresent” and allows a user to specify whether or not the detection of an account code in the data being transmitted or received will be taken as an indicator to start recording. of the data. The account codes are identified in step S262 shown in Figure 12 with reference to table r. The reference to this table is contained in the AccountCodes sub-branch of the IfPresentAccountCode branch. Note that this table also shows the number of pages prior to recording, in a similar way to that described above for identifying a credit card, however in this case the number of pages prior to recording is stored in table r allowing a different number of pages to specify for each account code detected.

The KnownCommerceSite branch allows the user to specify a list of URLs corresponding to sites, parts of sites, or even single pages, where e-commerce transactions are known to take place. The URL of the current page is compared against the entries in this list to determine if a transaction is taking place. The Known Sites sub-branch contains a reference to the table s in which the URLs of known e-commerce sites are stored. Determining whether the URL of the website is a known e-commerce site is made in decision step S266 which follows step S264 of Figure 12. Finally, the IfOtherIndicatorPresent branch provides a way for the user to specify whether or not the determination of other flags should be used as a starting point for data recording. The two sub-branches of this branch titled Keywords and Previous Pages specify possible indicators that can be detected in this case the keywords listed in table t, and also the number of previous pages that are required to be stored if the keywords are detected.

The Termination branch of the Transactions branch is divided into four sub-branches that specify the conditions to be used to terminate the recording of data being transmitted or received. Each of the sub-branches sets a condition by which the end of the transaction can be defined. The first branch titled "SiConensiónVaAInsegura" allows the user to specify that the resignation of a secure connection by the web browser indicates the end of the transaction so that the recording can be stopped. The other sub-branches specify that when the website changes the recording can be stopped, if a digital receipt is received the recording can be stopped and after receiving 20 web pages following the identification that a transaction is taking place the recording can be stopped.

It should be emphasized that the policy data shown in this particular diagram, but also other diagrams, is unique to each user. A user can not only specify if particular conditions should act by setting the Yes or No variable accordingly, or by changing the number of pages to be recorded for example, but also the structure and arrangement of the branches and the conditions specified on those branches can be different from user to user. It will be appreciated that although the example directives describe recording transactions in a web browser environment, similar directives would control the email environment, bypassing the secure connection option, but allowing the directives to be defined to record emails over the detection of credit card numbers, account codes or other identifiable information within them, or when emails are sent to known e-commerce addresses.

The full benefit of the method for identifying a transaction is realized when the method is used in conjunction with means for recording transmissions between a user of the preferred system and a remote site. This allows a recording of all transactions carried out by a user to be saved and maintained automatically. The recordings

ES 2 299 666 T3 can be kept up to date without the need to make paper copies of each transmission transmitted or received. In this way, the record keeping of a company is made considerably easier and more accurate.

Figure 14 illustrates the operation of a module to record the transmissions that comprise a transaction. The module starts at step 270.

If the module is implemented as part of a web browser, step S270 starts at point A in Figure 3 after receipt of the data or after point C in Figure 3 directly prior to data transmission to the site. remote. If the module is implemented as part of an email client, step S270 occurs after point A in Figure 5 after an email has been received or after point B just before an email composed of the user is sent to a receiver.

Following step S270, control passes to step S272, in which the check to identify a transaction, described above with reference to Figure 9, is performed and a determination is made as to whether a trade transaction is occurring. electronic or not. Control then passes to step S274 where, if it is determined that a transaction is not occurring, control passes directly to step S276 where the module exits.

If it is determined that a transaction is going to occur then control passes to step S278 in which the directives are consulted against one or more detection means, the identification of the sender, the amount of the transaction, or other parameters to determine what previous broadcasts, if any, should be stored with the identified broadcast, and in how much detail the broadcast should be recorded. The directives could, for example, require that a transaction involving a large sum of money be recorded in more detail than a transaction involving a small sum. An example of this operation could be to record each Web page accessed while recording on an online merchant's Web site for transactions involving large sums of money, but only record the transmission that contains an electronic receipt for transactions for large amounts. smaller.

Just as the amount of data to be stored is determined, the directives file also determines the nature of the data to be recorded. The entire stream or web page can be recorded as a series of snapshots of the transaction, in the same way that web pages are cached for example, or alternatively, individual elements can be extracted from the stream or web page of data, such as the date, the identity of the merchant, the quantity and so on, and stored either by themselves or together with the data of the snapshot.

In this way, memory can be used for storage more efficiently to ensure that the most important transactions have enough space to record. The amount of transaction data to be recorded may also depend on the identity of the merchant, the geographical location, the history of trade with the user's company, and the items and services on offer.

In Figure 13, the sample policy data shows a simple scenario in which the amount of data to write is specified in terms of the number of Web pages that are retrieved from the pages in the cache. The numbers differ depending on whether a credit card number, an account code, or a keyword is identified. Furthermore, table r shows that with the recognition of different account codes the number of pre-stored web pages could be different, reflecting the relative importance of the account.

Extending this simple case to a more sophisticated one can provide a higher level of detail in the policy data. Additional branches to the policy data tree could specify the individual company or name, or specific keywords relating to items and / or services; also the amount of data to record depending on these keywords and names.

Also, the tables could be expanded to refer to the number of different types of data to be stored. Data such as the name of the company, what it is selling, the quantity and so on could be extracted from the text of the email, from the HTML text that defines the web page, or from the DOM representation of the web page and stored in the database.

All web pages or cached information can be retrieved, or alternatively the system can retrieve only the pages that have details in common with the page initially identified as part of a transaction.

Alternatively, a list of all stored messages may be presented to the user for the user to manually select the transmissions that are related to the identified transaction.

Following the determination of how much data is recorded, control passes to decision step S280. In step S280 if the previous transmissions are to be stored, control passes to step S282 where the transmissions stored in the local cache are retrieved. In the case of a web browser, this can be a set number of previous pages, as described above. When the transition was detected in a web browser, policies can also dictate that it search the cache for previous email messages related to the transaction, for example sent to or received from the same organization. This can be determined by doing

ES 2 299 666 T3 match portions of the search engine URL with portions of the email address. Similarly, transactions detected in email messages can cause both older emails and older Web pages to be retrieved from the cache. Control then proceeds to step S284 in which the identified transaction and any previous retrieved transmissions are stored in the system database 42.

In step S280, if the above transmissions are not required, control passes directly to step S284 where the transmission identified as a transaction is recorded in the system database. At the same time that the transmissions are stored in step S284, relative data such as the identity of the user, the amount or the other party for the transaction can also be recorded in the system database to form a complete recording, although this will depend of the directive data instructions. Control then passes to S286 and the module exits.

Continuing from step S276 after the module exits, the data can be transmitted, following point A in Figures 3 and 5, or processed following its reception at points C and B in Figures 3 and 5 respectively.

Once the transmission has been identified as taking place, all transmissions between the user and the other party can be recorded until the system detects that the transaction has been completed. Detecting the end point of the transaction and stopping the recording can be done in a manner similar to that described above to identify whether a transaction is taking place. The simplest implementation is to record the transmission information until an electronic receipt or shipping order is received. Alternatively, the recording of transmissions can be made to stop after a predetermined number of transmissions have occurred between the user and the other party, or if a certain amount of time has elapsed since the transaction was identified.

Transmissions can be made simpler if every time the user changes the Web site the cache is flushed. This keeps the memory required for a low cache, as well as a reduction in the number of previous transmissions that need to be searched if search techniques are employed.

It will be appreciated that the methods described above can also be used to record associated transmissions that occur after a transaction is detected and recorded. For example, a transaction made using a web browser will typically be followed by a confirmation email sent from the sender to the buyer. This email can be detected as part of the transaction, as it will contain common characteristics, such as the order number, account number, description of the items, price, etc. It can also be sent from an address similar to the website address, for example “customer service@abc.com” when the original website used to make the purchase was “abc.com”. Preferably a time element is used so that only subsequent transmissions occurring within a given time period are considered to be associated with the original transaction.

In addition to recording transaction information, it may be advantageous to record other information that management provides with the ability to analyze the behavior of its users, for example to ensure that the organization is in effect obtaining a real productivity benefit from its adoption of commerce. electronic. Such information is not limited to the productivity of the user himself, but of all the processes, allowing for example a comparison of the purchase websites to determine which are the most effective in terms of the purchase process, and therefore which will be the most effective. greater benefit by reducing purchase costs. The preferred system provided for this records additional information, such as the amount of time a purchase takes, the number of keystrokes and mouse clicks required to complete a purchase, the amount of "wait" time while the user waits. to download the pages or receive a response. This information can be recorded with the recording of the transaction in the database, allowing statistical analysis over a range of transactions.

The time it takes for a transaction can be determined by associating a timestamp with each of the received transmissions. When the transaction is determined to be complete, the timestamp associated with the first transmission (which may have been retrieved from the cache in step S282) is subtracted from the timestamp associated with the last transmission, and the result, which will be the duration total of the transaction is stored in the database in step S284. Alternatively, the first and last timestamps could be written to the database and the transaction duration calculated later. The number of keystrokes and mouse clicks can be determined on a Microsoft Windows-based system using standard Windows hooks within the operating system. Such techniques are more fully described in the document "Win 32 Hooks" by Kyle Marsh of the Microsoft Network Technology Developers Group, dated July 29, 1993 available on the Microsoft Corporation Web site (http: // msdn.microsoft.com/library/default.asp? url = / library / enus / dnmgmt / html / msdn_hooks32.asp).

The preferred system maintains counters for the number of keystrokes (using the WH-KEYBOARD hook) and mouse clicks (using the WH-MOUSE hook) that occur between every two received transmissions, these totals associated with the received transmission. Keystrokes and mouse clicks that occur while another application is focused (for example, if the user temporarily switches to another application) are ignored. When the transaction is determined to be complete, the total keystrokes and mouse clicks that occur between the first transmission (which can be retrieved from the cache in step S282) and the last transmission are added together, and the result, which will be the total number of keystrokes and mouse clicks during

ES 2 299 666 T3 the global transaction is stored in the database in step S284. Similarly, Web site transaction response time can be measured by noting the time each outbound transmission request is sent, and then subtracting the time the response is received. Adding the response times between the beginning and end of the transaction will give the total time that the user spends waiting for the website. Similarly, the preferred system also counts user response time, which is the time between receiving a transmission, and the time in which a response is transmitted.

The preferred system also calculates how much of the user response time is invested in entering the data, and therefore allows determining the time required by the user to "absorb" the incoming transmission (which is the difference). The time taken to enter the data is determined by maintaining a "stop watch". The stop clock is reset each time a new transmission is received, and is restarted immediately each time the user enters a keystroke or mouse click. In case the user does not enter a keystroke or mouse click for a predetermined period of time, for example 5 seconds, the system assumes that the user is now absorbing the details of the previous transmission and for the clock. The clock also stops when a keyboard press or mouse click causes an output stream to be sent. Adding the time invested in entering data between the beginning and the end of the transaction will give the total time that the user spends in entering the data about the website. The aggregated times can be stored in the database in step S284 for future analysis.

The preferred system also provides a means to monitor transactions that have been made and automatically suspends the transaction for approval if deemed necessary. This process allows a large company to monitor and control the transactions that are being carried out by its employees using a single set of criteria established in the policy data. Policy data can be suspended each time a transaction is identified to determine if the user is authorized to perform that transaction himself or if he needs to request authorization from a superior in the company. The process is illustrated in Figure 15 to which reference will now be made.

The module incorporating this process is started in step S290. This initiation preferably takes place as soon as all relevant transaction details that need to be considered have been determined, and before the transaction is committed. In the case of an email transaction, details such as items and price typically contained within a single email may be considered prior to transmission of that email. In the case of a Web browser transaction, the existence of the transaction may be detected before all the details are known, in which case initiation does not take place until they are. This usually does not present a problem since the final commit does not occur until very late in the transaction process, or until all the relevant details are known. The detection of the transaction and all relevant details can be determined as described above with reference to Figure 12. Referring briefly to Figures 3 and 5, it will be seen that step S290 occurs after point C in Figure 3 in the case of a web browser implementation, or after point A in Figure 5 in the case of an email client implementation once the required details are known.

Control passes from step S290 to decision step S292 in which the details of the transaction are compared against the policy scenario to determine whether or not approval is required. The determination may be based on the identity of the position of the employee performing the transaction, the amount of the transaction, or the other party to the transaction. In some cases, approval may always be required, such as if the company's CFO wants to review all transactions before they are made.

Figure 16 is an illustration of example policy data that can be used to determine whether or not a transaction requires approval from a third party and also to determine the identity of the appropriate approver to be used. In this case, the conditions in the policy data stipulate whether approval is required depending on the amount of the transaction, and the URL of the other party to the transaction.

The relevant policy data is set on the Transaction Approval branch of the policy data tree. This branch is subdivided into four sub-branches. The first branch is titled “MaxTransaction Amount-Not Approved” and defines a threshold amount for transactions. Transactions for amounts above the threshold must be approved by an approver before being made.

The second sub-branch entitled "Maximum Monthly Amount Without Approval" defines a maximum amount for transactions that a user can perform within a month. In this case, any transaction made by the user that would cause the monthly total to exceed $ 2,500 would require approval by a third party, as well as additional transactions made after that threshold has been reached.

The third branch titled “Excluded Sites” refers to a table containing the websites and email addresses of all the sites that always require third party approval before transaction is made. Finally, the last branch titled “Approvers” refers to a table in which the names of possible third-party approvers are listed. Along with each name is the maximum transaction amount for which that approver has the authority to approve, and a list of excluded sites for which that approver cannot approve a transaction. In the simplest of cases, the approvers will be other computer users registered on the same network as the user who is carrying out the transaction, such as department managers or supervisors. The approvers will be, by the very nature of their role, members of the trading company that assumes and that

ES 2 299 666 T3 has the authority to assume responsibility for the financial transactions carried out by the company. It is also possible that approvers could be drawn from a group of people who are primarily employed in this role, such as people only in the finance department.

If the conditions on the first three sub-branches of the transaction branch tree indicate that such approval is required, an appropriate approver can be found by browsing through the approvers table until an approver whose transaction limit is equal to or higher is found to the proposed transaction and that is not prohibited for approval of transactions on the relevant site.

It will be appreciated that the example policy data shown in Figure 16 is policy data that is specified to a single user of a computer, or group of users, on the network. Other users, or groups, may have different scenarios and different approver lists.

It will be appreciated that the conditions for determining an appropriate approver can be introduced by creating new sub-branches of the policy data tree.

The operation of the approval process could for example be extended to any kind of transmissions, not just those that comprise an electronic commerce transaction. Such an operation can be implemented having the defined conditions or the sub-branches of the policy data that specify user names, addresses or keywords for example that will be identified in the transmission and will be acted upon. Thus, all email transmissions to a particular or individual company may result in an approval being required, or all emails containing predetermined information recognized through keyword identification.

If it is determined in step S292 that no approval is required, control passes directly to step S294 in which the module exits. Following step S294, transmission of the transaction is allowed and the transaction can proceed. Control returns from step S294 to point C in Figure 3 or point B in Figure 5.

However, if in step S292, after consulting the policy scenario, it is determined that approval of the transaction is required, control passes to step S296 in which the details of the transaction are used to determine an appropriate approver. for the transaction. The approver can be a company employee logged into their workstation, or a workstation with a dedicated approver role such as Operator Consoles 44, as shown in Figure 2, or it can even be an automated process. In the case of a large company with several departments, it may be advantageous to have a group of approvers for each department, with each group monitoring the department's accounts. This allows you to reject transactions before they are made, for example if the department management decides that it wants to temporarily suspend purchases, or purchases of a particular nature.

Control proceeds from step S296 following the determination of an appropriate approver to step S298 where an approval request is transmitted to the designated approver through the approval queue of the system 100. Following step S298 control proceeds to the decision step S300 where it is determined whether a response has been received from the approver. At the moment of issuing an approval request a timer is started. If no response has been received in step 300 control passes to step S302 where it is determined by the timer whether or not the waiting period has elapsed. Assuming that the period has not elapsed the control proceeds from step S302 back to step S300 where the system continues to wait for a response from the approver. In this way, steps S300 and S302 form a loop in which the system waits until a response is received or until the time-out expires. In decision step S300 once the response is received, control passes to step S304 in which an action is taken depending on whether the transaction was approved or rejected.

If the transaction was approved, control proceeds from step S304 to step S294 in which the module exits and the transmission is allowed to continue. However if the transmission is not approved then control passes from step S300 to step S306 in which the module exits. The exit in step S306 however prevents transmission of the transaction from taking place and returns the user to point A in Figure 3 in the case of a web browser implementation or to step S132 "compose an email" in the Figure 5 in the case of an email client implementation.

Also, if in step S302 it is estimated that the "timeout" has expired without a response being received from the approver, control passes directly to step S306 in which the module exits.

The right side of Figure 15 shows the stages involved by the approver. The approver process starts at step 310, from which control proceeds to step S312 in which the approver machine searches the system approval queue for any new approval requests. Control then proceeds to decision step S314. In step S314 if no request is pending, control passes back to step S312 where the system queue is interrogated once again. These stages are repeated until an approval request is received or until the approver deactivates the approval process.

In step S314 if an approval request is received, control passes to step S316 in which the approval request is downloaded from the system queue and the approver himself decides whether to approve the request or reject it. The

ES 2 299 666 T3 control then proceeds to step S318 in which the approver's response is transmitted back to the system approval queue and from there back to the users workstation.

Control passes from step S318 back to step S312 in which the system queries the approval queue of the system for new approval requests. It will be appreciated that the approvals process could be fully automated in some circumstances. For example, transactions can be rejected automatically if the company does not have sufficient funds, if they would cause budgeted amounts to be exceeded, or simply if they are above a maximum amount. Such automation could alternatively be provided as part of the user process, so that even the approval request is not made.

To determine whether to approve a particular transaction, the approver should ideally be able to have a complete view of the transaction, for example so that they can see exactly what is being purchased, rather than just summary information, such as total price and price. supplier. The preferred system is provided for this by combining the characteristics of the recording of the transmissions described above, with the characteristics of the approvals. The approval request sent in Step S298 is supplemented with a reference to the location in the database of the transaction information stored in Step S284. The approver receives the location details in step S316 and the system retrieves the transmissions constituting the transaction from the database, displaying them appropriately on the screen so that the approver can consider them in making his approval determination. The operation then continues normally at step S318. It is clearly important that the recording step S284 takes place before the approval request is made in step S298, otherwise the recorded information will no longer be available. Since in step 284 the transaction will have been identified, but not yet completed (since it has not yet been approved), it is necessary for the recording in the database performed in step S284 to contain an indicator that identifies the transaction as "pending". This indicator may be updated in Step S316 to show that the transaction has been approved or denied, or alternatively, if approval is denied the recording of the database may be deleted as the transaction did not take place.

Security

The preferred system provides a means of assigning an appropriate security classification to the transmission depending on the identified nature of the data being transmitted. The assigned security rating can be set by the system user using policy data to reflect their needs.

The simplest implementation of policy data in this case is a list that contains a first column of possible data types, such as employee passwords, employer passwords, credit card numbers, bank details, and so on, and that it contains in a second column, the desired encryption strength (in key bits, for example) that is considered appropriate for each type of data. It will be appreciated that other ways of assigning security levels may be employed depending on the determined nature of the data which may also be employed within the scope of the invention.

Figure 17 shows a sample illustration of the policy data that defines the appropriate encryption strength for various types of data. Policy data takes the form of multiple key value pairs arranged in separate branches of the policy data tree. The key specifies the type of data that is being transmitted such as passwords, credit card numbers, keywords sent, and a general key for any other data sent. The values ​​that correspond to these keys are the strength of the encryption in bits that are considered appropriate for the transmission of the data specified in the key. Key value pairs are arranged over multiple branches of the EncryptionRequiredLevel branch of the TransmittedDataSecurity branch of the policy data tree. Thus, in the example, it can be seen that passwords have a desired encryption strength of 40 bits, company credit card numbers and personal credit card numbers both have a desired encryption strength of 128. bits, the keywords sent have a desired encryption strength of 40 bits and the other data sent does not require encryption.

The SubmittedKeywords branch refers to particular words or strings of characters or text that have been designated as sensitive and require some form of encryption. These can be user names, address information, financial information, or preselected words such as "Confidential or Secret." Submitted keywords can be detected by reference to a table in which they are stored.

In addition, each branch of the policy data can, instead of giving a general encryption strength, refer to a table in which different passwords or credit numbers, for example, are listed together with the corresponding specific encryption strengths for each password or number.

Once a security classification has been assigned, the expansion module interrogates the web browser well to determine the security of the link that has been established by the web browser with the web server for the transmission of that information, or in the case of an email transmission, the encryption scenario that the user or application has determined will be applied to the message. Typically, this will be the encryption strength of the encryption algorithm used to encrypt the data for transmission. Such transmission details are received by the web browser as part of the "electronic setup sequence" from the web service provider.

ES 2 299 666 T3

A secure link is usually indicated in the browser window by the presence of a closed padlock icon in the upper right corner. The user can click on the icon to interrogate the security level that has been provided by the setup sequence. By doing so you may receive a notification of the ASSL form secured. (128 bits). The first part of the notification describes the type of encryption used while the second part describes the encryption strength. The expansion module is implemented to automatically obtain this data from the browser so that it can be used to determine whether or not the security level is adequate for the proposed transmission. Similarly, in the case of an email message, the expansion module determines the encryption scenario that the user or application has specified to use prior to transmission of the message.

The module compares the specified encryption strength with that of the link or message and, depending on the result of the comparison, performs one of the following actions:

a) if the security of the link is appropriate for the nature of the information to be transmitted, the module allows the information to be transmitted;

b) if the security of the link is greater than that required for the transmission of the information then, the module can or allow the information to be transmitted at that security level, automatically renegotiate with the Web server and the Web browser a new appropriate level of security and transmit the information at that level, or indicate to the user that the present level of security is unnecessary and invite them to take action.

c) if the security of the link is not sufficient for the nature of the information that is being transmitted then, the module can or prevent the transmission from taking place and warn the user, automatically renegotiate with the Web server and the Web browser a new level appropriate security and then transmit the information at that level, or in the case of an email automatically increase the encryption strength scenario, or indicate to the user that the present level of security is not sufficient and invite them to confirm that they still want the transmission to take place.

It will be appreciated that the expansion module could be configured to respond to a difference in the determined desirable level of security and is provided in various modes and that the actions outlined above are illustrative only.

Additional actions that can be taken by the system could include requesting a different web page to download to the user's machine or modifying the data in the submitted field so that sensitive information is not transmitted.

The operation of a browser or email expansion module to monitor data being transmitted by a user of the preferred system is illustrated in Figure 18, to which reference will be made. The module starts operation in step S320 at point C in Figure 3, just before the transmission of the data to the Web server or at point B in Figure 5 together before the transmission of an email. Control then proceeds to step S322, in which the module passes parsing the data about to be transmitted and searches for credit card numbers. One possible method to do so was described above, with reference to Figure 8. If no credit card number is detected in the data, control then proceeds to step S314 in which the module searches for passwords in the ready data. to transmit. One method of doing this has been described above with reference to Figure 6. If no password is found in the data, then control proceeds to step S316 in which the module searches for company accounts or purchase codes in the data. data. The recognition of accounts or purchase codes can be achieved by storing the company codes in a file and trying to match these codes with any string of characters or digits found in the output data. If no account code is found then control proceeds to step S318, where the module looks for indications of other sensitive data in the data to be transmitted. Such indications will preferably need to be defined in advance in a separate file used for detection, and will be dependent on the requirements of the users of the preferred system. Examples of keywords relating to projects that the company is undertaking, the titles of the projects themselves, addresses of personal details of the recipient of the data, or of the sender, or even the word "confidential" or "private" included in the own data.

If no such indications are found that the data is sensitive and requires stronger protection before it is transmitted, then the transmission is allowed to continue at the current level of encryption. This may mean that the transmission takes place without any encryption being applied.

However if any of the checks in steps S322 to step S328 reveal data that is deemed sensitive then control proceeds to step S332 in which a security rating is assigned to the detected data. This is accomplished by comparing the detected data with the default entries in the policy data.

Each entry in the policy data branch has a pre-assigned level of encryption that is the minimum level that can be used for the transmission of that data. The entries in the table and the assigned level of encryption, as with all policy scenarios, are decided by the company using the preferred system depending on their requirements. Assigning a security classification is then simply a matter of looking up a password, a card number,

ES 2 299 666 T3 credit or other data in the policy data and read the corresponding classification. Table references on the policy data sub-branch can be used to assign different encryption strengths to different passwords, credit card numbers, and so on.

Once the appropriate security level has been determined in step S332, control proceeds to step S334 in which the module determines the encryption level that has been negotiated with the Web server to which the data is being transmitted, or use by the email application before transmitting the message. This can be accomplished by interrogating the web browser or email application, or setting encryption strength variables at the time the link is established or email encryption requirements are determined, both of which will occur earlier. transmission.

Control then proceeds to decision step S336 in which the desired level of security, ie the encryption strength, is compared with that determined in the previous step. If the desired encryption level is less than or equal to that determined in step S334, then it is considered that there is sufficient protection for the data to be transmitted and control passes to the final step S330, where the module exits. Following step S330, control returns to either point C in Figure 3 or point B in Figure 5 depending on whether the module is implemented in a web browser or an email client. The transmission of the data can then proceed in the usual way.

However, if in step S336, the desired encryption level is higher than currently set, then the module does not allow transmission to proceed until the appropriate encryption level has been negotiated. Control passes to decision step S338 in which the module determines if it is capable of increasing the encryption strength, and if so, control passes to step S340 where a new more strongly encrypted link is negotiated, or in the case a higher encryption strength is set for an email.

The highest level of encryption that is available depends on the software being used by both the web server and the web browser, or in the case of email, by the applications that send and receive the email. There may then be cases where the appropriate level of encryption is not available on the one hand and the transmission of the data is never allowed to proceed. In addition, certain types of data can be given a certain security rating that indicates that no level of encryption will ever be high enough to protect it, that is, by preventing the data from ever being transmitted.

Having attempted to re-establish the link, or change the email encryption setting, to a higher encryption strength, control passes back to step S334 to ensure that the link or settings are now of the appropriate strength. If the appropriate encryption level cannot be renegotiated in step S338, or an attempt to increase the encryption strength in step S340 has not been successful, then it is deemed unsafe to transmit the data, and control passes to final step S342 where the module exits. Following exit at step S342, control returns to point A in Figure 3, or to step S132 in Figure 5 "compose email", for the user to reconsider and edit or abort the transmission. A suitable message explaining the reasons why transmission has been prevented can also be presented to the user on the screen.

The preferred system therefore provides a way to ensure that the data transmission is as secure as possible. This rules out the possibility of a user forgetting to secure a transmission, and negotiate a more appropriate level of security, if the one that has been used is not sufficient.

Web Search Engines can provide similar facilities to warn users that entered data is about to be sent over an insecure link or provide facilities to encrypt all messages by default. The preferred system however provides the ability to examine the content of the data to be transmitted to determine its security requirements, to allow or prevent transmission based on such security requirements, and on the determined security level of the link (strength of encryption). It will be appreciated that the preferred system provides a significantly improved system for secure transmissions that reduces the possibility of human error.

Monitoring of outgoing emails for sensitive information

In addition to the problem of sensitive data being intercepted by a third party between sender and receiver, organizations are at considerable risk of the deliberate release of sensitive information by their users. For example, the practice of “electronically” stealing copies of confidential documents, such as customer lists, before leaving an organization's employment is easily accomplished, virtually impossible to find, and consequently widely disseminated. All the user is required to do is send the document with their own private email address for later retrieval. The document does not even need to be sent through the organization's own email system, as an Internet mail service such as "Hotmail" can be used, making the trail of unauthorized "leakage" virtually impossible by the media. current.

In addition to providing means to ensure that an appropriate level of encryption is applied to messages, the preferred system allows messages identified as potentially sensitive to be automatically redirected or copied to another destination without the knowledge of the user. In determining whether to redirect such messages the preferred system takes into account several factors including the identity of the sender, the identity of the intended recipient, the nature of the address of the intended recipients, the nature of the content of the message, the nature and existence

ES 2 299 666 T3 of any attachments to the message, the means by which it is intended to transmit and whether the message, and / or attachments are encrypted or not.

The nature of the message can be determined by browsing it for one or more keywords, or combinations of keywords, or by using standard "natural language questions" techniques. The nature of the address of the intended recipients can be determined by reference to a list of Internet mail service domains. For example, "hotmail.com", "yahoo.com" and "aol.com" are all used predominantly by individuals, not corporations. Similarly, the address can be examined for similarities to the sender's name, for example a known email to be sent by Fred Smith to the address "smith900@aol.com" could be considered suspicious by the inclusion of both "smith" and " aol.com ”at the recipient's address. Further examinations of the message can support the probability that it is an unauthorized release of confidential data, for example if the message consists only of attachments with the text message and the subject blank, an important indication as the sender may be less likely. type a text that only he will read. The means by which the message is transmitted is an important factor, for example a transmission sent using an Internet mail service such as hotmail can be considered much more suspicious than one sent through the usual corporate email system.

Furthermore, the "download" of files to the Internet mail service is potentially so suspicious that the preferred embodiment provides means to absolutely prohibit the download of files to such services.

When mail is redirected, the preferred system adds additional text to the beginning of the mail, for example “--- Redirected Mail ---”, along with the address of the originally intended recipients, so that the new recipient can determine who was redirected, and to whom it was originally sent.

If the sent message is to be encrypted, the preferred system may redirect the encrypted or decrypted message to the third party, preferably the sender's encryption key is transmitted with the message and means are provided to the third party to decrypt the message, if it is still encrypted, and encrypt the message with the sender's original key for transmission.

The preferred system also identifies incoming emails that have been redirected (that is, sent to the user who is not originally the intended recipient), by searching for the text "--- Redirected Mail ---". Such mail can be brought to the attention of the new recipient by using, for example, special icons, or by presenting a message box for notification. A means can also be provided to allow the new recipient to easily "approve" the message and send it to the originally intended recipient. This can be achieved, for example by providing an "Approve" button. If this button is pressed, then the preferred system creates a new message in the same way as if the user had pressed the normal "Send" button. However, instead of adding text to the message to highlight that it has been redirected, in the case of the "Approve" button, the system extracts the list of originally intended recipients from the message, and then dismounts the details of the redirection to leave the message in its original state. The "To", "Cc" and "Bcc" fields are then automatically filled in with the addresses of the original receivers extracted, and the "From" field (which exists for every message even if it is displayed normally) is filled with the name / address of the original sender. The date / time field can also be set to the date / time of the original message. The message is then sent, either automatically, or when the user clicks the "Send" button. This way, when with the push of a button or two, the redirected mail can be approved and sent, and when it is delivered, it will appear that it came from the original recipient as if the redirection had not taken place.

Sample policy data to control the operation of an expansion module implemented to redirect email is shown in Figure 19 and a schematic illustration of the operation of such an expansion module is shown in Figure 20. Figure 19 is a policy data tree that has multiple branches as corresponding to the decision stages in Figure 20.

The expansion module starts in step S350, which corresponds to point B in the illustration of the operation of the email client in Figure 5. Once started, the expansion module goes through six stages that determine different particularities of the outgoing email message. First, in step S351 the identity of the person sending the email is checked against entries in a predetermined list of names or addresses. Emails from users on this list are deemed to have the authority to transmit emails directly to the intended recipient regardless of the content of the message and regardless of the recipient. Anyone not included in the list may or may not have their email redirected, depending on its content. Thus, in decision step S351, if the user's name or address is found in the list then control passes to step S364 where the email is allowed to be transmitted without further interaction. However, if the user is not on the list, control passes to step S253 for further checks. In step S352 the recipient of the outgoing email message is checked against the lookup table s, specified in the Recipients branch of the policy data shown in Figure 19. In the next decision step S354, the text that comprises the email message, and any attachments attached to the email message are compared to the entries in the lookup table t. Table t refers to a Keyword branch of the policy data and contains words that indicate the nature of the email message that may be company sensitive. In the next step S356, the email message is checked to see whether or not it is encrypted. It will be recalled that encryption does not occur until the time the email is transmitted, so at this stage the email will only be flagged for encryption.

ES 2 299 666 T3

In the next decision step S358, it is determined whether or not the email message contains attachments, and in the next decision step S360 whether the email message contains text accompanying the attachments, that is whether the text of the body of the message email is blank.

In any of the steps S352, S254 or S362 where a lookup table is queried, a match between an entry in the lookup table and an entry in the email indicates that the email should be redirected to a third party for checking before to send it out of the company. For example, if at step S354, the email is found to contain the words "confidential" or "secret", they will be sufficient to ensure that the email is verified by a third party before it is sent to its intended recipient. This ensures that sensitive information is not sent outside the company without the company's knowledge. Control therefore flows from these steps to step S364 where the text indicating that the email has been redirected is added to the message and the address of the recipient is changed to that of the verification party to which the message is transmitted. redirected. Control then proceeds to step S366 where the email is transmitted. If the email message has been marked for redirection, in step S336 it will in effect be transmitted to the verification party for review instead of the original recipient of the message.

In decision step S356 if the encryption of the message is detected then it is considered sufficient to guarantee the redirection of the message to a third party for review. Accordingly, if the message is to be encrypted, control passes from step S356 to step 364 where the message is modified for redirection. In the case of a message flagged for encryption, the encryption token is preferably removed so that the message is redirected without being encrypted, allowing the new recipient to read it. The redirection text, added to the message, preferably also includes the encryption key (which is generally the public key of the intended recipient, and therefore not sensitive) so that the message can be re-encrypted before transmission.

Alternatively, the intended recipient's entire digital certificate could be included with the redirected message. The public key, or the certificate, as the case may be, would then be removed by the automatic approval process described above.

If in step S358 the email does not contain attachments then it is judged that the email is unlikely to contain any potentially sensitive information files or documents, and then transmission of the email can be allowed without any further intervention in step S364. If the email contains attachments, and it is determined in step S360 that the email does not contain any text entered within the body or subject of the email, then the message is recognized as probably being sent to a different account than the email. sender. The email is then redirected to a third party for checking in steps S362 and 364.

Figure 21 shows the operation of the expansion module to block the download of information from the company's computer system to an external site. A simple two-state check is used, comprising an external site address check at S372, following an initiation at step S370, and a password-sensitive check on information being downloaded at step S374. Assuming that the external site address is not found to be a forbidden site in step S372, and no sensitive keywords are detected in step S374, then the download is allowed to continue in step S376. Otherwise, the discharge is blocked in step S378.

The policy data to control the operation of the expansion module, to selectively block the download of information is simple and is shown at the top of Figure 19.

In this way, outbound transmissions containing sensitive information that are being transmitted for reasons that are not in the company's interest can be verified prior to transmission, and if necessary the transmission can be prevented.

E-Mail Forwarding Management

Email applications provide a means to "forward" an incoming email to one or more users. Typically the user clicks on a "Forward" button, which causes a copy of the incoming message to be automatically entered in the email composition window, as if the user had typed it himself. All that then requires the user is to enter the names of the intended recipients of the forwarded mail and click on the "Send" button. This is a useful feature that allows a user to easily share the contents of a received email with others.

In the case of emails that contain sensitive information, a problem can arise, particularly if the sensitive nature of the email is not immediately apparent, for example if the sensitive information appears on the bottom of the email, so that the user is required to scroll the cursor down in the window you are viewing to read it. Users frequently forward emails after exploring just a few lines from the beginning, or in some cases just the subject line, particularly when they have large amounts of emails to process. As a consequence, sensitive information is frequently unintentionally disclosed, both within the organization, and more dangerously outside it. There are several high-profile cases where considerable sums are lost as a result.

ES 2 299 666 T3

The preferred system therefore provides a means of controlling the forwarding of emails. Such control includes providing warnings to the user before transmitting a forwarded email and preventing the email from being forwarded at all. A means could also be provided to approve the email before transmission, or redirect it to another user, as described above.

Preferably, forwarding occurs according to the content of the email, and the address of the recipients to whom it has already been sent. For example, the sensitive nature of email can be determined by various methods including scanning it for keywords such as "confidential", or checking if the sensitivity attribute is set to "Personal", "Private" or "Confidential". A means can also be provided for the original composer of the message to mark as unsuitable for future forwarding by inserting predefined character strings, such as "<NOREENVIAR>" (preventing any forwarding), or "<NOREENVIAREXTERNOS>" (preventing forwarding outside of the organization). Such a medium could also be provided in the form of an additional attribute to the message.

In addition to content-based factors, the preferred system interrogates the list of previous recipients of the message. If the email has already been sent outside the organization by the original composer, then it may for example be considered safe to allow additional forwards externally. Similarly, if the original email was sent only to a single recipient, then it can be determined that the original composer did not intend for it to circulate widely and an appropriate warning is issued. The course of action in response to these described factors can be determined in accordance with the guidelines.

Whether an email that is about to be transmitted is a forwarded email can be easily determined by scanning the email for character strings such as “---- Message

Original ---- ”that are automatically added to the beginning of the original email by the email program.

Similarly, the list of previous recipients can be determined by scanning the "To:" and "CC:" character strings that follow the original message string. The list of receivers is immediately after these character strings. Internal and external recipients can be easily distinguished by reference to the domain name (if any). For example, a receiver name like "Fred Smith" is typically internal, while "fsmith@xyz.com" is typically external.

Policy data to instruct the operation of an expansion module implemented to control forwarding of e-mail messages is shown in Figure 22, and the operation of such a module in Figure 23.

The policy data tree contains several sub-branches that specify the parameters against which command values ​​can be set. For example, the first sub-branch "Prevent All" when set to "YES", instructs the module to prevent all emails from being forwarded. The next WarnAll sub-branch when set to YES, requires the module to warn the email client user whenever an email is about to be forwarded. The next two sub-branches PreventExternal and WarnExternal contain the corresponding parameters only for external emails and allow the email client user to distinguish between the roles that affect the forwarding of emails within the company and the forwarding of emails to people. outside the company. The "PreventKeywords" branch specifies a lookup table in which sensitive information keywords are stored. Such keywords can be predefined as character strings such as <NORESEND> or <NORESENDEXTERNAL>, or one or more default words.

The email is scanned before transmission and if such a keyword is found in the email text or in any attachments to the email, forwarding of the email will not be allowed. The last two sub-branches Prevent If Not Sent Externally, when set to YES, will inhibit the transmission of e-mail forwarded outside the company if it has not been previously transmitted outside the company. In practice, forwarded email can be transmitted to all internal recipients of the company, simply by deleting external recipients from the recipient list or alternatively, prior to transmission, the user may be required to modify the address list so that does not contain external receivers.

Finally, the parameter set on the ImpedirSiReceptorUnico branch when set to YES prevents the forwarding of any e-mail messages if the original recipient of the message was a single person.

The operation of the expansion module is illustrated in Figure 23. The expansion module is started at step S380, again at point B in Figure 5. In decision step S382, a preliminary scan of the email is done. to see if it contains the character string “---- Original Message ----”, as this character string is automatically added to the beginning of the original email by the email program when a message is generated for forwarding. If the email message does not contain this character string, then it can be deduced that the email message is an original message and is not being forwarded and the message can be transmitted in step S384. However, if in step S382 it is found to contain the character string "---- Original Message ----", then the email message is clearly a forwarded message, and the module takes additional steps to determine whether whether or not to allow the forwarded message to be transmitted. Control then flows to step S386 in which the recipients of the forwarded message are checked to see if any are external to the on-line company. If there is an external receiver, then in step S388, the expansion module

ES 2 299 666 T3 scans the email message to see if the email has been forwarded before to a recipient outside the company. If not, the email message is prevented from being sent in step S390 and the email client user is notified. However, if the email message has been sent outside the company before, then a warning is issued to the user in step S392, following which the email message can either be transmitted by the user or it can be returned to the user. user to review the intended recipients.

If in step S386 the forwarded message is not sent to an address outside the company, then control passes to step S394, in which it is determined whether the user was the only recipient of the original message. If it was, then it may be the case that the original composer of the message did not therefore intend for it to be conveyed to a wide audience. Accordingly, control flows to step S390 where transmission of the forwarded email message is blocked. This is in accordance with the policy data shown in Figure 22, which specifies taking such action. Alternatively, a warning can be issued to the user who is trying to resend the message.

The last check performed is in decision step S396 in which the contents of the message and any annexes attached thereto are compared with entries in a keyword table. If any match is found between the entries in the email and those in the table then the message is considered to contain sensitive information and is not forwarded. The module then ends in step S390. If no sensitive keywords are found then forwarding of the email is allowed in step S384.

Signature Management of Outgoing Transmissions

The ability to use a Digital Certificate to sign a message is clearly valuable for the recipient of the message to establish the identity of the user, and for both parties to ensure that the message has not been tampered with. The sender of the message may however not be aware that a digitally signed message potentially constitutes a binding contract, which cannot be denied or revoked once sent. It is therefore imperative that caution be exercised when digitally signing a document, the same as when adding a written signature to a paper document. Email applications such as Microsoft Corporation's "Outlook" provide a means to automatically digitally sign messages, and while this can be valuable in confirming the identity of the sender to the sender, for the reasons described above, it is potentially dangerous. , requiring the user to exercise caution with the content of the document.

The preferred system provides a means of controlling the signing of outbound messages, in accordance with policy data. Example policy data is shown in Figure 24. Such control includes:

force the message to be signed;

suggest to the user to sign the message;

suggest to the user that the message should NOT be signed; and prevent the message from being signed.

In determining what action to take, the preferred system takes into account several factors, including the nature of the message content (including any attachments), the identity of the intended recipient and / or their organization, the identity of the sender, the nature of the digital certificate. being used (if the message has been flagged for signing), and the nature of the digital certificate available to sign the message.

The nature of the message can be determined by browsing it for one or more keywords, or combinations of keywords, or by using "natural language interrogation" techniques. Similarly, the nature of the intended or available digital certificates can be determined by reference to the issuer and type of certificate.

Figure 25 illustrates the operation of an expansion module to ensure that an email is digitally signed properly or not. The module starts in step S400, at point B in the operation of the email client illustrated in Figure 5. Control then passes to decision step S402 in which the outgoing email is scanned to see if it has already been marked with the signature. The actual "signature" of the message will not occur until directly prior to transmission. If it is not marked for signature, control passes to step S404 where the module consults the Recipients lookup table (table f) to determine if the recipient of the outgoing email has been identified as one to whom the emails they must always be digitally signed. If the Receiver is in table f, then control passes to step S406 where the email client user is notified that the email will not be sent unless it is digitally signed. Alternatively, the expansion module can automatically digitally sign email using the email author's digital certificate.

If in step S404, the recipient of the outgoing email is not found in the lookup table, then control passes to decision step S408 where the Keyword Table is then consulted on the ForceSign branch of the policy tree. . In the event that any of the keywords in table g are found in the text of the email or in any of the email attachments, digitally signing will be required

E-mail is 2 299 666 T3, and control will proceed to step S406 as before. It will be appreciated that decision steps S404 and S406 correspond to the search commands for querying the search for Receivers and Keywords on the ForceSign branch of the policy data.

Such keywords can be predetermined as "Confidential", "Secret", "Contract", "Quote", "Order" and so on as illustrated in Figure 24.

If the recipients of the email are not in table f, and the email does not contain Keywords specified in table g, then control passes to decision step S410, corresponding to the search command on the SuggestSignature branch of the sample policy data. In decision step S410, the recipient's address is checked against those in lookup table h, to determine whether email signature is advised. If the recipient's name is found in table h, then control proceeds to step S412, where the email client user is notified of the convenience of digitally signing the outgoing email message. However, the email client user is not required to digitally sign the email message and the email can then be transmitted unsigned if the user so chooses. Following decision step S410, if the recipient's name is not found in table h, control proceeds to decision step S414, where as before, various keywords that could indicate that contain sensitive data and require a digital signature. Depending on whether the email contains such sensitive keywords, either the email client user is notified in step S412 of the convenience of digitally signing the message, or alternatively, the unsigned email message is transmitted in the step S416.

If in step S402 following the initiation of the expansion module, the email is found to have been marked for signing then control passes to decision step S418. At decision step S418 the expansion module queries the lookup table m in the DenySignature branch specified under the DenySignature branch of the policy data. Table m is specified on the CertificatesUsados ​​branch under the DenySignature branch, and specifies the issuer, type, certificate number or signing key of the digital certificate deemed of interest. In case the digital certificate or signing key to be used to sign the outgoing email is found in table m, then additional checks such as the Recipient and the nature of the outgoing email will be made to determine if it is appropriate to sign the message or not. Control proceeds to step S420 where the recipient of the outgoing email is checked against table n of Recipients and then to decision step S422 where the email text and any attachments are scanned for various keywords. If in any of the decision steps S420 or S422, the receiver or any text in the message matches what is defined in the lookup tables, control passes to step S424 where the transmission of the email is blocked. The email client user can then go back to the email text input stage, and may require retransmission of the message without digitally signing it.

If in any of the steps S418 or S422 the certificate or the signature key is not found to be of interest, and the text of the email is not found to contain any sensitive words, control passes to step S426 corresponding to the first sub-branch on the SuggestDon'tSign branch of the policy data tree. As for the DenySign branch of the policy data tree, the three decision stages S426, S428 and S430, correspond to the search commands to check the digital certificate or the signing key used with the email, the recipient of the email outbound and outbound email text versus default responsive entries in lookup tables j, k, and l respectively. If in step S426 the certificate used to sign the outgoing email is found to be of interest, and in either step S428 or S430, the receiver or the text of the outgoing email is found to match the entries in the specified lookup tables, control will flow to step S432 in which the email client user will be notified of the convenience of not digitally signing the outgoing email message. The user, however, can still be free to send the signed message if he wishes.

If in any of the decision steps S426, S428 and S430 no match is found then the email is sent normally in step S416.

Instant Messaging and Telephony Applications

In addition to email and browser activity, additional applications such as Instant Messaging (also known as "Chat") and digital telephony applications such as "Voice Over IP" are becoming popular in business situations. The Instant Messaging regulations are defined in RFC 2778 and RFC 2779 and by the IETF SIMPLE working group. The Voice Over IP regulations are defined in the ITU-T recommendation H.323 (1998). Many aspects of the present invention can be applied to data transmitted and received by such applications. Instant Messaging is conceptually similar to a series of sent and received emails, except that the "conversation" takes place "live" with both parties present from beginning to end. For the purposes of the present invention however the procedures are identical. Figure 5 in the drawings may represent Instant Messaging by replacing the word "email" in steps S122, S124, S132 and S134 with the word "Message". The description of the "E-mail Server" 95 is replaced with the word "Message Relay". The preferred embodiment is arranged to intercept at points A and B as above, providing an expansion to the Internet Messaging application, or developing an Instant Messaging application that contains the expansion functionality.

ES 2 299 666 T3

Alternatively, it will be appreciated that the intercept activity could occur at the protocol level, intercepting packets from the network before they leave the user's machine, or when they arrive at the user's machine.

Voice Over Internet Protocol (VOIP) is conceptually similar to Instant Messaging, except that the content of the messages consists of digitized voice, which is encoded and transmitted immediately. The analysis of the content of the messages is not practical, however the means to record the message and place controls at the level of the "call" are viable and are implemented in the same way, or as an expansion to the voice messaging application , or at the network protocol level, any of them within the user machine.

Although the implementation of the preferred system has been described with reference to expansion modules for existing applications, the invention can be implemented by providing web browsers, email clients, instant messaging applications or Voice Over IP applications in which the functionality of the Expansion modules described in this point are already hard-coded from the beginning.