RU2252451C2 - Method for performing transactions, computerized method for network server protection, transaction system, electronic wallet server, computerized online shopping method (variants) and computerized access control method - Google Patents

Abstract

FIELD: electronic financial transactions.

SUBSTANCE: method includes receiving request for transaction from user to server, generating response to user, receiving answer from user, based on response, after that said response is processed and user is checked. Then transaction authentications are performed, using at least one key, and at least portion of said authentication documents are sent to user. Then repeated query from user is received, which has portion of authentication documents mentioned above, and it is checked by said key to provide access to transaction service.

EFFECT: higher reliability and trustworthiness.

7 cl, 16 dwg

Description

FIELD OF THE INVENTION

This invention mainly relates to methods and devices for conducting network transactions. In particular, this invention relates to systems for authorization and doing business in networks such as the Internet.

State of the art

In recent years, many consumers have realized the convenience and practicality of purchasing goods and services electronically. There are many ways to make electronic purchases (commonly called "e-commerce"), such as TV programs "shop on the couch", a call in response to television advertisements and the like. But recently, direct purchases over the Internet have become especially popular.

Starting an online transaction, the buyer usually finds goods and / or services by viewing online ads, such as HTML pages, through a browser (navigation and viewing tool) of the World Wide Web (WWW). Payment is usually made using a payment card number that is transmitted through a secure channel, such as a connection using a Secure Sockets Layer (SSL), which is established between the buyer and the seller. A payment card number is usually a sixteen-digit credit card number. Credit card numbers usually follow the standard format when there are four numbers separated by spaces "0000 0000 0000 0000". The first five to seven digits are reserved for processing purposes and identify the issuing bank, card type, etc. The last sixteenth digit is used as the checksum of this sixteen-digit number. The average eight to ten digits are used to uniquely identify the customer. The seller then processes the payment card number, for example, receiving direct authorization from the card issuer, after which the seller makes a transaction (business operations, commercial transactions, etc.). The SSL standard is described in the document "SSL Protocol version 3.0", dated November 18, 1996, available on the Internet at http://home.netscape.com/eng/ssl3/draft302.txt, the link to which is given here for reference.

Although millions of transactions are made daily on the Internet, a regular SSL transaction often reveals some of the shortcomings that have already been identified. Despite the fact that SSL usually provides a secure point-to-point connection and does not allow unscrupulous third parties to eavesdrop on, trick or otherwise obtain numbers of other people's cards, this protocol does not give full confidence that the payment card number itself by is correct or that the person who provided this number has a legal right to do so. Due to the high likelihood of counterfeiting during transactions through the Internet (Internet transactions), most issuers of payment cards charge for Internet transactions such as "(card itself) no" increased fees. In other words, because of the increased risk of a “no card” transaction, almost all card issuers are subject to higher authorization fees than if the card itself were in the hands of the seller.

In order to increase security, which was reduced as a result of the transfer of a payment card number over insecure networks, many suggested using smart cards (chip cards). A smart card usually has a built-in microprocessor and memory for storing data directly in the card. This data can be, for example, a cryptographic key or an electronic wallet (wallet), in which the amount of available currency is recorded. Many very clever schemes were proposed, but they usually had one conspicuous flaw, one that they were all non-standard. In other words, smart card merchants in their web stores would usually have to purchase additional, custom software. Moreover, to this day the cost of administering smart cards, including the recording and support of cryptographic information, is excessive.

It was assumed that the Secure Electronic Transaction (SET) standard would improve the security situation of Internet transactions through various cryptographic technologies. Although the SET standard did improve security over SSL transactions, the administrative complexity of working with the many public and private keys required for the transaction limited the widespread use of SET. The SET standard also required the acquisition by sellers who wish to work on SET of special software.

Existing digital electronic wallet technology, such as a digital electronic wallet, provided, for example, by GlobeSet Inc. (1250 Capital of Texas Highway South, Building One, Suite 300, Austin, TX, 78746 (USA)), enables customers to use various products for card transactions (such as credit, payment, debit, smart cards, account numbers and similar to them) in order to pay for goods and online services (i.e. in real time). Basically, a digital electronic wallet is a tool with which personal information (name, address, payment card number, credit card number, etc.) is stored in order to carry out electronic commerce or other network interaction. Personal information can be stored on the main server or on the side of the customer / user (personal computer or smart card) or immediately on both the main and user servers. The main electronic wallet server consists of a web server and a database server, which centrally stores personal information about the buyer and information about the credit card, its customer preferences and the profile of its online purchases (made in real time).

A digital electronic wallet mainly performs functions such as servicing a one-time login and password, autocomplete forms of a list of purchased goods, one- or two-click purchases, personalizing websites, tracking online ordering and delivery, a detailed electronic check, as well as special offers and promotions based on previous purchases and the choice of this buyer. The most commonly used one-click purchase also activates an electronic wallet, and confirms the purchase immediately. A two-click purchase first activates the electronic wallet, then a second click confirms the purchase.

In practice, the buyer clicks on the link to the electronic wallet and an SSL session is established with the electronic wallet server. A certain browser plug-in is being executed, and the buyer thus gives his login password or smart card for authorization and gets access to the contents of the electronic wallet. When making a purchase in an online store, the relevant information is transmitted from the electronic wallet server to the seller’s web server.

Thus, it is clear that a new system of electronic transactions is needed. This system should improve the security situation, while at the same time not causing much trouble to buyers and sellers. In addition, such a system should integrate well with various existing electronic wallet systems and other services from various suppliers.

SUMMARY OF THE INVENTION

In the presented examples of the implementation of the present invention, the user is provided with an identification tool, such as a smart card, which can be used in electronic transactions. This identification tool contains a digital certificate and is accordingly authorized by the network server, which carries out the transaction fully or partially requested by the user. Here, the user is the buyer (customer), who initiates the purchase transaction, and the server is an electronic wallet server, which in turn interacts with the security server in order to give a new quality to the reliability and privacy of this transaction.

Electronic transactions, such as electronic purchase transactions, are carried out as receiving a request for a transaction from the user on the server, issuing a response to the user, receiving the corresponding response from the user for this particular response, processing the response to verify the transaction tool, obtaining appropriate certificates that include at least one key for electronic transactions, transferring to the user at least part of these certificates, receiving a second request from the user, which includes part of the credentials true, check the validity of those parts received certificates key to provide access to the transactional service.

In addition to the described method of conducting transactions, the present invention proposes a computerized method of protecting a network server from its possible use as a base for attacks on a network client, in which the network server first receives a connection request from the network client and scans part of the network server for special characters associated with the protocol, then they check for the absence of special characters in any response of the network server to the network client and send a response from the network server About the server to the network client. The network server can be protected from attacks by restricting access to the network server to only access to that part of the network server that at least serves the selected protocol, as well as limiting the ability to scan this part of the network server for special characters of the selected protocol. Special characters can be removed or replaced with ordinary characters to reduce the risk associated with the features of the selected protocol. Said protocol preferably includes elements written in JavaScript. Preferably, scanned characters are stored in the system log (log file) for the purpose of creating a security log (security log). The security log can be regularly reviewed to identify potentially unreliable special characters. Some requests may be rejected. Such protection of a network server can be carried out during an electronic purchase transaction made through an electronic wallet.

The invention also includes a transaction tool, such as an electronic wallet used for shopping transactions and having an activator and a toolbar. It is better if such a toolbar has a button for a user to load a small activator, and uses operating system controls, such as a system panel. Such a transaction tool also includes an autocomplete form component and an autocomplete component for autocomplete forms with information previously entered by the user.

The invention also provides a transaction system for providing financial transactions at the request of a user working on a user computer connected to a data network. The system comprises a transaction authorizer and a security server configured to verify the availability of identification means at the user's disposal and provide a digital identity to said user computer if the verification is successful, the transaction authorizer configured to authorize a user’s request for a transaction based on at least a portion of the said digital identities received by a user computer via a data network.

In preferred embodiments, the system may comprise a transaction tool server or an electronic wallet server connected to a user computer via said data network. Moreover, said electronic wallet server may be configured to receive a transaction request from said user computer, communicate with a seller’s computer system and transmit information about said user to said seller’s computer system. At the same time, the user's computer contains a transaction tool, which is an electronic wallet client, and a reader configured to transmit information between the transaction tool and the identification tool.

The means of identification may be a smart card. Preferably, if the security server and the transaction authorizer have a data connection isolated from the data network, and the transaction tool and the security server have a data connection isolated between the data network.

The means of identification may contain a digital certificate of unique identification of the user of this means of identification. In particular, the system comprises a personal user identifier of said identification means for opening access to a digital certificate.

The system may also include an issuer of an identification tool, and the transaction is a "card present" transaction set by the issuer of the identification tool.

The invention also provides an electronic wallet server for facilitating transactions through a digital network, which includes a digital network interface and an electronic wallet application that is connected to a database, the electronic wallet server being configured to receive a transaction request from an electronic wallet client, processing an identity from said electronic wallet client for identifying a user of an electronic wallet client, fetching user information of the database after the identification of said user and making the said transaction on behalf of said user using said user information.

In preferred embodiments, the credential comprises a set of arbitrary data digitally signed by the identification means at the disposal of said user. Moreover, the electronic wallet client is provided with said set of arbitrary data via a security server.

The server may contain seller’s forms filled in with information about the said user when the transaction was completed on behalf of the user.

The invention further provides a computerized method for making online purchases in which authorization is performed through a security server, obtaining credentials from said security server, then identifying the seller’s address where the purchase is made from, transmitting said credentials to the electronic wallet server to authorize the said user on the electronic wallet server, and after successful authorization on the electronic wallet server, messages with the a by the seller’s address to the said electronic wallet server, and information about the said user is sent from the electronic wallet server to the seller’s address, after which they receive information about the results of the said purchase.

In another embodiment of a computerized method of making online purchases, a request is received from the user for the transaction to the server, which includes the seller’s address and certificate, then the said certificate is verified to identify the user, and according to the results of the said check, user information is selected from the database, after which fill out online forms in accordance with the address of the seller and give the mentioned user information about the results of the purchase.

In preferred embodiments of the invention, the security server is combined with the server. Digital signature is carried out using a smart card.

In addition, the invention provides a computerized method for controlling access to a service, in which they first receive a login request from a user, verify that the user has an identification tool, after receiving a successful verification result, issues a certificate to the said user, then receives a transaction request from the user, which includes at least part of the said certificate, and process the said part of the certificate to provide access to the said service.

In preferred embodiments of the invention, said verification is carried out by means of a response request, which contain arbitrary data from an identification means, in particular a digital signature of said arbitrary data. The said service may be represented by a financial transaction service.

List of figures of drawings and other materials

The above and other advantages of the present invention are described in detail below in the description of examples of its implementation with the accompanying drawings, in which like elements on the corresponding modules have the same numeric designations.

1-3 are diagrams of various examples of the implementation of a transaction system.

4 is a block diagram of an example customer service system.

5 is a block diagram of an example security system.

6 is a block diagram of an example of an electronic wallet.

7-10 are views of examples of screen forms of an electronic wallet system formed in accordance with the present invention.

11 is a flowchart of an example processing process executed by a typical activator application.

12 is a map of the sequence of messages used during the login process.

13 is a map of the sequence of messages used during the purchase process.

14 is a message sequence map illustrating the potential for security problems inherent in many scripting languages.

FIG. 15 is a sequence chart of messages of the normal progress of data exchange without causing the security problems mentioned in FIG. 14, and

Fig. 16 is a flowchart of an example of a process for reducing the amount of unnecessary executable code.

Information confirming the possibility of carrying out the invention

The present invention is described below as a combination of functional blocks and various processing steps. Due to this, such functional blocks can be implemented using any equipment and / or software configured to perform these functions. For example, various components on integrated circuits (ICs), such as logic elements, hash tables, and the like, can be involved in the present invention, and they can perform various functions under the control of one or more microprocessors or other control devices. Similarly, software elements for the purposes of the present invention can be implemented in any programming language or scripts, such as C, C ++, JAVA, COBOL, Assembler, PERL and the like, with various algorithms implemented on any combination of data structures, objects, processes, subprograms or other program elements.

Moreover, it should be noted that in the present invention can be used any technology of general application for data transfer, queries, data processing, interaction management and the like. And yet, this invention can be used to detect and compensate for security holes that occur when using scripting languages such as JavaScript, VBScript, and the like.

It should be noted that the specific form of implementation of the invention given and described here is given with the aim of the best disclosure of the present invention and in no way limits the scope of its claims. Indeed, for brevity, we cannot give details of traditional methods of data exchange, application development, and other functional aspects of its constituent systems (and also the components of the operating components used). Moreover, the connection lines shown in the accompanying figures represent typical functional relationships and / or physical joining between different elements. It should be noted that in a real system of electronic transactions, there may be many temporary or additional relationships or physical connections.

To simplify the description of an example implementation, the invention is often described as an e-commerce system for use on the Internet. However, it should be noted that many applications of the present invention can be given. For example, this system can be used to authorize users of a computer system, or to activate a password protection system, or for any other purpose. Similarly, this invention can be used in conjunction with any type of personal computer, network computer, workstation, computer, mainframe, and the like, under any version of any operating system, such as Windows, Windows NT, Windows2000, Windows 98, Windows 95, MacOs, OS / 2, BeOS, Linux, Unix, and the like. Moreover, although the invention is often described here as being implemented on the basis of the TCP / IP communication protocol, it must be understood that the invention could also be implemented using IPX, Appletalk, IP-6, NetBIOS, OSI, or any number of existing or future protocols.

Further, the buyer and seller can be specific people, as well as objects, enterprises, while a bank can be understood as any card issuer, such as card issuing companies, card sponsoring companies, or issuers acting under a contract with financial organizations. A payment network may include existing networks that currently support transactions with credit cards, debit cards or other types of financial / bank cards. Such a payment network is a closed network, which implies that it is protected from information leakage, for example, as in the American Express network (American Express ^® ), the network Visanet (VisaNet ^® ) or Verifone (Veriphone ^® ).

In addition, other participants, such as intermediary organizations, may be involved in some phases of the transaction, but these participants are not shown on the diagrams. To carry out the transaction, each of its participants is equipped with a personal computer. The buyer has a personal computer, the seller has a computer or server, and the bank has a mainframe-type computer; however, any of the computers can be a minicomputer, a server based on a personal computer, a network of computers, laptops (travel computer), laptops, PDAs, networks, or the like.

Turning now to FIG. 1, a transaction system 100 (for conducting transactions) includes at least one user computer 110, a transaction authorizer, in particular a transaction authorization computer (seller) 120, a security server 130, and an additional transaction service server 140. In some implementations of the invention described in detail herein, transaction system 100 is used for e-commerce to carry out purchase transactions. More specifically, user computer 110 is the computer of the buyer or customer (user), transaction authorization computer 120 is the seller’s computer, and transaction service server 140 is an electronic wallet server. It should be noted that although the transaction system described herein is an e-commerce system, the present invention may equally be applicable to various other transaction systems.

Some computer systems and servers are interconnected by a corresponding digital data network 102, which may be a network such as the Internet, or another public network. These networks may include automatic telephone exchanges, intranets of enterprises or educational institutions, and the like. In some implementations of the invention, one of which is shown in FIG. 2, the seller’s computer is in electronic communication with the security server with

using a separate data connection isolated from the network 102. Similarly, in some implementations there is a channel 150 connecting the electronic wallet server 140 to the security server 130, which is separate from the network 102. Channels 150 and 152 may be used as channels a telephone, a digital integrated services network (ISDN), a dedicated T1 channel, or other data transmission channels, such as a radio channel and the like. It should be noted that channel 150 and channel 152 may be identical channels, or in some implementations of the invention, one may be fundamentally different from the other.

Some embodiments of the invention, as shown in FIG. 3, also include an application server 160. In some implementations, a database (not shown) and / or a server profile (not shown) can communicate with the application server 160 and / or the electronic wallet server 140. The application server 160 can be used to evenly distribute the computing load. Load balancing between the electronic wallet 140 and the application server 160 can increase efficiency and / or security. For example, application server 160 may perform some functions performed by electronic wallet server 140, such as accessing a database. Since the application server 160 is not directly connected to the data network 102, accessing the database from the application server 160 rather than from the electronic wallet 140 can increase security.

It should be noted that although Figs. 1-3 illustrate some examples of the invention, it is also possible to create other implementations. For example, the invention may include channel 150 and not include channel 152 and vice versa. Moreover, the components (such as the buyer (customer) 110, seller 120, security server 130, electronic wallet server 140 and application server 160) can be individual computers, and working groups of networks or computers, purposefully interacting to perform functions, described here. The functional contribution of an individual component can be distributed between one or more computers so that the described functionality is implemented. For example, an electronic wallet server can actually be a collection of web servers, application servers, and other types of servers.

To complete the transaction, the buyer 110 appropriately establishes a connection through the network 102 with the seller 120. When the purchase has already been completed, the buyer contacts the electronic wallet server 140. The buyer is then redirected to the security server 130 in order to verify that the buyer is indeed smart card owner. A smart card can have a digital certificate that uniquely identifies the card, for example, by creating a digital ID in the context of the current transaction, as described below. In some implementations of the invention, parts of the digital ID are returned to the buyer 110, and other parts are transmitted to the electronic wallet server 140 via the secure connection channel 150. Buyer 110 may then use digital credentials to log in to the electronic wallet server 140, which in turn can already complete the electronic transaction according to the authority received from the buyer 110. The electronic wallet server 140 may include functions for filling out forms specified by the seller’s computer 120 . When the seller 120 receives the identifier of the safe purchase means from the buyer 110 or from the server of the electronic wallet 140, authorization of the card can be carried out on channel 152 so same as regular authorization of a payment card. As described above, data transfer can be carried out using various protocols, for example SSL or VPN and the like. Due to the fact that a smart card contains identification information that is unique for a particular card and which is only electronically read and transmitted over networks, a purchase transaction using smart cards is more secure than a transaction using a regular payment or credit card. For transactions with this level of security, lower fees can be set, and they can be processed as card-present transactions. In addition, if such a transaction is a "card present" transaction, then the risk of counterfeiting risk can be transferred from the seller to the card issuer.

Referring to FIG. 4, a typical customer computer 110 (also referred to as a customer or user computer) is any computer system that is capable of initiating an electronic transaction over a network 102. In some implementations of the invention, the customer’s computer 110 is a personal computer running any operating system 212, such as any version of the Windows operating system from Microsoft, Redmond Washington, USA, or any version of the MacOS operating system from Apple, Coop Rtina, California, USA.

Buyer computer 110, respectively, has software and / or hardware for processing identification means, in particular smart cards 202, through a web browser interface 216 running operating system 212. Web browser 216 is a program compatible with computer 110, using which he communicates over the network, such as Netscape Communicator from Netscape, Mountain View, California, USA, or Internet Explorer from Microsoft, Redmond, Washington, USA, or AOL browser from America Online from Dulles, Virginia, USA. In some implementations, a transaction tool is installed on customer’s computer 110, for example, an electronic wallet client 214, which is some kind of computer program capable of interacting with an electronic wallet server. A typical client of an electronic wallet is the Microsoft Wallet program or the Globeset Wallet program from Globeset, Austin, Texas, USA, however any program can be used.

The electronic wallet client 214 and browser 216 can interact with the smart card 202 by transmitting data to a smart card reader (terminal) for operating the smart card under operating system 212. Any smart card reader 204 is a smart card reader capable of transmitting information between the electronic wallet client 214 and the smart card 202. In some implementations, a Ge model GCR410 reader was used as such a reader. mplus, Redwood City, California, USA, compliant with ISO-7816, or any other suitable reader.

As a smart card 202, any can be used with which you can carry out electronic transactions, for example, any smart card made in accordance with the following ISO standards, mentioned here as reference material:

ISO / IEC 7816-1: 1998 Identification cards - Chip cards with pads - Part 1: Physical characteristics.

ISO / IEC 7816-2: 1999 Information technology - Identification cards - Cards on microchips with contact pads - Part 2: Dimensions and location of contact pads.

ISO / IEC 7816-3: 1997 Information technology - Identification cards - Cards on microchips with pads - Part 3: Electronic signals and data transfer protocols.

ISO / IEC 7816-4: 1995 Information technology - Identification cards - Cards on microchips with pads - Part 4: Command system for inter-industry data transmission.

ISO / IEC 7816-5: 1994 Identification cards - Chip cards with pads - Part 5: Number assignment system and procedure for registering request identifiers.

ISO / IEC 7816-5: 1996 Identification cards - Cards on microcircuits with pads - Part 6: Data elements for inter-industry exchange; and

ISO / IEC 7816-5: 1994 Identification cards - Cards on microcircuits with pads - Part 7: Commands for intersectoral data exchange of the structured data query language from payment cards (SCQL).

A typical smart card 202 is a smart card made in accordance with the ISO 7816 specification, such as a card on a SLE66 chip manufactured by Infineon, Munich, Germany. The SLE66 chip has built-in memory (such as 16K memory, but larger or smaller memory can be used) and a processor running an operating system, such as Multos (such as Multos v.4). For some implementations of the invention, a smart card 202 also means an applet (application programs in the Java language (JAVA)) for performing the functions of storing and processing digital certificates and other cryptographic functions. For an introduction to the basics of cryptography, see "Applied Cryptography: Protocols, Algorithms, and C Sources," by Bruce Schneider, John Wiley & Sons (Second Edition 1996), a link to this book is provided here as a reference. For example, a J.A. X.509 applet can be included in a smart card to process X.509 certificates that will be written to it. Although smart cards are mentioned in the implementations of the invention described here, it should be noted that other means of identification can be used, for example, a GSM global telecommunication system mobile phone can replace smart cards in some implementations of the present invention.

Now turn to Figure 5. The security server 130 accordingly implements interaction with the network 102, and the security module 304 and the authorization server 306 interact with the database 310. The network interface 302 is any program that can communicate with the network 102, for example, such as a web server. In some implementations, the network interface 302 may be based on the Netscape Enterprise Server software from Netscape, Mountain View, California, USA. The network interface 302 receives electronic messages from the network 102 and forwards them accordingly to the security module 304 or the authorization server 306.

The security module 304 and the authorization server 306 can be separated by a firewall 308 (firewall software) that manages the data transferred between the security server 130 and the customer 110 or the electronic wallet server 140. The firewall 308 can be any device or control program ( for example, an access control router) capable of restricting the flow of data between an external and internal network (not shown). In some implementations of the invention, the security module 304 is appropriately located outside the firewall in order to control data transfer between the security server 130 and the customer 110 or the electronic wallet server 140. The authorization server 306 protects valuable confidential information, such as a database 310, which may contain cross links of X.509 certificates stored in various smart cards 202 serving the entire system 100, allowing it to be maintained on the Internet with a good level of security tee. It should be understood that the functions of the security module 304 and the authorization server 306 can be appropriately combined or separated within the scope of the present invention.

Now turn to Fig.6. An exemplary electronic wallet server 140 includes a network interface 402, an additional applet server 404, and an electronic wallet application 406. Network interface 402 is any program that allows network communication on a network 102, such as a web server. In some implementations, the 402 network interface is based on the Netscape Enterprise Server software from Netscape Corporation, Mountain View, California, USA. An additional server 404 applets implements the server side of the functions of distributed processing programs, such as JAVA programs or ActiveX controls. A typical applet server is Sun Microsystems' Java Applet Server from Mountain View, California. The applet server 404 and the network interface 402 support the functions of the electronic wallet application 406, which may include login processing, retrieving data from the electronic wallet database 408 and / or managing transactions, as described here. In some implementations of the present invention, the electronic wallet server 140 may include a SERVERWALLET program (also known as NETWALLET) from Globeset, Austin, Texas, USA.

Some implementations of the present invention may include an activator application that appropriately helps the buyer complete the purchase process with an electronic wallet. The activator application may present information in the form of a status bar, for example, or may itself launch the electronic wallet client program 214 (Figure 4), when necessary. In addition, the activator can support local cache sites served by electronic wallet.

The activator application can be implemented as a regular computer application. In some implementations, the activator application provides information to the system panel as a "floating bitmap", or in another suitable way. A graphical representation (i.e., icons) can provide status information such as “zone of a supported site”, “zone of a supported authorization page”, “zone of a supported payment page”, “no open windows”, “zone of an unsupported page” and / or similar.

The floating bitmap can be implemented as a graphic file of any format, for example, a graphic exchange format (GIF) file. In various embodiments of the invention, information can be displayed in graphical, audio, video, audio-video, multimedia, animation, and other formats. Moreover, GIF files can be replaced with files like LZW, TIFF, animated GIF, JPEG, MPEG or any other type of graphic, audio or multimedia formats or files.

Basically, the present invention has been improved by equipping a transaction tool with a window that has controls that make this transaction tool easier to use. The transaction tool can be used for various electronic transactions. For example, purchase transactions, financial consulting transactions, insurance transactions, buyer-buyer transactions in cases of barter transactions, transactions related to the response to commercial offers or the issuance of fees and others. The transaction tool described here is an electronic wallet used for purchase transactions. The functionality of the electronic wallet has been expanded to include the functions of a window with controls in order to make it easier for the user to use the electronic wallet. Basically, the present invention includes the functions of accessing an electronic wallet in the form of implementation on the customer side, and a server toolbar (toolbar), allowing the user to use the controls of the operating system user interface, such as the system panel, for small volumes of downloadable activator. Microsoft Windows

The activator is an object code that runs on the user's computer and has subroutines for accessing the electronic wallet server. Such an activator can generate events and has procedural logic that allows you to communicate with an electronic wallet, responding to certain user and system actions or events. Usually, the activator is represented by one single graphic element, for example, an icon that, if implemented under the Microsoft Windows operating system, will be located on the system panel and which allows the user to enable or disable the visibility of the electronic wallet toolbar. In fact, in various implementations, the electronic wallet toolbar is a special browser window through which access to the electronic wallet server is available. The activator interacts with the server of the electronic wallet in such a way as to automate the updating of the activator object code by downloading it from the server in small portions. Typically, before starting the download, the user is asked for confirmation. In some implementations, the activator interacts not only with an electronic wallet, but also with other applications such as commercial offers or issuing rewards. The system supports a number of important options for each of its web pages, for example, dynamic and contextual information that is specific to each page viewed by the user. And the activator monitors the viewed unified index of the information resource (URL), adjusting to the page being viewed so that the user has information about the opportunities provided to him. For example, an activator can check whether a user is browsing a trading site and currently offering special offers (discounts, etc.). The activator can also monitor the software versions on the user's computer in order to remind him of the possible appearance of newer versions. Embodiments of the invention can be performed on any networks, such as global, local, Internet, or on any personal computers, radio communication devices, and the like. The system can be implemented under any operating system, such as Microsoft Windows, Mac OS, Linux, Windows CE, Palm OS and others.

Such an activator, which is preferably implemented on the customer side, allows the user 110 to be in constant or interrupted interaction with a company that stores electronic wallet 140, for example American Express, without having to take up space under extra windows on the screen of the user terminal. As already mentioned, it allows the company that stores the electronic wallet to track and show the user potentially interesting data at the moment. These configurable controls allow the customer to quickly find the right websites and immediately launch the necessary functions, such as authorization of a digital payment card. The client toolbar can preferably be basically implemented as a separate window associated with a user browser window, and it can support such a geometry that it appears to be part of the user's browser. The only difference is, say, when a user clicks on his controls, it remains unchanged, while the main URL is loaded into the main window to perform the specified action (such as accessing an electronic wallet). For example, when a user clicks on the electronic wallet icon on the system panel, a toolbar 502 of the electronic wallet 205 appears on a screen in a separate window, which is connected to the main browser window 500, as shown in FIG. 7. In another embodiment, the customer’s toolbar is located on the window frame of a particular electronic wallet, providing the user with additional controls, as described above, in an additional window area of this electronic wallet that extends the main window. In the third embodiment, this area is scattered around the main window of the user browser in order to use it for the electronic wallet and other controls described above.

Such a system provides a convenient way for customers not only to visit their chosen URLs, but also to launch certain functions, which can be a multi-stage and even changing process, as seller’s sites are constantly updated. This system allows you to simplify the life of the user, not only making working with an electronic wallet and commercial sites easier, but also making it easier to find the electronic wallet and toolbar of the customer. When a user has many open windows, searching for an electronic wallet window can become difficult, especially considering that various browser windows can capture input focus while browsing and communicating with sites. Thus, the use of the system panel and server functionality is the best combination for the user. In a preferred embodiment, this system can work with any known browser, for example, such as Netscape Navigator.

While previously created systems could only be a custom portal (for example, My American Express. Corm), which allows the user to visit the page and then follow the link from this page, the preferred embodiment of the present invention makes it possible to conveniently use the window with controls that remain on the users screen while they surf the web. In addition, the customer’s toolbar allows you to automate user actions, and this despite the fact that such actions can take place on a third-party commercial site. Moreover, previously created systems could use a separate browser window to display electronic wallet controls, while the present invention uses a conventional browser window divided into parts to provide space for the electronic wallet itself. For example, in a preferred embodiment of the invention there is an electronic wallet icon available to the user on a system panel (not shown). After clicking on this icon, the electronic wallet toolbar 502 appears on the screen, as shown in Fig. 7. The presence of this toolbar is not intrusive, while allowing the user to work with an electronic wallet. The toolbar 502 is preferably integrated in the browser window 500.

As shown in Fig. 8, when the user presses the button for the shopping catalog on the toolbar 502, the toolbar will expand and turn into the page of the shopping catalog 602. The user can select a seller from the list of sellers 604 located here on the page of the trade catalog 602. After selecting a seller from the list sellers 604 an electronic wallet takes the user to the website 702 of the seller selected by the user, as shown in FIG. 9. Usually, when the electronic wallet has already transferred the user to the seller’s website 702, the toolbar 502 takes its usual size. When the user makes a purchase from the seller, for example, by placing the selected item in the basket and starting the checkout, in the present invention, the checkout itself is partially done by the electronic wallet itself. As shown in FIG. 10, when the user determines the desired purchase on the seller’s website 702, an interface (window) 802 of the purchase is displayed. For example, a checkout interface 802 is provided on one side of a browser screen, and a store window continues to remain on the other side of the browser screen. Most of the information that the user must enter to complete the purchase (for example, name, address, E-mail, credit card information, etc.) has already been entered into the electronic wallet and appears in the electronic wallet purchase window 802 itself. In a preferred embodiment of the invention, the user can edit this information.

In a preferred embodiment, the present system also includes methods and apparatus that are best suited to reliably fill out HTML forms of Web sites. Ultimately, users can themselves determine the content of the information that they mainly want to give to sites, regardless of their appearance, labeling and behavior. In a preferred embodiment, the present invention includes an “auto-remember” component, which allows you to remember information already entered, and an “auto-complete" component, which includes a combination of powerful processing tools obtained by analyzing user and site behavior patterns.

The present invention collects information from users, storing it reliably and securely on the server, and then distributes it to the desired form fields under user control. The system supports binding user information to various fields of HTML-forms of sites of interest to the user. This information is then used to control the completion (or auto-completion) of HTML forms by those users who want to interact with these sites.

As for the “auto-remembering” function, previous versions of electronic wallet implementation could have a memorizing function, but it had to be activated by the user. In the present embodiment of the “auto-memorization” implementation, the user does not need to press anything to memorize the form that they just filled out, since this system itself remembers the fields that users enter in the store window. When the form is submitted (for example, by pressing the "Send" or "Buy" button), the electronic wallet responds by determining whether the window that requested the form to be sent is the website window of the seller. If so, in this case, the electronic wallet remembers the data accordingly, otherwise it may prohibit the submission of the form and continue normal operation. Among the controls of an electronic wallet there may be a button with the inscription "Remember", or it may support the option of automatic storage, which can be constantly enabled. Preferably, all fields except those used for autocomplete are remembered. In this context, it is clear that when the user enters data in a specific field, this value will be stored in the system. The electronic wallet component will detect the field values entered in this way and securely transfer them to the server via the Internet. The next time the user visits this page, the electronic wallet, in addition to autofilling the form fields that are taken from the system, will also fill out the form with the values that were previously remembered. When processing a form (auto-complete), an electronic wallet safely reads values from the server.

In particular, with respect to Internet Explorer, the present invention accordingly implements an ActiveX control that is itself connected to a web page, such as, for example, American Express Online Wallet. In a preferred embodiment, this ActiveX control has a method that captures browser events in all Internet Explorer browsers, and therefore American Express Online Wallet can, if necessary, respond to these events via the JavaScript function loaded as part of the American Express Online Wallet page, thus allowing Get the full document in Internet Explorer. This feature allows the system to catch the "Document Completed" event, triggered by Internet Explorer, which means the end of the document loading. When this event is intercepted, the ActiveX control notifies the American Express Online Wallet page by calling the JavaScript function loaded as part of the American Express Online Wallet page. This function responds to an event through appropriate interaction with the ActiveX control in order to intercept the "Submit Form" event for all forms of all Internet Explorer browser windows.

When a user fills out a form on a web page and clicks on the Submit button (or any control such as a button that submits the form), the American Express Online Wallet page receives a notification from the ActiveX control by invoking the JavaScript function loaded as part of the American page Express Online Wallet.

The American Express Online Wallet page then appropriately determines whether the document that triggered the Submit event is the desired document by checking the URL box that triggered the event. If the event needs to be processed, then the American Express Online Wallet page should call the ActiveX control function, which in turn reads the document object model (DOM) that triggered the event. Then the DOM is scanned and you can get the values of the forms for subsequent transmission to the server for memorization. In a preferred embodiment, the ActiveX control is required to properly stop intercepting browser events and “Submit Forms” events in order to reduce the number of crashes during execution of the algorithm.

As for the Netscape browser, due to the specifics of implementing the event model in Netscape, the system only intercepts events from JavaScript functions. If the system manages to obtain the “Allow recording from browser” privileges (assigned by the user), then the system will succeed in executing a function that allows the external window to intercept the events of another window. And then the system will be able to read the document object model for all frames of this window. In the process of doing this, the system notifies each form of the window that it wants to intercept the "Send" event. Thus, when the user fills out the form of this window notified by the system and clicks the “Submit” button (or any control, such as the button that submits the form) on this page, the electronic wallet is notified and responds properly. Those skilled in the art will understand that the present invention can be implemented for each respective transactional system, including but not limited to any electronic wallet systems.

As for the form filling function, an electronic wallet, such as the American Express Online Wallet, implements the filling function in order to help users fill out forms. Previous systems, such as those provided by GlobeSet, typically used the Browser Helper Object. The concept with VNO often has the disadvantage that, for example, Internet Explorer 5.0 contains a bug (failure) in which only the first VNO specified in the registry is loaded. This is also a problem for any application in such a way that it is impossible to be sure whether all VNOs are loaded or not. Moreover, VNOs are downloaded for each instance of Internet Explorer, that is, many VNO instances can work at some point in time, occupying memory and slowing down browsing by all browsers, not just the one you need.

The present invention preferably replaces the solution with VNO by using the same ActiveX control that was mentioned in the description of the "auto-memorize" function. By attaching an ActiveX control to an electronic wallet page, the system appropriately obtains an object model of any document loaded into any Internet Explorer browser, using, for example, Shell Windows API functions. When the user clicks the "Fill out the Form" button on the electronic wallet page, the wallet can respond by first receiving an object model of the document by using the ActiveX control. Further, the electronic wallet can save the names of the fields that make up the form and send them to the server for heuristic processing. The server will respond to this request by returning the values that should be used when filling out these fields. These fields can then be filled using the same document object model obtained previously. Thus, the present invention simplifies the problem of inputting duplicate data onto web site forms. In addition to customer convenience, this increases the accuracy of the data entered.

In more detail, the architecture of the present invention combines the server model of each site (i.e., fields, pages, links, etc.), the server model of the user (i.e., its profile), the user-generated site model (i.e. storing macros, markup tags, drag-and-drop algorithms), a site model artificially generated by the system (i.e. building up and checking models generated by users), and a heuristically generated site model (i.e. assumptions about semantic information for lei, actions, etc.). This system creates and stores several special types of models. The first characterizes the site, for example, how you make a purchase, how you add something to the basket, how you look for types of goods, how you enter your preferences (for example, in cases of travel), etc. The second model characterizes the user, for example, what actions the user is allowed to do and what attributes of the user profile are available. By combining these two models, this system creates special processing capabilities that give it flexibility and power.

This system binds the model of user capabilities to the site model where site models are generated by known methods. The site model, as such, can be created by the user, host, credit card issuer and even the site provider. In a preferred embodiment, ECML / XML languages are used to represent the site model. In some embodiments, site models can be exchanged with other systems.

For example, a user can sequentially visit the websites of various airlines and travel agencies in order to buy airline tickets. Each site has fields on different screens in order to collect information that is approximately the same for different sites. However, each site uses different HTML forms that are hosted on different URLs and which may change from time to time. Although the information on different sites can be very similar in nature, there is currently no general mechanism for automating the process of filling out form fields with information about user preferences (such as suggestions about places, lunch menus, discounts for relatives, etc.). Each site can have its own profile for maximum memorization of user preferences. And in this state of affairs, one user must create his profile on each such site separately.

A heuristic field recognition model is included in the present invention. With this approach, in the identification of the required form fields, their spatial location relative to the labels related to these fields is taken into account. Combinations of field labels and HTML field attributes (especially the "name" attribute of the HTML elements "input", "select" and "action") will be given to the input of the heuristic functional, which has a dictionary to facilitate identification of the required fields.

In another embodiment, the present invention includes user recognition of fields. With this approach, the user, on his own initiative, intercepts the input by pressing the "Remember" button of such a control that allows the server to collect information about the sequence of actions that the user performs. When the user does this, he can "play back" the sequence of actions (similar to remembering the macro used in some programs). Thus, it becomes possible to submit the sequence of user actions to the heuristic functional and also remember it directly in the markup tables that are used by this functional.

In a preferred embodiment of the invention, the two above approaches require some user intervention in order to fully complete the process of creating markup for filling and marking the location of fields in order to most fully reflect site navigation and possibilities for filling in the fields, which makes this invention applicable. When necessary, living people act in much the same way as the user recognition algorithm for fields, although, of course, they will provide much more information about their navigation and filling out forms than the average user. But in any cases, the information that is collected is used to create process maps (or detailed site maps) that reflect the sequence of actions (filling out forms, HTTP response, HTTP request, etc.), with which you work with site. A form field map will also be generated for each process page web page where the field map determines the exact field names that can be used to automate form submission. State maps may also be required in order to track the state of the user while interacting with the website (for example, user states such as being logged in or not logged in will affect the outcome of certain actions on the site).

In a preferred embodiment of the invention, the user interaction process can be either fully automated (the user announces his desire to carry out a sequence of actions recorded as a script) or the user can participate in the interaction (here the present invention can automatically fill in the form fields, leaving the user with the opportunity to adjust , change and fill in any field that requires additional data entry). In addition to well-known products and services, a customizable technology in the form of process and field maps can be applied to new products and services, allowing entrepreneurs to facilitate the automation of data entry from site visitors. For example, if an entrepreneur compiled maps of processes and fields for his customers (in any way described above), he can sell this information or services and goods to third-party customers. Sites for which such cards exist can also benefit from this by delivering a similar service to those customers who do not have access to such a system. The underlying processes themselves are based on a system that collects information and converts it, for example, into XML or ECML. These standard representations can form the basis for the exchange of information for the mentioned goods and services.

Turning now to FIG. 11. The process 900, implemented accordingly in the activator program, includes initializing the application (step 902), checking the universal resource locator (URL) while the user browses the site or makes an online purchase (step 904), determining whether the user is browsing a supported site (steps 908 and 912) and with the issuance of corresponding answers at step 908 and 912 (respectively). Other features (such as bonuses, special offers, tracking, security, and the like) can be implemented at step 916.

Initialization step 902 appropriately includes starting an activator application and initializing the application. An activator’s application can be initialized as a result of turning the system on, connecting to a network (such as the Internet or a local network), or by initializing a browser (such as Internet Explorer from Microsoft, Redmond, Washington, USA, or Netscape Navigator from Netscape, Mountain View, California, USA). In some embodiments, the activator application may communicate with the electronic wallet server 140 (FIGS. 1-3), the electronic wallet application 406 (FIG. 6), or with another network server 102 (network server). The activator application accordingly contacts the remote server in order to obtain information, such as a list of websites, domain names or URLs that are supported by the electronic wallet.

This information can be obtained on a regular basis (i.e. daily, monthly, or each time the agent program is initialized), or when a request from the activator application or server follows. In various embodiments, the activator application stores a list of supported URLs in a cache (high-speed buffer memory), in a file on a local disk, or in the memory of a user computer.

As the user browses the Internet or another data network 102, the activator application appropriately tracks the location of users on the network. One way to track a user is to track the URLs used by the user's browser. In such implementations, the activator application receives the current URL from the user's browser (or from the system’s network interface, respectively) and compares (step 906) the current URL with the list of supported URLs received from the remote server in initialization step 902. Such comparisons are shown in the logical steps 906, 908, 912 and 916 of FIG. 11, although these steps can be combined or broken in any way without losing the meaning of the invention. For example, although FIG. 11 shows a multiple comparison, for some embodiments of the invention, a single comparison of the current URL with a list of supported URLs is sufficient.

If the current URL matches the supported URL, then the activator application responds accordingly. For example, if the current URL has a supported checkout page (yes, at step 908), then the activator application performs the checkout process (step 910). The checkout process may include notifying the user that this checkout page is supported by displaying a message box or by highlighting a specific icon on the system panel or in a separate window. If the application 214 serving the electronic wallet is not already running, the activator application may issue a dialog box or other notification to the user that this page is supported by the application 214 serving the electronic wallet. Such a window may have a button or other mechanism by which the user can launch the electronic wallet application 214.

If the current URL matches the supported checkout page (yes, at step 912), the activator application can provide the electronic wallet application with payment instructions or other authorization instructions for the electronic wallet application (step 914). Messages circulating between an activator application, an application serving an electronic wallet, a browser, etc., can be sent using Open Desktop messaging technologies, Object Linking and Embedding (OLE), object procedure calls, etc. P.

In various embodiments of the invention, the functions described above are carried out using cookies (password or a piece of data about the user's access to the server), as described below. Cookies are used to determine the authentic context of the user. If a valid user context is found, then the activator application either launches the server application or launches the server toolbar, which will allow the user to start other applications. For example, the user's browser may have some cookies, which may indicate the possibility of making a purchase either through a regular payment or by a special card. The activator can issue a toolbar that will allow the user to select the desired payment instrument (i.e. a regular payment or on the user's electronic wallet card). It should be noted that available applications are not necessarily applications related to purchase transactions. In some implementations, contextual information is stored on both the server and browser cookies. For example, cookies can serve as the key according to which contextual information can be downloaded from the server.

Other functions (step 916) may also be included in the activator application. For example, protection mechanisms can be implemented (such as those that were described above and will be described below), customer tracking functions, bonuses, special offers, and the like. In the case of bonuses or special offers, the activator can perceive the current URL as referring to a specific product or web page. When the user arrives at a specific supported URL, the activator application notes the match and gives the user (through a dialog box, browser, or whatever) a special offer, such as the ability to purchase a certain product or the opportunity to receive a discount on a purchase. It should be noted that other functions within the scope of the present invention may be included in the activator application.

In some embodiments of the present invention, the electronic wallet client 214 (FIG. 4) provides forms pre-populated with specific customer information. 1-3, a user can access an electronic wallet through a web server, such as an electronic wallet server 140 of a network 102. In order to use an electronic wallet, a user fills out a registration form (which may, for example, be generated by a CGI script). The electronic wallet server 140 appropriately receives demographic, banking, and other information (i.e., address, delivery address, name, credit card number, etc.) from the authorization server 306 (Figure 5) or another server on the private network. This information can be used to configure the electronic wallet client 214 (FIG. 4), which is uniquely assigned to each user. One way to configure the electronic wallet client 214 is to create a configuration file that is associated with the client 214 and which is read by the client 214 in order to obtain information for the electronic wallet, as described above.

The registration information preferably also includes information about a card reader, which in turn includes an indication of which port, serial or USB, the reader is connected to. If the user agrees to install the electronic wallet service application, the user is set up or supplied with a credit card reader, as well as a special code (such as a cryptographic key or password, or some other code in electronic or printed form). The user then registers himself on the server of electronic wallet 140 and logs in using a card or a special code. After entering the special code, the user receives a specially configured software for servicing the electronic wallet, which can be installed on the user computer 110 accordingly. The procedure for pre-filling out forms of electronic wallet can be carried out using any credit or payment card, by simply associating the version of the electronic wallet service program with a special code. The configuration information of a particular user is associated with the code that was provided to that user, and the user can subsequently use a special code to authorize himself on the electronic wallet server 140 to obtain a copy of the electronic wallet software configured with data specifically for that user.

Figures 1-3 and 12 show how customer 110 initiates the transaction accordingly by logging on to the electronic wallet server 140 via smart card 202. In order to access the electronic wallet server 140, customer 110 may first connect to security server 130 through the browser 216. The user selects a specific URL to call the input page by accessing the bookmark (bookmark), or by clicking on the icon or link, or in another way. The security server may return the authorization page via the network interface 302. In some implementations, the input form and the user login and password send button and the smart card authorization hyperlink are part of the authorization page. The user selects the authorization of the smart card, and the browser 216 responds accordingly by sending a message to the authorization request 1002 (FIG. 12). The security server 130 receives an authorization request 1002 and initiates a smart card authorization process as necessary. In some implementations, the security server 130 generates a cryptographic response (request) to the authorization server 306 or the security module 304 in response to the authorization request message 1002. The cryptographic response 1004 is a message of any kind, as long as it prevents repetition attacks (i.e., such attacks , in which fake messages are generated by re-sending previously sent authorization packets), for example, a response with sending arbitrary data aimed at receiving a response from the X.509 application stored in the smart card 202. The response is then sent to the customer 110 via network 102 as a response message 1004.

Upon receipt of a response message (request) 1004, the browser 216 sends a message 1004 to the electronic wallet client 214 for processing by smart card 202. If the client 214 is not running, then the browser 216 can automatically run this program. The electronic wallet client 214 then prepares the signature response accordingly. For example, an electronic wallet client 214 can read server response information, generate a new user request (i.e., a second cryptographic response for smart card 202), combine both responses into a double request, and calculate the double request hash code for later use, for example, Public-Key Cryptography System 1 (PKCS1) type 1 cryptographic block of a public-key cryptographic system. The hash code can be calculated in accordance with any algorithm, such as, for example, MD3 or MD4, and used to guarantee the full and accuracy of the data in the double request block. PKCS refers to a cryptographic standard with a common key that defines the mechanisms for encoding and signing data, and using the public key of the RSA cryptosystem. The PKCS standard is fully defined in PKCS # 1: RSA Cryptographic Specifications Version 2.0 (PKCS # 1: RSA Cryptography Specifications Version 2.0), dated September 1998 (available at http://www.rsa.com/rsalabs/pubs /PKCS/html/pkcs-1.html) and referenced here as reference material.

The PKCS1 block is appropriately delivered to the smart card 202 for processing by the card reader 204 (step 1006 in FIG. 12). In order to access the card, in some implementations, the card reader 204 interacts with the user computer to request the user to enter a personal identifier, such as a personal identification number (PIN) or other uniquely identifying identifier. In a preferred embodiment, the PIN is stored on the card 202. In other cases, the PIN or other personal identifier may be stored somewhere in the system, for example, in a card reader 204 or on the customer’s computer 110. The user accordingly enters the personal identifier to to open access to the smart card 202, which receives a double request block from the client 214 of the electronic wallet and then puts a digital signature on the block. In some implementations, smart card 202 has a private key used to calculate the digital signature for this block. The signed block is then returned to the electronic wallet client 214. In some implementations, smart card 202 also provides a certificate (such as an X.509 certificate) that corresponds to the private key used to calculate the digital signature.

Upon receipt of the signature and certificate from the smart card 202, the electronic wallet client 214 accordingly creates the necessary response message 1008 for sending to the security server 130. Although the response message 1008 can be in any format, in some implementations it is formatted as a PKCS7 message, as defined in the PKCS # 7 Standard for Cryptographic Message Syntax Standard. RSA Lab Technical Note, version 1.5, (PKCS # 7. Cryptographic Message Syntax Standard. An RSA Laboratories Technical Note ") version dated November 1, 1993, available at ftp://ftp.rsa.com/pub/pkcs/doc/pkcs-7.doc and is hereby incorporated by reference in its entirety. .

Upon receipt of the response message 1008, the security server 130 processes this message as necessary (step 1010 in FIG. 12). In some implementations, the response message 1008 is sent to the authorization server 306, which verifies the certificate and signature received from the smart card 202. Upon successful verification of the certificate and signature verification in some implementations, a secure identification tool can be generated, which is returned to the buyer 110 or to the smart card 202.

In the future, the use of a secure identification tool allows the user to establish their identity and work safely with an electronic wallet. In some implementations, the authorization server 306 may create an additional means of secure authentication in order to identify the user. In other implementations, such an identification tool may consist of many parts, subsequently tied to the corresponding digital certificate, smart card or other data, possibly using the database 310. In third embodiments, the additional identification tool and its parts may be sent to the buyer (customer) ) 110 in combination with a redirect message 1012. In various embodiments, an additional means of identification may be sent to the customer or maintained on the server 306.

Upon receipt of a redirect message 1012, customer 110 appropriately connects to the electronic wallet server 140 and makes a connection request. In some implementations, the Connection Request message 1014 appropriately includes an identification means and possibly an additional means of secure identification, in whole or in part, as part of the redirect message 1012. The electronic wallet server 140 requests the automation server using some combination of completely secure means of identification or partially so as to identify the customer 110. Request 1016 and response 1018 are appropriately transmitted through the transmission network data (channel) 150, which in some implementations is maintained separate from the network 102 in order to increase the security of the system 100. In alternative implementations, a network 102 may be involved, which in some implementations may provide enhanced security through virtual private network technologies (Virtual Private Network), the SSL protocol, the use of shared secret keys and / or other cryptographic tools. If the returned credentials 1018 are in order, the electronic wallet server 140 reads the attributes of the corresponding customer 110 from the electronic wallet database and notifies the customer of a successful login using message 1020. It should be noted that other options for implementing the login procedure are possible. It should also be noted that any encryption schemes, message formats, and the like can be used to complete the login sequence for system 1000.

Now turn to Fig.13. A typical authorization procedure suitable for use in trade transactions is initiated by the buyer (user) 110 by sending a request 1102 for the transaction to the electronic wallet server 140 for each event (such as a purchase) for which authorization is necessary. The electronic wallet server appropriately recognizes this event and sends a request message 1104 to the security server 130, for example, through a communication channel 150 to generate a request message. The authorization server 306 (or some other component of the security server 130) then generates a response 1106 (which may include randomized data) and provides a response 1106 to the electronic wallet server 140 through, for example, a connection (channel) 150. The electronic wallet server receives a response 1106 and sends the response information to the browser 216 as a request message for an electronic signature 1108. The browser 216 launches an electronic wallet client 214, if necessary, and redirects the request message to an electronic signature 1108. Accordingly, obstacle to the above described electronic wallet client 214 generates a request message block on an electronic signature as a PKCS1 block type and includes therein a request server, the client request and the hash code. The resulting block of the e-signature request message is supplied to the smart card 202 by means of a card reader 204. Smart card 202 appropriately signs this block and prescribes a copy of the X.509 certificate built into it.

The signed block can then be returned to the electronic wallet client 214, which generates a corresponding response message to the electronic signature 1110 (such as a PKCS7 message) and sends it to the electronic wallet server 140. The electronic wallet server 140 then generates an authentication message 1112, which includes itself data from the response message to the electronic signature 1110 and the secure identification means associated with the buyer 110 during the login process (such as for example the login process in the system mu shown in Fig.10). In other implementations, the used secure identification means is received from the buyer 110 as part of a response message to an electronic signature 1110. An authentication message 1112 is sent to the security server 130 via connection 150. The security server 130 can then redirect the authentication message accordingly to the authorization server 306, which can verify the signature and obtain a secure identification means from the database 310 (step 1114 in FIG. 13). This means of secure identification and / or an additional unique identification code obtained from the database is then compared with the means of secure identification or identifier received from the electronic wallet server 140. If these two objects (ie, means of secure identification or identifiers) are identical, it can be concluded that the card that is currently used by buyer 110 is the same card that was used by buyer 110 during the login process. Then, an appropriate enable or disable message 1116 is sent from the security server 130 to the electronic wallet server 140, and the transaction can be continued.

In some embodiments, the electronic wallet server 140 plays the role of the proxy server (representative) of the buyer 110 during transactions. For example, the electronic wallet server 140 can fill out order forms on behalf of the buyer, enter the delivery address, card number, etc. Vendor 120 may then authorize the purchase transaction as a transaction with a regular charge card using conventional hardware and software. But you must understand, however, that the additional security provided by the systems disclosed here will allow you to have a greater degree of trust in the identity of the buyer, thereby reducing the discount rates on the transaction.

Various embodiments of the present invention include additional security vulnerabilities. Due to the fact that many server functions implemented, for example, on security server 130 or electronic wallet server 140, may include various components written in scripting languages such as JavaScript (in accordance with the specifications of Sun Microsystems, Mountain View, California, USA) or VBscript (according to Microsoft specifications, Redmond, Washington, USA), servers connected to 102 network can offer various functions implemented in such server programming languages to many customers 110 p means for delivering scripts (code) from the server to the customer. This code is interpreted, compiled, and somehow executed by the user computer 110. In implementations involving, for example, JavaScript, scripts are interpreted and executed by a viewing program (such as Internet Explorer, Netscape Communicator, etc.) executed on the user computer 110. In other implementations, other non-PC compatible browsers are involved, for example, phones using the Wireless Application Protocol (WAP) standard, which supports WML markup scripts. Many scripting languages can have commands, objects, or other data management mechanisms, for example, to access files on a user's hard drive or other manipulations with data on a user's computer. In order to prevent the receipt of executable code from unauthorized sources, the script language may include a mechanism that allows the user to allow scripts received only from trusted sources. For example, a user conducting an electronic transaction, as described above, may allow the execution of scripts downloaded from the electronic wallet server, but may prohibit the execution of scripts received from other sources on his computer.

A potential security issue found in many scripting languages is shown in FIG. An unscrupulous "hacker" can create a website 1204 that is specifically designed to conduct malicious actions against a user of a legitimate web server 1206. A hacker site 1204 (indicated in the figure as a "criminal web server") can, for example, deliver a code fragment to a user, such as a script. Hacker site 1204 can also force the web browser of user 216 to access a specific universal resource locator (URL) on legitimate server 1206 (such as electronic wallet server 140 or any other network server 102). The requested URL can be cleverly redone so that the legitimate server returns, for example, an error message or other response to the user's browser 216. In some implementations, such a legitimate server response may include portions of a request from a user's browser 216 or variations thereof. If such an answer includes JavaScript, VBscript, or other executable code generated as a result of malicious attacks by the criminal site 1204, then it is clear that such codes can be executed on the user's computer. This example illustrates one of many technologies whereby a “hacker" can force a legitimate web server to return a provoked response to a user's browser. Since different executable systems and scripting languages contain commands for accessing the file system, registry, etc., it is clear that unauthorized execution of such code is extremely undesirable. Nevertheless, the technology shown in Fig. 14 may allow the script or other code from the criminal site 1204 to be delivered to the user's computer. Since the user's computer believes that the script came from a reliable source (i.e., from an electronic wallet server), a user computer can execute code from a criminal site, thereby creating a potential threat of damage or unauthorized data dumping, data destruction, etc. On Fig illustrates the correct sequence of operations of the interaction, which should take place (instead of a criminal attack, as shown in Fig).

In order to prevent the formation of such potential security problems, various technologies are included in various embodiments of the present invention to reduce or eliminate unwanted executable code. Turning to FIG. 16. The process 1300, the purpose of which is to repel script-like attacks, appropriately includes steps to reduce the number of server parts that have elevated privileges (step 1302), remove dangerous characters inside these parts of the site (step 1304), encode some special characters where necessary ( step 1306), and it is possible to write to the log file information that goes to users from the corresponding parts of the website (step 1308).

Consider step 1302. A website typically includes various pages, each of which has a unique URL. Site users can provide increased trust to certain servers (such as those that correspond to proven financial or trading organizations). By restricting the scope of high trust to only part of the website (i.e., a limited subset of the URL corresponding to the established website), you can lower the level of trust exerted on the rest of the site, thereby increasing security. Trust can be limited to a certain part of the site by configuring the user's web browser so that, for example, he trusts only part of the site. The web browser can be configured manually or using a script, for example, supplied from an electronic wallet server. When only certain pages (i.e., part) of a website receive elevated privileges, any script received when accessing other pages will either not be executed at all, or at least will not be run in elevated privilege mode.

In addition to (or instead of) configuring the client so that it “trusts” only a certain part of the server, the server itself can be configured to improve the security of client-server interaction. For example, to improve security, scripts with elevated privileges may be prohibited on most servers. Moreover, the data transmitted to the trusted part of the website can be monitored and / or changed before sending it to the user (step 1304 and 1306). Most scripting languages use special characters to form their commands. For example, JavaScript commands are often encoded with sentences placed between angle brackets ("<" and ">"). Consequently, angle brackets can be removed from any content that must be returned from a trusted part of the website. If a web page received from a trusted part of the site should have a malicious JavaScript program that, for example, tries to use angle brackets, the script commands will not be executed on the user's computer, since these commands will not be syntactically formatted after removing the angle brackets . On the other hand, some "dangerous" characters (such as angle brackets in JavaScript) can be returned in another format, for example, in the format of an ampersand ("&"), or in the values of the American information exchange code (ASCII), or by replacing “dangerous” characters are safe, such as the space character (step 1306). It should be noted that any characters can be deleted or transcoded only depending on which script language, execution environment, etc. are used.

In some embodiments of the invention, at an additional step 1308, a log of information from various parts of the website is appropriately included. All content in which symbols are transcoded or deleted can be written to a log file so that this log can be analyzed to determine if a given website is dangerous in order to endanger a network client. For example, all content (content) received from a web page, all content received from a trusted part, or content from any other part of a web site can be logged into one or more data files. These data files can be viewed or analyzed as appropriate in order to understand whether attempts have been made to provide illegal content to server users.

In some cases, internal computers can be attacked by a "criminal" site by sending content that contains a script to a network server, which allows you to write content to tracking files (logs). Suppose the browser was configured to give elevated privileges to files stored on the server, as in implementations where the user views tracking files via the web and other e-commerce servers using such a browser, and the script can be run on a network client under network server privileges, who delivered this tracking record (i.e., under the highest privileges). Running such a script can result in a blow that can be delivered much later after the script has been sent to the network server. Such an attack is preventable by using the same methods and procedures that were described above to eliminate the transfer of scripts through sites, such as, for example, the above-described "criminal" attack. A filter, such as described in FIG. 16, running on a network server, such as a web server, or running on a network client, such as a personal computer browser, can filter script control characters and encode characters, reject characters, or reject the entire record.

Appropriate structures, materials, actions and equivalents of all elements of the following claims mean the inclusion of any structures, materials and actions in them to ensure the implementation of the above functions in conjunction with other elements claimed in private versions. The scope of the claims of this invention should be determined in the framework of the claimed features of the formula and their equivalents, without limiting it to the above examples.

Claims (42)

1. A method of conducting transactions, characterized in that the request is first made for the transaction from the user to the server, a response is given to the user, a response is received from the user based on the response, then the response is processed and the user is verified, then the transaction certificates are compiled containing at least one key, and transmit to the user at least part of the said credentials, then receive a second request from the user that contains the aforementioned part of the certificates, and verify the said part of the certificates with the said key to provide access to the transaction service. 2. The method according to claim 1, characterized in that the transaction is an electronic purchase. 3. The method according to claim 2, characterized in that carry out the transaction of electronic purchases through an electronic wallet. 4. The method according to claim 1, characterized in that the transaction is carried out by means of a smart card of the user. 5. A computerized method of protecting a network server from its possible use as a base for attacks on a network client, characterized in that they first receive a connection request from the said network server from the said network client and scan part of the network server for special characters associated with the protocol , then check for the absence of special characters in any response of the network server to said network client and send a response from the network server to the said at the network client. 6. The method according to claim 5, characterized in that they further restrict access to said network server to only a specific part of this network server for a given protocol. 7. The method according to claim 5, characterized in that it additionally replaces the mentioned special characters with safe characters to reduce the risks associated with the use of the selected protocol. 8. The method according to claim 5 or 6, characterized in that said protocol includes elements written in JavaScript. 9. The method according to any one of paragraphs.5-7, characterized in that it further record the mentioned special characters to create a security log. 10. The method according to claim 9, characterized in that they additionally check the aforementioned security journal to determine whether the special characters are hostile. 11. The method according to any one of paragraphs.5-7, characterized in that the said protection of the network server is carried out during an electronic purchase transaction. 12. The method according to claim 11, characterized in that the electronic purchase transaction is carried out by means of an electronic wallet. 13. A transaction system for providing financial transactions at the request of a user working on a user computer connected to a data network, characterized in that it contains a transaction authorizer and a security server configured to verify the availability of identification tools at the user's disposal and provide a digital identity mentioned user computer in case of successful verification, and the transaction authorizer is configured with the possibility of Strongly user transaction authorization request based on at least a portion of said digital certificates received by a user computer data network. 14. The system according to item 13, characterized in that it further comprises a transaction tool server. 15. The system of claim 13, wherein it further comprises an electronic wallet server connected to the user computer via said data network. 16. The system of Claim 15, wherein said electronic wallet server is configured to receive a transaction request from said user computer, communicate with a seller’s computer system, and transmit information about said user to said seller’s computer system. 17. The system according to item 13 or 16, characterized in that the user's computer contains a transaction tool and a reader configured to transmit information between the transaction tool and the identification tool. 18. The system of claim 17, wherein said transaction tool is a customer of an electronic wallet. 19. The system according to item 13, wherein the means of identification is a smart card. 20. The system of claim 13, wherein said security server and said transaction authorizer have a data connection to each other isolated from the data network. 21. The system according to 17, characterized in that said transaction tool and said security server have data connections between them isolated from said data network. 22. The system according to item 13, wherein the means of identification contains a digital certificate of unique identification of the user of this means of identification. 23. The system according to p. 22, characterized in that it contains a personal user identifier of the said identification means for opening access to a digital certificate. 24. The system according to item 13, characterized in that it includes the issuer of the means of identification, and the transaction is a transaction of the type "card present" established by the issuer of the means of identification. 25. An electronic wallet server for facilitating transactions through a digital network, characterized in that it comprises a digital network interface and an electronic wallet application having a database connection, the electronic wallet server being configured to receive a transaction request from an electronic wallet client, processing credentials from the said electronic wallet client for identifying the user of the electronic wallet client, retrieving user information from the database after identifying said user and making said transaction on behalf of said user using said user information. 26. The server according A.25, characterized in that the said certificate contains a digital signature. 27. The server according to p. 26, characterized in that the said certificate contains a set of arbitrary data with a digital signature of the identification means at the disposal of the said user. 28. The server according to item 27, wherein said electronic wallet client is provided with said set of arbitrary data through a security server. 29. The server according to claim 25 or 27, characterized in that it contains seller’s forms filled out with information about the said user when the transaction was completed on behalf of the user. 30. A computerized method for making online purchases, characterized in that they authorize via a security server, obtain certificates from the said security server, then identify the seller’s address where the purchase is made from, transfer the said certificates to the electronic wallet server to authorize the said user on the electronic wallet server, and after successful authorization on the electronic wallet server, messages with the seller’s address are forwarded to the aforementioned electronic wallet server and send information about said user of the electronic wallet server to the address of the seller, and then receive information on the results of said purchase. 31. The method according to p. 30, characterized in that the said certificate contains a digital signature. 32. The method according to p, characterized in that the said certificate contains data received from the security server. 33. A computerized method of making online purchases, characterized in that they receive a request from the user for the transaction to the server, which includes the seller’s address and identity, then verify the identity to identify the user, and, based on the results of the verification, select user information from database, after which they fill out online forms in accordance with the seller’s address and give the mentioned user information about the results of purchases and. 34. The method according to p, characterized in that the said certificate contains a digital signature. 35. The method according to clause 34, wherein said certificate contains data received from a security server. 36. The method according to clause 35, wherein said security server is combined with said server. 37. The method according to any one of paragraphs 34-36, characterized in that said digital signature is performed by means of a smart card. 38. A computerized method of controlling access to the service, characterized in that they first receive a request for input from the user, verify that the user has an identification tool, after receiving a successful verification result, issue a certificate to the mentioned user, then receive a transaction request from the user, which includes at least part of said certificate, and processing said part of certificate to provide access to said service. 39. The method according to § 38, characterized in that the said verification is carried out by means of a response request. 40. The method according to § 39, wherein said request-response contains arbitrary data from the means of identification. 41. The method according to p, characterized in that the said request-response further comprise a digital signature of said arbitrary data. 42. The method according to any of paragraphs 38-41, characterized in that the said service is a financial transaction service.

Images